Имя: Пароль:
1C
1С v8
Помогите устранить ошибки неконсистентности
,
0 PVS_Mtl
 
06.07.16
10:28
Уважаемые коллеги! Помогите пожалуйста разобраться в причинах возникших ошибок и устранить их.
Ситуация следующая.
1. До возникновения проблем (до конца мая):
1.1. был старый сервер (железо), на котором размещались сервер приложений 1С, sql server 2005 (9.00.3042.00) sp2 вместе с базой.
1.2. ежедневно успешно выполнялись процедуры обновления статистик и дефрагментации, урезания лога транзакций и затем снятия бэкапа (модель восстановления full). full - чтобы в течение дня иметь возможность восстановления на любую точку времени из лога. Еженедельно проводилась реиндексация.
1.3. Сервер работал медленно, но в целом корректно. Однако ближе к началу описываемой истории замедление работы сервера в целом усугубилось, очень редко какая-либо из описанных процедур не успевала отработать в срок, и другие не запускались.
1.4. До дня переезда на новый сервер ошибок в части процедур обслуживания БД не возникало.
2. С переездом БД на новый сервер в конце мая с дня переезда появились ошибки, препятствующие нормальной работе БД:
2.1. ошибки неконсистентности данных (inconsistensy was detected...) Появляются во время отработки регламентов обновления статистик, дефрагментации индексов и реиндексации, сами процедуры не проходят по причине ошибки неконсистентности данных. Появляются регулярно, в различных объектах, которые не дорабатывались нашими программистами (регистр Хозрасчетный, Заказы поставщиков, регистр накопления Движения денежных средств и др.). Некоторые объекты повторяются из раза в раз с различными страницами. Один раз при обновлении статистик было указано имя
2.2. Причина неконсистентности в том, что в поля таблиц БД по непонятной причине записываются неподходящие по типу значения (очень большие). Наши админы применили следующий способ исправления: они обнуляют указанные значения, и временно ошибка исчезает, пока не появится в новом месте.
2.3. Такой способ исправления имел негативный результат: в одном из справочников обнаружили пропажу ряда элементов. Один восстановили загрузкой из копии базы, а другой не загружается. Пишет, попытка вставки неуникального значения в индекс _Referen..._ParentCode_RLSR с полями, по которым по sql таблице было проверено, что таких элементов в них нет.
2.4. транзакционный лог перестал урезаться (cannot shrink log file 2 because of minimum log space required). Сейчас он 178 ГБ при базе в 63 ГБ, используемое в логе место 99.993%, результаты dbcc opentran
Transaction information for database 'UPP'.

Replicated Transaction Information:
        Oldest distributed LSN     : (0:0:0)
        Oldest non-distributed LSN : (1269938:16600:1)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Репликация не настроена.
2.5. При переходе на новый сервер администраторы перенесли целиком "образ" системы (я не админ, за точность термина не ручаюсь). Единственная шероховатость - sql server после этого не распознает тип процессора нового сервера.
2.6. Экспериментально в большинстве случаев разворачивание dt (в тестовые базы) также приводило к исчезновению ошибок неконсистентности.
---------------------------------------------------------------
Просьба помочь:
1. как избежать ошибок неконсистентности? как их правильно исправлять?
2. как урезать лог? почему он перестал урезаться?
3. как вставить отсутствующий элемент справочника, которого нет, а в индексе он есть?

Заранее спасибо за ответы.
PS 1C 8.2.19.130 УПП 1.3.77.2. Пишу очень подробно, т.к. любая незначительная на первый взгляд деталь может повлиять на результат.
1 DmitrO
 
06.07.16
10:54
и что только не придумают люди чтобы развлечься )
перенести "образ" серверной ос, да еще и вместе с базой, это же было так необходимо
2 PVS_Mtl
 
06.07.16
10:57
(1) Вы считаете, причина в этом? Что теперь можно сделать?
3 Мимохожий Однако
 
06.07.16
11:01
Откатывай назад, настрой новый сервер, перенеси данные через выгрузку данных
4 PVS_Mtl
 
06.07.16
11:01
*2.1. ошибки неконсистентности данных (inconsistensy was detected...)... Один раз при обновлении статистик было указано имя объекта основной бд и база TEMPDB (!)
5 DmitrO
 
06.07.16
11:09
(2)я думаю что разработчики MSSQL сервера поперхнутся, когда будут читать этот пост и дойдут до пункта 2.5
и скажут: эээууу!!! -Выпороть лентяев!

Установите серверную ОС и MSSQL как положено, он еще может при установке скажет что у вас с диском проблемы!
6 PVS_Mtl
 
06.07.16
11:12
(5) Руководство опасается переустановки MsSql из опасений, что он вообще не поднимется после этого.
7 PVS_Mtl
 
06.07.16
11:16
(5) можно ли без переустановки определиться с причиной проблем и как это сделать?
8 DmitrO
 
06.07.16
11:19
(6)да почему он не поднимется то, откуда такие опасения?
9 DmitrO
 
06.07.16
11:24
И еще, журнал транзакций регулярно не урезать надо а попросту бекапить.
10 VrotKampot
 
06.07.16
11:50
День добрый! Присоединяюсь к PVS_Mtl, в лице админа. Ну по поводу переноса сервака- пришлось так делать, по поводу с базой - базу выгружали/загружали стандартными способами.
11 МешочекЗнаний
 
06.07.16
11:58
(10) Пришлось чтоб время сэкономить? Устанавливайте по нормальному и ось и скуль.
12 DmitrO
 
06.07.16
11:59
(10)вы образ ОС не этим https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx ли волшебным инструментом получали? ну или подобным.
Суть вопроса: находу была ос когда образ получали или нет?
13 VrotKampot
 
06.07.16
12:01
И время сэкономить тоже. Одна из причин

Всё же просим помощи в решении проблем с неконсистентностью, а так же способом безболезненной отмены незавершённой транзакции, мешающей усечению лога (переустановку сервера и скуля не предлагать - нереальный вариант в нашем случае). Тем более других проблем никаких нет. Ни с ОС ни с 1С сервером.

P.S.: прошу не забывать про обновления конфигураций, которые проводят другие специалисты.
14 VrotKampot
 
06.07.16
12:03
Образ снимался акронисом, на выключенной машине.
15 PVS_Mtl
 
06.07.16
12:06
(8) Опасения наверное в том, что неясны причины возникновения ошибок неконсистентности.
Кстати, по поводу незавершенной транзакции, которая появилась в минувшую пятницу и мешает усечению лога. Нашли ветку http://www.sql.ru/forum/1029778-2/dbcc-opentran-chto-dalshe кто из специалистов может прокомментировать?
16 VrotKampot
 
06.07.16
12:07
Практики по этому вопросу очень много, никаких проблем никогда не было. Единственный косяк в том, что скуль иногда в логах проскакивает строка с сообщением о неизвестном типе процессора. Влияет ли это на работу базы и запись значений в неё из 1С пока не ясно.
17 DmitrO
 
06.07.16
12:09
тогда
- базу выгрузить в dt
- на MSSQL базу удалить;
- MSSQL перезапустить чтобы пересоздалась tempdb
- создать создать заново пустую базу
- загрузить в нее из dt

Если после этого будут ошибки неконсистентности, то MSSQL сервер попросту работает не правильно, ибо на только что загруженной базе их не может быть ну никак - переставлять все как положено.

Либо действительно проблемы с диском..
18 PVS_Mtl
 
06.07.16
12:13
(17) а почему он может работать неправильно? Что могло с ним случиться?
Стоит ли сейчас пытаться урезать лог как описано в ссылке? Настораживает, что репликация не настроена, а
Replicated Transaction Information:
        Oldest distributed LSN     : (0:0:0)
        Oldest non-distributed LSN : (1269938:16600:1)
19 DmitrO
 
06.07.16
12:23
(18)(15) что, так сильно хочется журнал обрезать? это же не главная проблема, вам же не до нее должно быть пока что.
сценарий в (17) все равно все пересоздаст заново.
20 PVS_Mtl
 
06.07.16
12:29
(19) хочется понять причину, из-за чего всё это началось. Иначе сделаем все как в 17, а спустя время вернемся к тому, с чего начали.
21 PVS_Mtl
 
06.07.16
12:32
(19) другими словами, если мы пересоздадим базу из dt, мы исключим факторы, "находящиеся" внутри возможно подпорченной базы. А если база изначально при переносе на новый сервер была нормальной, значит что-то её портит извне, а не изнутри.
22 DmitrO
 
06.07.16
12:32
(18) если репликация транзакций не настроена (а откуда ей там взяться..), то такого сообщения эта команда выдавать не должна..
23 PVS_Mtl
 
06.07.16
12:45
(22) Не настроена, но прежние админы могли как и в указанной ссылке экспериментировать с ней. Наверное, стоит sp_removedbreplication 'BD', 'tran' ?
Плюс почему строка в справочник не закачивается? В таблице указанных значений нет. Поможет ли перестройка индекса?
24 PVS_Mtl
 
06.07.16
13:04
(23) Последовательная перестройка всех уникальных индексов на указанном справочнике помогла, и запись загрузилась.
Остаются актуальными вопрос об урезании лога (будем пытаться sp_removedbreplication 'BD', 'tran') и устранения причины неконсистентности данных.
Вариант с загрузкой dt понятен.
Что может быть причиной регулярного возникновения неконсистентности (последнее вчера)?
25 DmitrO
 
06.07.16
13:11
(23) а что sp_repltrans выдает?
26 PVS_Mtl
 
06.07.16
13:16
(25) Unable to execute procedure.The database is not published.
27 DmitrO
 
06.07.16
13:28
выполните тогда DBCC CHECKDB чтобы увидеть ошибки в вашей базе.
28 PVS_Mtl
 
06.07.16
13:37
делали, исправляет процентов 90% - остается 3-5 ошибок, исправить которые даже с потерей данных эта команда не может. Их-то и правили вручную обнулением больших значений.
Но они регулярно появляются вновь, чего до переезда на новый сервер не было.
29 DmitrO
 
06.07.16
13:41
на нормально установленном сервере это указывает на проблемы с дисковой системой (диск/рейд контроллер)
30 DmitrO
 
06.07.16
13:42
ну либо отключение питания :)
31 PVS_Mtl
 
06.07.16
14:02
План действий следующий:
1. проверяем диск на ошибки.
2. обновляем 2005 sql server до sp4.
3. изменяем тип процессора на поддерживаемый sql server.
4. всех пользователей выгоняем, выгружаем dt.
5. перезапускаем sql server для чистки tempdb.
6. создаем новую базу с другим именем, в неё выгружаем dt, проверяем на ошибки.
7. переименовываем старую рабочую.
8. переименовываем новую рабочую, загруженную из dt.
32 PVS_Mtl
 
06.07.16
14:02
Если не поможет, остается переустановка всего.
33 PVS_Mtl
 
07.07.16
14:45
Промежуточные результаты подготовки:
1. лог усекли, помог рецепт из ссылки
sp_removedbreplication 'BD', 'tran'
Остается загадкой, откуда взялись транзакции репликации.
2. таблица, на которой перестраивали индексы с целью закачки пропавшего значения, оказалась сегодня испорченной - это показывает и Checktable, и при попытке перестроения кластерного индекса выдается Possible index corruption detected.
3. dt за позавчера в чистую экспериментальную БД на новом сервере не развернулся с той же ошибкой Possible index corruption detected.
4. dt за вчерашний день в чистую экспериментальную БД на СТАРОМ сервере не развернулся с ошибкой "Ошибка формата потока".

Собираемся вначале исправить все ошибки неконсистентности, затем переходить к плану.
34 Ёпрст
 
07.07.16
14:54
Продолжайте наблюдение
35 PVS_Mtl
 
07.07.16
14:59
(34) Вы намекаете, что результат наблюдений уже известен и бессмысленно всем этим заниматься? Просьба привести конкретные предложения.
36 Ёпрст
 
07.07.16
15:05
(35) ерундой какой-то занимаетесь. Всего то надо было - сделать бекапы (которые и так должны делаться регламентом каждый день) SQL , поднять новый сервак, восстановить базы из бекапов sql от старого сервера. Усё.
Если на серваке у вас помимо скуля, еще и ад какой-нить крутился - тогда поднять запасной контрол1ёр, передать ему роли, потом взад.
А так, создание образов..это полный ПЭ.
37 Ёпрст
 
07.07.16
15:05
Я б еще понял, у вас там вмваре стоял, там да, один раз слепил и клонируй
38 Ёпрст
 
07.07.16
15:06
На данный момент, делал бы как в (17)
39 Ёпрст
 
07.07.16
15:07
ну и скуль бы ставил, хотя бы 2012
40 PVS_Mtl
 
07.07.16
15:21
(38) Как в (17) не получается, ошибка формата потока при загрузке dt+ошибка Possible index corruption detected.
41 PVS_Mtl
 
07.07.16
15:22
(39) 2012 не куплен, есть только 2005.
42 Ёпрст
 
07.07.16
15:23
(40) самих скулевых архивов, нема ?
43 Ёпрст
 
07.07.16
15:23
бекап базы, кто-нить делает у вас ?
44 PVS_Mtl
 
07.07.16
15:25
(43) есть sql бекапы
45 Ёпрст
 
07.07.16
15:30
(44) дык разверните его на новом сервере в новую базу, тоже не работает ?
46 DmitrO
 
07.07.16
15:56
(40)ну блин.. ошибка формата потока при загрузке в чистую базу

Надо попробовать залить этот dt на другой сервер: тем же релизом 1С, и с таким же релизом MSSQL.

Поставьте на отдельный комп с обычным винтом. Не надо стесняться что нет лицензий, на попробовать это не грех, отмолите. :)

Если зальется, боевой сервер в переплавку, ну или можно долго еще баловаться.

Я же говорю развлечение.
47 DmitrO
 
07.07.16
16:01
Кроме того, вместо 8.2.19 давно надо использовать 8.3.6 как минимум.
48 VrotKampot
 
07.07.16
18:26
Сделали бэкап базы через скуль, проверили базу на виртуальном сервере на ошибки - опять ошибки неконсистентности, перенесли на старый сервер, развернули, проверили - абсолютно теже ошибки. Остаётся править вручную базу...опять.
49 DmitrO
 
11.07.16
17:39
(48)ну разумеется если в базе есть ошибки неконсистентности, то они попадут в бекап и после восстановления базы из этого бекапа они останутся и новой базе.
Я же писал в (46) через выгрузку/загрузку (dt файл средствами 1С) получить новую базу. Вот тогда 1С вам заново все данные в новые экземпляры таблиц разложит, а MSSQL место под них заново выделит в новом файле БД.
50 PVS_Mtl
 
13.07.16
10:51
(49) через dt не получилось. Пробовали на 2 сервера (старый и новый). Вышли ошибки (40). checkdb помимо ошибок неконсистентности выдает также ошибки размещения экстентов (allocation), которые успешно исправляет. Однако при нормальной работе sql server их не должно регулярно возникать вновь. В каком порядке лучше проделать:
переустановка sql server
реструктуризация таблиц средствами 1С
?
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший