Я создаю куб в службах SQL Server Analysis Services, который использует локальный экземпляр SQL Server в качестве источника данных. Основная часть данных в источнике данных - это большая таблица фактов (~ 200 ГБ), которая слишком велика для локального жесткого диска, поэтому я переместил файлы .mdf и .ldf для этой базы данных на внешний жесткий диск USB. Я хочу сохранить эти файлы на внешнем жестком диске, но сохранить обработанный куб на локальном жестком диске. Я надеюсь, что, хотя это замедлит обработку куба, запросы куба все равно будут быстрыми при подключении клиентов.
И когда я могу обработать куб, это работает: запросы куба по-прежнему выполняются быстро, потому что запросы куба не попадают на медленный внешний жесткий диск USB. Проблема, с которой я сталкиваюсь, заключается в том, что часто, когда я перехожу к обработке куба, я получаю такие ошибки:
«Ошибка OLE DB: ошибка OLE DB или ODBC: истекло время ожидания блокировки буфера типа 2 для страницы (1: 1785), идентификатор базы данных 5 .; 42000
Зайдя в журнал событий, я вижу такие ошибки:
SQL Server обнаружил 29351 вхождение запросов ввода-вывода, для выполнения которых требовалось более 15 секунд, в файле [U: \ sqldata \ X.mdf] в базе данных [X] (5). Дескриптор файла ОС - 0x0000000000000164. Смещение последнего длинного ввода-вывода: 0x00002f4b664000
Похоже, это происходит из-за того, что жесткий диск USB работает медленно. Я не возражаю, чтобы запросы, необходимые для обработки, занимали много времени, но похоже, что SQL Server имеет жесткое ограничение на запросы ввода-вывода. Есть ли способ обойти это?
Вы можете отключить это поведение с помощью флага трассировки 830 для получения дополнительной информации. проверьте эту статью на msdn
dbcc traceon(830, -1)
или как параметр запуска, если вы хотите, чтобы он был включен постоянно: добавьте / T830 в качестве параметра запуска службы.
Поскольку у вас есть такие дешевые диски и запущенный sql server 2008, взгляните на включение сжатия страниц для всей базы данных, у вас будет небольшая нагрузка на процессор, но я бы сказал, что в вашей ситуации преимущества перевешивают минусы.
Вы также могли бы проверить диск на фрагментацию? Это может немного ускорить процесс.
(очевидно, что на самом деле дефрагментация диска, а не просто его проверка, ускорит его ....)
Поскольку вы используете SQL Server 2008, я бы посоветовал изучить возможность использования сжатия данных в таблицах хранилища данных (если вы действительно используете DW, как я предполагал из вашей формулировки). С помощью этой технологии можно разместить таблицу фактов на более высокоскоростном приводе (ах).
Убедитесь, что вы исключили файлы базы данных из любой проверки антивирусом, это может снизить производительность для больших файлов.