Здравствуйте, уважаемые товарищи!!!

Прошу о помощи!

Имею Win. server 2008 stand., SQL 2008 R2.
Развернута база 1с 8.2.
Запускается обработка по обмену данными, пользователи заходят, создают-изменяют справочники-документы.
Не давно были перепады с напряжением.
Теперь при открывании документов и обработки по обмену, выдает ошибку:

http://files.mail.ru/ED2C375A476B4FBAB78A02176D5605E3?t=1

Я никогда с самим SQL не работал, но видимо повредилась сама база? Следовательно стоит сделать её проверку и исправление?

Если это поможет, прошу подскажите, как сделать это исправление? Или дело может быть в другом?


Заранее примного благодарен!!!

Ссылка на ошибку (картинка):
http://files.mail.ru/ED2C375A476B4FBAB78A02176D5605E3

А сам то этот текст ошибки читал? Там же все разжевано. И даже написано, что делать. И еще резонный вопрос: бэкап есть?

Ну DBCC CHECKDB жи есть :)

(0) Проверку стоит сделать - DBCC CHECKDB без доп. параметров и посмотреть что за ошибки (например здесь http://habrahabr.ru/post/136979/ ), потом уже по ситуации.
Плюс, посмотреть что в журналах ошибок SQL Server (как, собственно и написано в сообщении об ошибке).

Запустил DBCC CHECKDB (база)...

База в 5 ГБ примерно, сколько времени будет проверяться?

Бэкапов нет((((

вот раньше говорили, что админы делятся на тех, кто ещё не делает бекапы и тех, кто делает бекапы.
Теперь появилась третья часть - те, кто периодически проверяет как сделались бекапы

(6) Я к сожалению, не админ(((

Поэтому после завершения запроса никак не пойму, что это все означает (пример красных строк)?

Сообщение 8939, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор объекта 0, идентификатор индекса -1, идентификатор секции 0, идентификатор единицы размещения -1152659564975816704 (тип Unknown), страница (0:0). Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел. Значения - 12716041 и -4.
Сообщение 8939, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор объекта 0, идентификатор индекса -1, идентификатор секции 0, идентификатор единицы размещения -647565963498684416 (тип Unknown), страница (363:-930978156). Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел. Значения - 12716041 и -4.
Сообщение 8909, уровень 16, состояние 1, строка 1
Ошибка таблицы: идентификатор объекта 0, идентификатор индекса -1, идентификатор секции 0, идентификатор единицы размещения -74159023271968768 (тип Unknown), идентификатор страницы (1:628260) содержит неправильный идентификатор страницы в заголовке страницы. PageId в заголовке страницы = (44920:0).
Сообщение 8939, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор объекта 0, идентификатор индекса -1, идентификатор секции 0, идентификатор единицы размещения 36918460416 (тип Unknown), страница (50781:4356). Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел. Значения - 12716041 и -4.
Сообщение 8939, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор объекта 0, идентификатор индекса -1, идентификатор секции 0, идентификатор единицы размещения 281474976710656 (тип Unknown), страница (26:50). Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел. Значения - 12716041 и -4.
Сообщение 8939, уровень 16, состояние 98, строка 1
...
Сообщение 8928, уровень 16, состояние 1, строка 1
Идентификатор объекта 763149764, идентификатор индекса 1, идентификатор секции 72057594216775680, идентификатор единицы размещения 72057594212909056 (тип In-row data): не удалось обработать страницу (1:628257). Для получения подробных сведений просмотрите сообщения о других ошибках.
Сообщение 8976, уровень 16, состояние 1, строка 1
Ошибка таблицы: идентификатор объекта 763149764, идентификатор индекса 1, идентификатор секции 72057594216775680, идентификатор единицы размещения 72057594212909056 (тип In-row data). Страница (1:628257) не была обнаружена при просмотре, хотя ее родитель (1:516695) и предыдущая страница (1:628256) ссылаются на нее. Проверьте предыдущие ошибки.
Сообщение 8928, уровень 16, состояние 1, строка 1
Идентификатор объекта 763149764, идентификатор индекса 1, идентификатор секции 72057594216775680, идентификатор единицы размещения 72057594212909056 (тип In-row data): не удалось обработать страницу (1:628258). Для получения подробных сведений просмотрите сообщения о других ошибках.
Сообщение 8980, уровень 16, состояние 1, строка 1
Ошибка таблицы: идентификатор объекта 763149764, идентификатор индекса 1, идентификатор секции 72057594216775680, идентификатор единицы размещения 72057594212909056 (тип In-row data). Узел индекса на странице (1:516695), область памяти 85 ссылается на дочернюю страницу (1:628258) и предыдущий дочерний элемент (1:628257), но они не были найдены.
Сообщение 8928, уровень 16, состояние 1, строка 1
Идентификатор объекта 763149764, идентификатор индекса 1, идентификатор секции 72057594216775680, идентификатор единицы размещения 72057594212909056 (тип In-row data): не удалось обработать страницу (1:628259). Для получения подробных сведений просмотрите сообщения о других ошибках.
Сообщение 8980, уровень 16, состояние 1, строка 1
Ошибка таблицы: идентификатор объекта 763149764, идентификатор индекса 1, идентификатор секции 72057594216775680, идентификатор единицы размещения 72057594212909056 (тип In-row data). Узел индекса на странице (1:516695), область памяти 86 ссылается на дочернюю страницу (1:628259) и предыдущий дочерний элемент (1:628258), но они не были найдены.
...
HECKDB обнаружил 0 ошибок размещения и 25 ошибок согласованности в базе данных "Bahus6".
repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (Bahus6).
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.


Стоит запустить с REPAIR_ALLOW_DATA_LOSS ?

(5) Но ведь ты его сделал сразу же, как увидел ошибку?

(8) Да, конечно.

(9) Тогда запускай с исправлением и надеждой на лучшее. Хуже уже не будет.

(6) На админе экономят, типа если работаешь с 1с, то и сопутствующие ошибки тоже разгребать((((

Эх, братцы, благославите, иду на риск, времени не так уж много...

Кстати, отыскался недельный МДФ, делался методом отключения- копирования-подключения, но и там обещали, те же самые ошибки...

...ну, что же, тестирование с исправлением сделал. База задышала (вздыхаю с облегчением). Буду продолжать мониторить работу.

Спасибо всем за поддержку и участие!!!

Настрой уже резервное копирование. У меня, например, хранятся ежедневные копии базы, которые делаются таким скриптом SQL Agent:
DECLARE @CurrentFileDate char(10)
        , @BackupFile varchar(255)

SET @CurrentFileDate = CONVERT(char(10),getdate(),121)
SET @BackupFile = 'U:\SQL-Back\Dobr14-'+@CurrentFileDate + '.bak'

BACKUP DATABASE Dobr14
    TO  DISK = @BackupFile
WITH
    NOFORMAT,
    NOINIT,  
    NAME = N'Dobrusha2014-Full Database Backup',
    SKIP,
    RETAINDAYS = 20,
    STATS = 10;
GO

Старые удаляются ежедневно запускаемым (автоматически, разумеется) батничком:

forfiles /p U:\SQL-Back\ /d -10 -S -m *.* -C "cmd /c del @file"

(14) а чем мэйнтененс плэн не устроил?

(15) Так исторически сложилось. Про планы обслуживания тогда не знал. А в чем разница-то? Можно без агента обойтись?

(17) без агента то никак. просто удобнее в нем все сделать, если нет своей специфики (copy only тот же - в плане обслуживания такого кажется выбрать нельзя). да и когда когда не одна база - указал нужные и все. а батник откуда стартуется? из планировщика виндового?

упс. (17) к (16)

(15) На всякий случай сообщаю: майтансе планы будут удалены из sql server и останутся только джобы. Так, что лучше делать сразу джобами :)

(19) с фигали?) или мелкософт планирует обновляшки? сидим на 2008. пока слазить с него не планировали. да и мейнтенес плэн как раз джобы и создает. или я не прав?