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

Question

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

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

цель здесь, чтобы узнать соответствующий коэффициент заполнения для индексов - есть идея из этой статьи (Fill Factor Defined).

---

[ОБНОВЛЕНИЕ] Существует прослеживание вопрос о ServerFault
How to determine Read/Write intensive table from DMV/DMF statistics

Answer 1

• sys.dm_db_index_physical_stats (размер и фрагментация)
• sys.dm_db_index_usage_stats (использование, количество сканирований/стремится/обновления и т. д.)
• sys.dm_db_index_operational_stats (текущая деятельность по индексу)

запомнить «table» означает кластеризованный индекс или «кучу».

Answer 2

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

Количество выделенных листов: общее количество разделов страницы на уровне листа индекса.

Количество нелистовых расчётов: общее количество разделов страницы над уровнем листа индекса.

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

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

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

Answer 3

Следующий запрос может использоваться для поиска числа чтения и записи по всем таблицам в базе данных. Этот результат запроса можно экспортировать в 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 

Answer 4

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