none
ошибка при архивации SQL RRS feed

  • Общие обсуждения

  • Коллеги, доброго дня.

    Есть проблема.

    DPM 2010, SQL 2005 в  кластере

    При выполнении архивации баз SQL-кластера, зависает кластер, точнее сказать активный узел кластера. Причем ping на него проходит, поэтому не происходит переключения на другой узел. Соответственно в DPM дается ошибка Recovery Point Creation Failed.

    Что посоветуете?


    • Изменен тип Yegor StartsevModerator 4 февраля 2013 г. 7:31 отсутствие активности
    22 ноября 2011 г. 7:21

Все ответы

  • Небольшой комментарий.

    Выяснил, что ошибка возникает при архивации только 1 БД из всех.(если ее не включать в Protection Group - все работает хорошо)

    Проверил ее на целостность средствами SQL - все ОК

    Так же могу выполнить BAckUP этой БД средствами SQL, но нужно чтобы BackUp шел через DPM.

    Так что ясности не прибавилось, ошибка присутствует.

    Помогите разобраться.


    • Изменено NSerg 22 ноября 2011 г. 8:37
    22 ноября 2011 г. 7:52
  • Чем данная база отличается от других? Дайте подробностей по размеру, расположению и тд

    Что в журналах SQL на момент создания точки восстановления?


    My DPM blog ystartsev.wordpress.com
    23 ноября 2011 г. 12:02
    Модератор
  • В том-то и дело, что ничего особенного в ней нет.

    Больше скажу, что архивирование проходило успешно некоторое время после настройки. А потом появилась ошибка и обойти ее у меня не получается.

    (Примечательно, что накануне появления ошибки я не менял никаких настроек и не устанавливал обновлений)

    А теперь по существу.

    Группа баз данных находится под управлением кластера SQL 2005 на внешнем хранилище. Используются недавно, поэтому размер у них не большой: 90-130 Mb. Размер сбойной базы 115 Mb, т.е. она даже не самая большая :(

    Места для Protection Group выделил почти в 100 раз больше суммарного объема баз.

    Если сбойная база не включена в Protection Group, то бэкап Protection Group (т.е. остальных БД) проходит успешно.

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

    БД называется - SharePoint_Config02

    эксперимент проводил с 12:45 до 13:40

    Лог кластера sql, где хранится БД прилагаю:

    11/25/2011 13:50:31,spid26s,Unknown,Starting up database 'SharePoint_Config02'.
    11/25/2011 13:20:25,spid3s,Unknown,SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [I:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\SharePoint_Config02_log.LDF] in database [SharePoint_Config02] (8).  The OS file handle is 0x0000000000000B80.  The offset of the latest long I/O is: 0x000000063c3200
    11/25/2011 12:59:24,spid3s,Unknown,SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [I:\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\SharePoint_Config02_log.LDF] in database [SharePoint_Config02] (8).  The OS file handle is 0x0000000000000B80.  The offset of the latest long I/O is: 0x000000063bf000
    11/25/2011 12:58:47,Backup,Unknown,Database backed up. Database: SharePoint_Config02<c/> creation date(time): 2011/06/17(11:49:40)<c/> pages dumped: 1<c/> first LSN: 6866:4695:67<c/> last LSN: 6866:4723:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{B71D5D24-2036-4362-88B8-DEF2054FD8CA}1'}). This is an informational message only. No user action is required.
    11/25/2011 12:58:46,spid69,Unknown,I/O was resumed on database SharePoint_Config02. No user action is required.
    11/25/2011 12:58:46,spid69,Unknown,I/O is frozen on database SharePoint_Config02. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.
    11/25/2011 12:43:46,spid26s,Unknown,CHECKDB for database 'SharePoint_Config02' finished without errors on 2011-11-22 15:59:42.133 (local time). This is an informational message only; no user action is required.
    11/25/2011 12:43:46,spid26s,Unknown,Recovery is writing a checkpoint in database 'SharePoint_Config02' (8). This is an informational message only. No user action is required.
    11/25/2011 12:43:46,spid26s,Unknown,Starting up database 'SharePoint_Config02'.
    11/25/2011 11:37:38,spid25s,Unknown,CHECKDB for database 'SharePoint_Config02' finished without errors on 2011-11-22 15:59:42.133 (local time). This is an informational message only; no user action is required.
    11/25/2011 11:37:37,spid25s,Unknown,Starting up database 'SharePoint_Config02'.

     

    25 ноября 2011 г. 10:26
  • Если системным монитором глянуть в момент резервного копирования на основные показатели диска, что-то необычное будет заметно?
    My DPM blog ystartsev.wordpress.com
    23 декабря 2011 г. 7:37
    Модератор
  • Если смотреть с активного узла кластера - ничего необычного - диск (общий ресурс кластера) просто теряется и все.

    Такое впечатление что процесс архивации данной базы зацикливается: идет постоянная попытка что-то сохранить, но процесс не заканчивается ни с результатом, ни с ошибкой (между сервером dpm и архивируемым сервером в этот момент информация по сети не передается)

    17 января 2012 г. 11:03