Определение физического объема таблиц базы данных
Однажды мне нужно было вести разработку в копии рабочей базы DIRECTUM. Вся система, включая SQL-сервер, была развернута на виртуальной машине, что привело к необходимости экономии ресурсов. Я решил уменьшить объем БД, удалив оттуда объекты, которые мне для разработки не требовались. Однако, к своему удивлению, обнаружил, что ни большого количества задач, ни документов в этой базе нет. "Что же тогда заняло все место?" - подумал я. Подумал, и нашел очень неплохую ХП, написанную товарищем по имени Andrew Novick. Эта процедура сразу показала, что объем таблицы истории работы с электронными документами равен 6 Гб. Не меньше была и таблица истории работы с задачами. История для разработки мне была совершенно не нужна, поэтому я с легким сердцем очистил эти таблицы и освободил необходимое место.
Хранимая процедура: dba_spaceused.zip (2,03 Кб)
Источник: Table Space Reporting with dba_spaceused
Пример работы:
Schema TabName Rows ReservedMB DataMB Index_SizeMB UnusedMB
------- ------------------ ------- ------------ ---------- ------------- ----------
dbo SBEDocVer 14997 5827.750 5807.500 2.852 17.398
dbo SBEDocSignature 29225 119.625 117.492 1.242 0.891
dbo MBText 7270 114.023 109.594 1.195 3.234
dbo SBTask 107 88.094 81.125 1.727 5.242
Есть еще отчёты в SQL Server (в Management Studio для SQL Server 2008 точно есть). Но тут сложность - в данном случае, надо на время поменять режим совместимости БД DIRECTUM с SQL 2000 на SQL 2008, тогда отчёты будут строиться. Перед этим лучше остановить службы и прекратить все подключения клиентстких частей к БД.
Потом надо вернуть режим совместимости обратно на SQL 2000, потому как клиентская часть, WorkFlow, ... не будут работать с базой пока она имеет неправильный режим совместимости.
Вот кусок отчета, экспортированного в xls-формат (на выбор есть xls и pdf).
Table Name
# Records
Reserved (KB)
Data (KB)
Indexes (KB)
Unused (KB)
dbo.COCClaimEventsQueue
0
0
0
0
0
dbo.dtproperties
0
0
0
0
0
dbo.getReplActions
0
0
0
0
0
dbo.MBAnalit
6 954
11 552
6 712
3 480
1 360
dbo.MBAnalitSpr
6 954
3 560
952
1 816
792
dbo.MBAnalitV
1
16
8
8
0
dbo.MBAnValR
16 668
6 184
4 184
1 688
312
Сам себя поправлю.
>> Перед этим лучше остановить службы и прекратить все подключения клиентстких частей к БД
>> потому как клиентская часть, WorkFlow, ... не будут работать с базой пока она имеет неправильный режим совместимости
Думаю надо делать всё очень осторожно, потому как если клиенсткая часть, WorkFlow всё же будут работать с базой то она может разрушиться из-за SQL-запросов в не том режиме совместимости. Для большей надёжности - эксперимент со сменой режима совместимости стоит делать только на неиспользуемой копии базы (а не на боевой БД).
БД от этого не разрушится. Просто запросы со *= не будут выполняться (при их выполнении будет возникать исключение). Т.е. фактически никто работать с системой не сможет.
В статье Переносим задачи в файловые хранилища приведен SQL запрос который позволяет определить размер таблиц БД
Авторизуйтесь, чтобы написать комментарий