Уважаемые коллеги! Помогите пожалуйста разобраться в причинах возникших ошибок и устранить их.
Ситуация следующая.
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) Вы считаете, причина в этом? Что теперь можно сделать?

Откатывай назад, настрой новый сервер, перенеси данные через выгрузку данных

*2.1. ошибки неконсистентности данных (inconsistensy was detected...)... Один раз при обновлении статистик было указано имя объекта основной бд и база TEMPDB (!)

(2)я думаю что разработчики MSSQL сервера поперхнутся, когда будут читать этот пост и дойдут до пункта 2.5
и скажут: эээууу!!! -Выпороть лентяев!

Установите серверную ОС и MSSQL как положено, он еще может при установке скажет что у вас с диском проблемы!

(5) Руководство опасается переустановки MsSql из опасений, что он вообще не поднимется после этого.

(5) можно ли без переустановки определиться с причиной проблем и как это сделать?

(6)да почему он не поднимется то, откуда такие опасения?

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

День добрый! Присоединяюсь к PVS_Mtl, в лице админа. Ну по поводу переноса сервака- пришлось так делать, по поводу с базой - базу выгружали/загружали стандартными способами.

(10) Пришлось чтоб время сэкономить? Устанавливайте по нормальному и ось и скуль.

(10)вы образ ОС не этим https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx ли волшебным инструментом получали? ну или подобным.
Суть вопроса: находу была ос когда образ получали или нет?

И время сэкономить тоже. Одна из причин

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

P.S.: прошу не забывать про обновления конфигураций, которые проводят другие специалисты.

Образ снимался акронисом, на выключенной машине.

(8) Опасения наверное в том, что неясны причины возникновения ошибок неконсистентности.
Кстати, по поводу незавершенной транзакции, которая появилась в минувшую пятницу и мешает усечению лога. Нашли ветку http://www.sql.ru/forum/1029778-2/dbcc-opentran-chto-dalshe кто из специалистов может прокомментировать?

Практики по этому вопросу очень много, никаких проблем никогда не было. Единственный косяк в том, что скуль иногда в логах проскакивает строка с сообщением о неизвестном типе процессора. Влияет ли это на работу базы и запись значений в неё из 1С пока не ясно.

тогда
- базу выгрузить в dt
- на MSSQL базу удалить;
- MSSQL перезапустить чтобы пересоздалась tempdb
- создать создать заново пустую базу
- загрузить в нее из dt

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

Либо действительно проблемы с диском..

(17) а почему он может работать неправильно? Что могло с ним случиться?
Стоит ли сейчас пытаться урезать лог как описано в ссылке? Настораживает, что репликация не настроена, а
Replicated Transaction Information:
        Oldest distributed LSN     : (0:0:0)
        Oldest non-distributed LSN : (1269938:16600:1)

(18)(15) что, так сильно хочется журнал обрезать? это же не главная проблема, вам же не до нее должно быть пока что.
сценарий в (17) все равно все пересоздаст заново.

(19) хочется понять причину, из-за чего всё это началось. Иначе сделаем все как в 17, а спустя время вернемся к тому, с чего начали.

(19) другими словами, если мы пересоздадим базу из dt, мы исключим факторы, "находящиеся" внутри возможно подпорченной базы. А если база изначально при переносе на новый сервер была нормальной, значит что-то её портит извне, а не изнутри.

(18) если репликация транзакций не настроена (а откуда ей там взяться..), то такого сообщения эта команда выдавать не должна..

(22) Не настроена, но прежние админы могли как и в указанной ссылке экспериментировать с ней. Наверное, стоит sp_removedbreplication 'BD', 'tran' ?
Плюс почему строка в справочник не закачивается? В таблице указанных значений нет. Поможет ли перестройка индекса?

(23) Последовательная перестройка всех уникальных индексов на указанном справочнике помогла, и запись загрузилась.
Остаются актуальными вопрос об урезании лога (будем пытаться sp_removedbreplication 'BD', 'tran') и устранения причины неконсистентности данных.
Вариант с загрузкой dt понятен.
Что может быть причиной регулярного возникновения неконсистентности (последнее вчера)?

(23) а что sp_repltrans выдает?

(25) Unable to execute procedure.The database is not published.

выполните тогда DBCC CHECKDB чтобы увидеть ошибки в вашей базе.

делали, исправляет процентов 90% - остается 3-5 ошибок, исправить которые даже с потерей данных эта команда не может. Их-то и правили вручную обнулением больших значений.
Но они регулярно появляются вновь, чего до переезда на новый сервер не было.

на нормально установленном сервере это указывает на проблемы с дисковой системой (диск/рейд контроллер)

ну либо отключение питания :)

План действий следующий:
1. проверяем диск на ошибки.
2. обновляем 2005 sql server до sp4.
3. изменяем тип процессора на поддерживаемый sql server.
4. всех пользователей выгоняем, выгружаем dt.
5. перезапускаем sql server для чистки tempdb.
6. создаем новую базу с другим именем, в неё выгружаем dt, проверяем на ошибки.
7. переименовываем старую рабочую.
8. переименовываем новую рабочую, загруженную из dt.

Если не поможет, остается переустановка всего.

Промежуточные результаты подготовки:
1. лог усекли, помог рецепт из ссылки
sp_removedbreplication 'BD', 'tran'
Остается загадкой, откуда взялись транзакции репликации.
2. таблица, на которой перестраивали индексы с целью закачки пропавшего значения, оказалась сегодня испорченной - это показывает и Checktable, и при попытке перестроения кластерного индекса выдается Possible index corruption detected.
3. dt за позавчера в чистую экспериментальную БД на новом сервере не развернулся с той же ошибкой Possible index corruption detected.
4. dt за вчерашний день в чистую экспериментальную БД на СТАРОМ сервере не развернулся с ошибкой "Ошибка формата потока".

Собираемся вначале исправить все ошибки неконсистентности, затем переходить к плану.

Продолжайте наблюдение

(34) Вы намекаете, что результат наблюдений уже известен и бессмысленно всем этим заниматься? Просьба привести конкретные предложения.

(35) ерундой какой-то занимаетесь. Всего то надо было - сделать бекапы (которые и так должны делаться регламентом каждый день) SQL , поднять новый сервак, восстановить базы из бекапов sql от старого сервера. Усё.
Если на серваке у вас помимо скуля, еще и ад какой-нить крутился - тогда поднять запасной контрол1ёр, передать ему роли, потом взад.
А так, создание образов..это полный ПЭ.

Я б еще понял, у вас там вмваре стоял, там да, один раз слепил и клонируй

На данный момент, делал бы как в (17)

ну и скуль бы ставил, хотя бы 2012

(38) Как в (17) не получается, ошибка формата потока при загрузке dt+ошибка Possible index corruption detected.

(39) 2012 не куплен, есть только 2005.

(40) самих скулевых архивов, нема ?

бекап базы, кто-нить делает у вас ?

(43) есть sql бекапы

(44) дык разверните его на новом сервере в новую базу, тоже не работает ?

(40)ну блин.. ошибка формата потока при загрузке в чистую базу

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

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

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

Я же говорю развлечение.

Кроме того, вместо 8.2.19 давно надо использовать 8.3.6 как минимум.

Сделали бэкап базы через скуль, проверили базу на виртуальном сервере на ошибки - опять ошибки неконсистентности, перенесли на старый сервер, развернули, проверили - абсолютно теже ошибки. Остаётся править вручную базу...опять.

(48)ну разумеется если в базе есть ошибки неконсистентности, то они попадут в бекап и после восстановления базы из этого бекапа они останутся и новой базе.
Я же писал в (46) через выгрузку/загрузку (dt файл средствами 1С) получить новую базу. Вот тогда 1С вам заново все данные в новые экземпляры таблиц разложит, а MSSQL место под них заново выделит в новом файле БД.

(49) через dt не получилось. Пробовали на 2 сервера (старый и новый). Вышли ошибки (40). checkdb помимо ошибок неконсистентности выдает также ошибки размещения экстентов (allocation), которые успешно исправляет. Однако при нормальной работе sql server их не должно регулярно возникать вновь. В каком порядке лучше проделать:
переустановка sql server
реструктуризация таблиц средствами 1С
?