Кэширование таблиц

Question

[RedQuark]

Если способы заставить закэшировать конкретные таблицы в памяти mssql сервера 2008 принудительно? Или дать большой приоритет для кэширования конкретной таблицы?

Например есть таблица со списком документов, в 20 тыс. записей и она одна из главных в системе. Полная ее выборка при нагруженном сервере составляет 6 секунд, что непозволительно долго. Вызывается она через процедуру где есть suser_name(), что делает автоматическое кэширование недееспособным.

Answer 1

[rPman]

Очень давно не работал с mssql, если внутрь уже готовых функций лезть никак 9а это единственно верный способ оптимизации), то у вас есть два способа:
1. разместить таблицу в отдельном таблеспейсе на ram диске (не рекомендуется, так как в случае аварийной остановки сервера базу придется чинить, но это гарантированно разместит данные только в оперативной памяти)
2. создать таблицу в памяти (точнее в tempdb) stackoverflow.com/questions/27835/does-ms-sql-support-in-memory-tables и прилинковать через вьюху
Оба метода требуют дополнительных скриптов, по наполнению этих таблиц при перезапуске сервера а так же самое главное по сохранению изменений, ничего лучше кроме копирования изменений в нормальную таблицу тригером не приходит в голову — очень эффективно, чуть по сложнее — поднять еще одну базу и настроить репликацию (но цена вопроса — удорожание лицензии на серверный софт)

p.s. кстати две или более базы, разнесенные по серверам или даже географически могут позволить схемы, когда полностью вся база размещена в оперативной памяти.

Comments

[RedQuark]

1. Файловая группу на RAM диске это интересно, поэкспериментирую, спасибо. Плохо, что по хорошему действительно нужно делать дублера на нормальном диске и с помощью тригерного велосипеда или репликации в режиме он-лайн синхронизировать их.
2. Ну вот почему эти MS не сделали индексы в table variable? Первичный ключ есть, ограничения есть, а индексов нет. Итог, думаю, что без индексов прирост чтения в 10 раз себя не оправдает или оправдает только на маленьких табличках.

Answer 2

[lavel]

Сложно представить задачу, где на клиенте понадобятся все 20 тыс. записей в неагрегированном виде. Если по теме, то для таблицы, а также каждого из индексов этой таблицы можно создать отдельные filegroup, которые можно поместить на отдельные жесткие диски и получить почти параллельное чтение\запись.

Comments

[RedQuark]

Вы правы, но имеется ни одна такая таблица и к ней обращается по 100 процедур, разбираться правильно ли они написаны и на что надо вешать индексы ни кто не будет. Ключевых таблиц мегабайт на 100, если бы их можно было эффективно разместить в кэше, про тюниг с индексами и правильным переписыванием процедур можно забыть года на 2 минимум. Да, про файловые группы, SSD, RAID это все понятно. Можно даже целиком базу в кэше разместить, но это решение слишком радикальное.

[Пума Тайланд]

НУ поставить ssd довольно тривиально и дешево, где тут радикальность не очень понятно.

[RedQuark]

В огромных компаниях, все чрезвычайно криво устроено(может конечно так и надо), но даже вставить гиговую планку на компьютер субподрячика оказывается невероятно сложной задачей. А письма с просьбой добавить еще одно виртуальное ядро процессора натыкаются на стену причитаний, что дефицит серверных мощностей невероятный. В маленьких компаниях да, перешел дорогу, купил SSD, перенес базу и журнал транзакций на новый диск и забыл о проблеме.

Answer 3

[unfilled]

Раньше был DBCC PINTALBE, сейчас такого механизма нет (да и PINTABLE особо не рекомендовалось к использованию).
ИМХО, вы зря не хотите разбираться с запросами и индексами. «Закрепление» таблицы в памяти может вам и не помочь. Например, вы таблицу «закрепили», а пользователь бабахнул запрос с 10 кросс джойнами этой таблицы — в данном случае, вне зависимости от того «закреплена» она или нет, памяти уйдёт намного больше чем предполагалось.
Плюс, suser_name() никак на кэширование данных не влияет — почему вы считаете, что кэширование не дееспособно?

Comments

[RedQuark]

Практика показывает, что одного бесузумного крос джойна вполне хватает. Нет, задача разместить таблицу в кэше, эта функция очевидно было бы полезной, но ее нет. Задача не взята из ниоткуда, у MSSQL можно штатными средствами разместить всю базу в RAM кроме журнала транзакций (где то такое читал). По поводу suser_name(), конечно БД закэширует любую выборку, но так как пользователей около 200 и у всех эта выборка будет своя, то закэшированный запрос уже вытесниться к тому моменту когда пользователь решит выполнить ту же операцию.