Медленная работа nbackup из-под виндового шедулера

Добрый день!
Помогите разобраться с проблемой долгой работы nbackup из-под виндового шедулера

Имеется железо:
Сервер: HP ProLiant DL580 G5 (24 ядра 4x6)
Процы: Intel(R) Xeon(R) CPU X7460 @ 2.66GHz
Дисковая подсистема: P800 RAID-10 (10 шт SAS 300Гб 15K)
Оперативка: 16Гб

Софт:
Microsoft Windows Server 2008 Enterprise (x86)
Classic V2.5.1.26351 Firebird 2.5 (x86)

База ~700Гб
Количество коннектов днем ~100, ночью 2..10 (малоактивных)
Сервер обслуживает только одну базу, никаких других задач на нем нет.

Итак:
Nbackup 3-го уровня запускается в 1 ночи:
..\nbackup.exe -u SYSDBA -p пароль -D OFF -B 3 localhost:E:\Database\data.gdb d:\...\data_%date%_%time%-3.gbk

Ручной пуск с FAR-а: 1ч 10м
Через шедулер из под того-же пользователя: 12ч 15м

Эксперимент выполнялся 5 раз в разные дни, разлет ручного пуска +- 15 мин, шедулерного пуска +- 3ч

Вопрос: Почему из-под шедулера так долго? Заподозрил что каким-то образом не используется файловый кэш (админы разводят руками, "это все ваш Firebird тупит мы тут не при чем").

Изменил параметры (убрал -D OFF) nbackup на
..\nbackup.exe -u SYSDBA -p пароль -B 3 localhost:E:\Database\data.gdb d:\...\data_%date%_%time%-3.gbk

Что ручной пуск что через шедулер 2ч 15м +-15м

И вся бы всех устраивало и так и дальше работало если бы этой ночью не возник рабочий аврал и большая ночная нагрузка. В итоге nbackup не отработал до этого времени (17ч), размер дельты 25Гб, а в логах впервые за многие годы "internal Firebird consistency check (can't continue after bugcheck)"

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

Жду советов... идей...
Заранее благодарен.

P.P.S Мысли по "internal Firebird consistency check (can't continue after bugcheck)" тоже приветствуются.
Если че, читаю http://www.sql.ru/forum/actualthread.aspx?tid=961286 ... скоро буду орать что виноват nbackup

Viktor_bs
P.P.S Мысли по "internal Firebird consistency check (can't continue after bugcheck)" тоже приветствуются.

что в логе перед этим?

HP_2009 Wed Aug 15 15:06:22 2012
Database: E:\DATABASE\DATA.GDB
deadlock
internal Firebird consistency check (Can't lock alloc table for writing)

HP_2009 Wed Aug 15 15:06:22 2012
Cannot dump the monitoring data
I/O error during "GetFileSize" operation for file "E:\DATABASE\DATA.GDB"
Error while trying to access file
The handle is invalid.


HP_2009 Wed Aug 15 15:06:40 2012
INET/inet_error: read errno = 10054

(10-к 10054)

HP_2009 Wed Aug 15 15:13:01 2012
Database: E:\DATABASE\DATA.GDB
internal Firebird consistency check (can't continue after bugcheck)

Viktor_bs
размер дельты 25Гб

я бы задумался об оптимизации приложений.

Viktor_bs
Что ручной пуск что через шедулер 2ч 15м +-15м

чтение 97 мегабайт в секунду. с одной стороны вроде ок, с другой стороны, сомнения берут, для raid 10 из 10 дисков.

kdv
я бы задумался об оптимизации приложений. чтение 97 мегабайт в секунду. с одной стороны вроде ок, с другой стороны, сомнения берут, для raid 10 из 10 дисков.

По 1. Большая информационно-аналитическая база. Ночью шли расчеты с вставкой большого количества (10-ки млн записей), а поскольку в это время шел инкрементный бекап, потому и такая дельта.
Больше интересует почему из-под шедулера такие тормоза.

По 2. Ну ХЗ. Я год назад общался с Владом (hvlad) на одном из форумов на тему медленного бекапа, в итоге он намекнул на мои руки, я спорить не стал.
Файловое копирование идет очень быстро.

З.Ы. Это конечно же пока особо ни о чем не говорит, но gfix на копии наводит на мысли о ссылке на чужой пост в первом моем сообщении
..\bin\gfix.exe -validate -full -user sysdba -password пароль localhost:E:\DBCopy\data_err.gdb

Index [X] is corrupt (missing entries) in table [Y]

Viktor_bs
База ~700Гб <...> Если че, читаю http://www.sql.ru/forum/actualthread.aspx?tid=961286

А вчитывались ? там не с потолка кое-что, а выстраданное на соб. шкуре...

Viktor_bs
Classic V2.5.1.26351 <...> Это конечно же пока особо ни о чем не говорит, но <...> Index [X] is corrupt (missing entries) in table [Y]

Увы, но это как раз говорит о том, что в V2.5.1.26351, датированном 04-oct-2011, бага CORE-3515 осталась не убитой
Хотя в трекере сказано, что "Resolved" (15/Jun/11 09:48 AM).

Viktor_bs
Итак: Nbackup 3-го уровня запускается в 1 ночи: ..\nbackup.exe -u SYSDBA -p пароль -D OFF -B 3 localhost:E:\Database\data.gdb d:\...\data_%date%_%time%-3.gbk

Какой, к чёрту, localhost и gdb ???

Как можно к БД в 700гиг подпускать людей, нихрена не понимающих в предмете ?

Я плакаль...

Viktor_bs
Я год назад общался с Владом (hvlad) на одном из форумов на тему медленного бекапа, в итоге он намекнул на мои руки, я спорить не стал

Для того, чтобы я делал такие намёки, мне нужно дать серьёзный повод.
Ссылку на то общение можешь дать ? Перечитаю ещё раз

Viktor_bs
З.Ы. Это конечно же пока особо ни о чем не говорит, но gfix на копии наводит на мысли о ссылке на чужой пост в первом моем сообщении ..\bin\gfix.exe -validate -full -user sysdba -password пароль localhost:E:\DBCopy\data_err.gdb Index [X] is corrupt (missing entries) in table [Y]

1. А делали ли подобную проверку до нынешних проблем ? А то мало ли когда индекс сломался...
2. После bugcheck'а такие ошибки теоритически возможны. Перестройка индекса это исправит.