Я столкнулся с каким-то поведением, которое мне кажется странным. Я использую 32-разрядный SQL Server 2008 Enterprise (четырехъядерный процессор 2) в Windows 7 (для тестирования).
У меня есть хранимая процедура, использующая две переменные таблицы. В один вставляется примерно 2 или 3 строки, в другой - от 0 до 100 строк. Затем я отбираю 20-60 строк из второй, и все.
Производительность довольно быстрая. Я создал простое приложение для циклического выполнения запросов, и я могу делать 1300 / сек с 1 потоком и около 4000 с 4 потоками.
Введите tempdb: Когда я открываю монитор ресурсов, чтобы увидеть, что происходит, я вижу, что в файлы журнала tempdb много записей. (Я создал 2 100 МБ на 2 разных физических дисках - кажется, они не превышают 100 МБ.) нуль активность чтения - вся БД помещается в ОЗУ.
При выполнении запросов в одном потоке скорость записи в файлы журнала tempdb составляет около 3 МБ / с. Когда я увеличиваю это значение, он увеличивается до 20 МБ / с на файл журнала.
В мониторе активности SQL «Ведение журнала» превышает 300 мс / сек для «Время ожидания», когда я использую 5 потоков. При 3 потоках скорость снижается до 25 мс / сек.
Вопрос: В чем дело? Почему SQL пишет в журналы tempdb как сумасшедший, но выдает нулевое чтение (я не вижу активности чтения в мониторе ресурсов или в мониторе активности)? Мне кажется, что в не тестовой среде дополнительные 40 МБ / с записи могут отрицательно сказаться на общей производительности.
Я знаю, что переменные таблицы (@foo) не всегда хранятся в памяти, но я не понимаю, почему tempdb должен регистрировать все это. Как я могу устранить то, что он делает? Могу я поместить журнал tempdb на рамдиск или что-то в этом роде? Любые другие указатели?
Заранее спасибо!
Это типичный журнал писать вперед поведение. Когда страница обновляется в базе данных, обновление сначала записывается в журнал, а затем применяется к странице в памяти. Страница остается грязной в памяти до тех пор, пока не произойдет контрольная точка, после чего она будет записана на диск. Перед обновлением необходимо вести журнал для поддержки восстановления и отката. Если не произойдет одно из этих двух (восстановление или откат), нет необходимости когда-либо читать журнал снова. Таким образом, поведение, которое вы видите, типично для системы, которая изменяет страницы в tempdb. Вы увидите только чтение журнала, если произойдет откат (поскольку восстановление не может произойти для tempdb).
Более интересный вопрос: почему в базе данных tempdb происходит так много обновлений страниц? Типичными виновниками являются либо прямые обновления (например, состояние сеанса в базе данных tempdb с ASP), либо косвенные (буферизация и сортировка в планах запросов).