Как узнать статистику чтения/записи таблицы SQL Server?

есть ли способ найти статистику по количеству чтения и записи таблицы в SQL Server 2005/2008?

Я специально искал DMVs/DMFs без использования триггеров и проверок.

на цель вот чтобы узнать соответствующий коэффициент заполнения индексов - получил идею из этой статьи ( Коэффициент Заполнения Определен).

[обновление] есть продолжение up вопрос на ServerFault
как определить Чтение / запись интенсивной таблицы из DMV / DMF статистика

10
fillfactor sql-server statistics tsql

4 ответов

помните, что "таблица" означает кластеризованный индекс или "куча".

10

следующий запрос может использоваться для поиска количества чтения и записи во всех таблицах базы данных. Этот результат запроса может быть экспортирован в CSV-файл, а затем с помощью формул excel вы можете легко вычислить соотношение чтения и записи. Очень полезно при планировании индексов на таблице

DECLARE @dbid int
SELECT @dbid = db_id('database_name')

SELECT TableName = object_name(s.object_id),
       Reads = SUM(user_seeks + user_scans + user_lookups), Writes =  SUM(user_updates)
FROM sys.dm_db_index_usage_stats AS s
INNER JOIN sys.indexes AS i
ON s.object_id = i.object_id
AND i.index_id = s.index_id
WHERE objectproperty(s.object_id,'IsUserTable') = 1
AND s.database_id = @dbid
GROUP BY object_name(s.object_id)
ORDER BY writes DESC
19

чтобы определить соответствующий коэффициент заполнения для индексов таблицы, вам нужно посмотреть количество разделений страниц. Это показано в sys.dm_db_index_operational_stats:

количество листьев распределения: общее количество разбиений страниц на конечном уровне индекса.

выделение Неконечных граф: общее количество разбиений страниц выше конечного уровня индекса.

количество слияний страниц: общее количество слияний страниц на листовой уровень индекса.

после небольшого рытья я видел несколько сообщений, в которых говорится, что номера разделения страниц из DMV не так полезны (я лично не подтвердил это), но есть также счетчик производительности "разделение страниц/сек" (но это только на уровне экземпляра SQL Server).

Я использую эмпирическое правило, что обычные таблицы используют коэффициент заполнения по умолчанию 90%, высокие таблицы вставки где - то между 70-85% (в зависимости от размера строки). Читать только таблицы использовать коэффициент заполнения 100%

3

Если у вас есть хороший кластеризованный индекс (т. е. постоянно растущий, уникальный, узкий), то реальные проблемы определения коэффициента заполнения-это то, как обновляется таблица и типы данных столбцов. Если все столбцы имеют фиксированный размер (например, integer, Decimal, Float, Char) и не имеют значения null, обновление не может увеличить хранилище, необходимое для строки. Учитывая хороший кластеризованный индекс, Вы должны выбрать коэффициент заполнения 90 + даже 100, так как разделения страниц не произойдет. Если у вас есть несколько переменных длины столбцы (например, Varchar для хранения имени пользователя), и столбцы редко обновляются после вставки, тогда вы все равно можете сохранить относительно высокий коэффициент заполнения. Если у вас есть данные, сильно изменяющиеся по длине (например, UNC-пути, поля комментариев, XML), то коэффициент заполнения должен быть уменьшен. Особенно, если столбцы часто обновляются и растут (например, столбцы комментариев). Некластеризованные индексы обычно одинаковы, за исключением того, что ключ индекса может быть более проблематичным (не уникальным, возможно, никогда не увеличивающимся). Я подумайте о sys.dm_db_index_physical_stats дает лучшие показатели для этого, но это после факта. Посмотрите на размер записи avg/min/max, размер фрагмента avg, пространство страницы avg, используемое для получения изображения того, как используется пространство индекса. HTH.

1