Подскажите по бекапам sql #763876

файл бекапа bak весит больше 100Гб, хотя база небольшая. Я так понимаю, в этот один файл записываются ночные бекапы - дописываются? как в скуле восстановить бд из этого бекапа?

и подскажите пжл, есть ли в скуле что-то типа ТИИ. база ругается на страница в базе данных с идентификатором 9 помечена RestorePending что может обозначать повреждение диска. Чтобы вернуться к обычному состоянию выполните процедуру по востановлению

в sql есть настройка время жизни бекапа.

DBCC CHECKDB но данной процедурой нужно пользоваться с умом - можно потереть данные.

я на копии

пишу DBCC CHECKDB ('1c444', REPAIR_REBUILD) GO пишет Инструкция восстановления не обработана. База данных должна находиться в однопользовательском режиме. Перевести в автономный режим?

или отсоединить?

проверить диск, место на винтах запустить dbcc checkdb для начала с All_ErrorMsgs

ALTER DATABASE BAZA SET SINGLE_USER DBCC CheckDB ALTER DATABASE BAZA  SET MULTI_USER

ALTER DATABASE 1c444 SET SINGLE_USER Сообщение 102, уровень 15, состояние 1, строка 2 Неправильный синтаксис около конструкции "1".

сейчас последние версии скуля содержат в бекапе лог, и позволяют восстанавливать на почти любую точку

это начиная с какой версии? Всегда разностные бекапы настраивал сам.

точнее бекапы логов

ALTER DATABASE 1c444 SET SINGLE_USER Сообщение 102, уровень 15, состояние 1, строка 1 Неправильный синтаксис около конструкции "1".

что имеешь в виду? full backup + backup логов + лог = восстановление на любую дату после full backup, так это всегда было. или что то новое придумали?

GO ALTER DATABASE AdventureWorks2012 SET SINGLE_USER WITH ROLLBACK IMMEDIATE или сделай в менеджмент студии. см

Офигели человеку сразу DBCC CHECKDB  давать?

я в менеджмент и есть

я с удовольствием почитаю все эти полезные ссылки. но - завтра. а сегодня нужно как-то эту базу восстановить

ай молодец... :)!

GO ALTER DATABASE 1c444 SET SINGLE_USER WITH ROLLBACK IMMEDIATE Сообщение 102, уровень 15, состояние 1, строка 1 Неправильный синтаксис около конструкции "1". Сообщение 102, уровень 15, состояние 1, строка 3 Неправильный синтаксис около конструкции "IMMEDIATE". это в скуль менеджмент студио, БД - задать запрос

у меня все отрабатывает.

может не правильно имя базы пишишь?

разобрался. GO ALTER DATABASE "1c444" SET SINGLE_USER DBCC CHECKDB ('1c444',repair_allow_data_loss)

ALTER DATABASE [1c444] SET SINGLE_USER WITH ROLLBACK IMMEDIATE Он не понял, что это имя базы.

базу так можно грохнуть. лучше вначале с параметром All_ErrorMsgs было запускать

DBCC CHECKDB ('1c444',repair_allow_data_loss) Лучше сначала просто проверить, без исправления. Чтобы узнать, что конкретно сломано.

т.е. без repair_allow_data_loss

оно выдает 10 листов сообщений

он уже все забабахал :) но ведь это не просто так, почитай те же теперь только ТИИ

Там большая часть ни о чем, надо красные сообщения смотреть (реальные ошибки). Главное понять, что за объекты испортились, без этого неясно, как восстанавливать. Если повезло, просто какие-нибудь индексы умерли.

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

Хватило же дури базу с цифирки обозвать :)

пытаюсь рабочую поставить в режим синг - повисло выполнение запроса

ALTER DATABASE BAZA  SET MULTI_USER

не трогай рабочую!!!

мне нужно как-то рабочую реаниминировать, чтобы пользователи с утра смогли работать

в рабочей: Сообщение 5069, уровень 16, состояние 1, строка 1 Не удалось выполнить инструкцию ALTER DATABASE.

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

запустил ТИИ в копии. проверка ссылочной и лог целостности. все ок

еще есть время. вначале надо убедится, что ты не сделал хуже.

скорее всего в ней кто то сидит.

знать бы кто, консоль серв 1С зависает

размер базы, версия sql, версия 1с, что сделали

ну и было бы хорошо

GO DBCC CHECKDB ('1c4') WITH ALL_ERRORMSGS

Результаты DBCC для "1c4". Сообщение 9675 компонента Service Broker, состояние 1: Проанализировано типов сообщений: 14. Сообщение 9676 компонента Service Broker, состояние 1: Проанализировано контрактов службы: 6. Сообщение 9667 компонента Service Broker, состояние 1: Проанализировано служб: 3. Сообщение 9668 компонента Service Broker, состояние 1: Проанализировано очередей служб: 3. Сообщение 9669 компонента Service Broker, состояние 1: Проанализировано конечных точек диалога: 0. Сообщение 9674 компонента Service Broker, состояние 1: Проанализировано групп сообщений: 0. Сообщение 9670 компонента Service Broker, состояние 1: Проанализировано привязок удаленной службы: 0. Сообщение 9605 компонента Service Broker, состояние 1: Проанализировано приоритетов диалога: 0. Результаты DBCC для "sys.sysrscols". Имеется 52407 строк на 444 страницах для объекта "sys.sysrscols". Результаты DBCC для "sys.sysrowsets". Имеется 8266 строк на 78 страницах для объекта "sys.sysrowsets". Результаты DBCC для "sys.sysallocunits". Имеется 8973 строк на 117 страницах для объекта "sys.sysallocunits". Результаты DBCC для "sys.sysfiles1". Имеется 2 строк на 1 страницах для объекта "sys.sysfiles1". Результаты DBCC для "sys.syspriorities". Имеется 0 строк на 0 страницах для объекта "sys.syspriorities". Результаты DBCC для "sys.sysfgfrag".

+ еще 7 тыс строк и Имеется 0 строк на 0 страницах для объекта "_FrmDtSettings". Результаты DBCC для "_Const11265". Имеется 1 строк на 1 страницах для объекта "_Const11265". Результаты DBCC для "_Document264". Имеется 0 строк на 0 страницах для объекта "_Document264". Результаты DBCC для "_AccumRgAggDict6h15788". Имеется 0 строк на 0 страницах для объекта "_AccumRgAggDict6h15788". CHECKDB обнаружил 0 ошибок размещения и 70 ошибок согласованности в базе данных "1c4". repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (1c4). Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

70 ошибок согласованности - сможешь их из текста вытащить? Или куда-нибудь весь лог файлом сохрани. Остальное там не нужно.

ладно, что с рабочей делать? если я загружу в неё скульный бекап из копии - взлетит?

красным: Сообщение 8964, уровень 16, состояние 1, строка 1 Ошибка таблицы: идентификатор объекта 30623152, идентификатор индекса 1, идентификатор секции 72057594358464512, идентификатор единицы размещения 72057594059685888 (тип LOB data). У внестрочного узла данных на странице (1:50693), область памяти 52, идентификатор текста 18699911168, отсутствует ссылка. Сообщение 8964, уровень 16, состояние 1, строка 1 Ошибка таблицы: идентификатор объекта 30623152, идентификатор индекса 1, идентификатор секции 72057594358464512, идентификатор единицы размещения 72057594059685888 (тип LOB data). У внестрочного узла данных на странице (1:50825), область памяти 34, идентификатор текста 18136694784, отсутствует ссылка. Сообщение 8928, уровень 16, состояние 1, строка 1 Идентификатор объекта 30623152, идентификатор индекса 1, идентификатор секции 72057594358464512, идентификатор единицы размещения 72057594059685888 (тип LOB data): не удалось обработать страницу (1:50879). Для получения подробных сведений просмотрите сообщения о других ошибках. Сообщение 8939, уровень 16, состояние 98, строка 1 Ошибка таблицы: идентификатор объекта 30623152, идентификатор индекса 1, идентификатор секции 72057594358464512, идентификатор единицы размещения 72057594059685888 (тип LOB data), страница (1:50879). Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел. Значения - 12716041 и -6. Сообщение 8965, уровень 16, состояние 1, строка 1

подключись к копии из 1с, не трогай рабочую.

70 ошибок согласованности - похоже все плохо

Не повезло, данные потерялись. Что за таблица с ИД 30623152?. Нашел похожие проблемы . Ну и полезные обсуждения по подобным случаям (хотя там тоже не всегда правильные советы дают):

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

к копии подключиться удалось, все документы открываются проводятся? Скорее всего были потеряны данные - исчезнут элементы справочников, документы. Ну и главный вопрос: backup есть?

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

Что за таблица, все-таки? Там текстовые данные потеряны, может быть проверка их и не искала.

А база сама сколько весит? Скорее всего в файле бэкапа много копий за разные даты. В любом случае надо искать копию, в которой еще не было поломки, чтобы восстановить удаленные сейчас данные.

бекап 1с весит 600мб зачем восстанавливать данные из старого бекапа? этот вроде все данные содержит

скинул бы лог... Знаешь как определить соответствие между таблицами sql и объектами 1с?

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

ошибку можно не сразу заметить.