добрый день. Управление торговлей, редакция 11 (11.5.17.185). MS SQL 2014.
Перенесли базу с одного сервера на другой через выгрузку загрузку dt. через несколько дней выявили проблему, что БД не удается выгрузить или протестировать.
При тестировании или выгрузке выдает ошибку: "Запись каталога не обнаружена для идентификатора секции 72339071758893056 в базе данных 5. Метаданные несогласованы. Запустите DBCC CHECKDB, чтобы выполнить проверку метаданных на повреждение."
DBCC CHECKDB выдает такую же ошибку.
При этом БД работает, бэкапы sql сервером создаются. Мож кто побеждал такое?
Перенесли базу с одного сервера на другой через выгрузку загрузку dt. через несколько дней выявили проблему, что БД не удается выгрузить или протестировать.
При тестировании или выгрузке выдает ошибку: "Запись каталога не обнаружена для идентификатора секции 72339071758893056 в базе данных 5. Метаданные несогласованы. Запустите DBCC CHECKDB, чтобы выполнить проверку метаданных на повреждение."
DBCC CHECKDB выдает такую же ошибку.
При этом БД работает, бэкапы sql сервером создаются. Мож кто побеждал такое?
По теме из базы знаний
- Исследование использования СУБД (MS SQL, PostgreSQL, Oracle, IBM DB2) с отраслевыми конфигурациями на платформе 1С:Предприятие
- Скорость работы 1С: Предприятие с разными СУБД: MS SQL и с PostgreSQL
- Workaround me в 1С/MS SQL и не только, системный подход к созданию костылей
- Мигрируем с MS SQL на PostgreSQL
- Восстановление базы или решение проблемы Ошибка СУБД: Microsoft SQL Server
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(4)
Не горячитесь. data_loss это то, что может всплыть, скажем, через 7 месяцев.
Вы из какого бэкапа будете тогда восстанавливаться?
Это я к тому, что сперва стоит попробовать ALL_ERRORMSGS и вдумчиво почитать.
Кроме того, насколько помню, DBCC CHECKDB выдает рекомендуемый уровень восстановления.
Может достаточно REPAIR_REBUILD.
Ну и не забываем все это оборачивать в транзакцию, на всякий случай.
А вообще, в таких случаях я бы обратился к DBA, наверняка там много нюансов, я, например, их не знаю.
А так в тексте команды всё написано, здесь же не выпускники детского сада
Не горячитесь. data_loss это то, что может всплыть, скажем, через 7 месяцев.
Вы из какого бэкапа будете тогда восстанавливаться?
Это я к тому, что сперва стоит попробовать ALL_ERRORMSGS и вдумчиво почитать.
Кроме того, насколько помню, DBCC CHECKDB выдает рекомендуемый уровень восстановления.
Может достаточно REPAIR_REBUILD.
Ну и не забываем все это оборачивать в транзакцию, на всякий случай.
А вообще, в таких случаях я бы обратился к DBA, наверняка там много нюансов, я, например, их не знаю.
(13)
Все же похоже на глюк СУБД неверную работу хранимки или чего-то такого.
Предлагать запускать профайлер не буду, т.к. черт там ногу сломит, если делать выгрузку.
Ну, попробуйте что ли выгрузить через РИБ в дочернюю базу и там сделать ТИС.
Но, даже, если это заработает, не факт, что все объекты вашей базы в принципе имеют регистрацию в планах обмена.
У меня идеи закончились ;)
средствами SQL, напоминаю, бэкапы SQL создаются
Все же похоже на глюк СУБД неверную работу хранимки или чего-то такого.
Предлагать запускать профайлер не буду, т.к. черт там ногу сломит, если делать выгрузку.
Ну, попробуйте что ли выгрузить через РИБ в дочернюю базу и там сделать ТИС.
Но, даже, если это заработает, не факт, что все объекты вашей базы в принципе имеют регистрацию в планах обмена.
У меня идеи закончились ;)
(15) Да. Я не силен в запросах SQL. Как я понял, на шаге 3, по идентификатору секции я должен вычислить имя таблицы ('YourTableName') и имя индекса [YourIndexName], но данный запрос:
SEL ECT *
FR OM sys.partitions
WHERE partition_id = 72057594967228416;
ничего не находит
SEL ECT *
FR OM sys.partitions
WHERE partition_id = 72057594967228416;
ничего не находит
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот