Узнайте, какие столбцы в таблице НИКОГДА не используются

Question

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

К сожалению, в большинстве случаев это были бы столбцы (а не таблицы), которые не используются. Поэтому мне нужно разбить его до такого уровня. Я использую SQL Server 2008, если это имеет значение.

Answer 1

Вы можете использовать audit:

use master 
GO 

create server audit MyAudit 
    to file (filepath = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA') 
GO 

alter server audit MyAudit 
    with (state = on); 
GO 

use [<YourDatabase] 
GO 

create database audit specification MyDatabaseAudit 
for server audit MyAudit 
add (
    select on [<YouSchema>].[YourTable] by dbo 
) 
with (state = on) 
GO 

select [<YourColumn>] from [<YouSchema>].[YourTable] 
GO 

use master 
GO 

alter server audit MyAudit 
    with (state = off); 
GO 

select * from sys.fn_get_audit_file ('C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\MyAudit*',default,default); 
GO 

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

Очевидно, что путь к файлу указан выше, как раз для целей примера.

Другим способом является трассировка SQL Profiler, однако это также не позволит вам добраться до уровня столбца, но просто захватывает выполняемые операторы выбора. Недостатком этого является то, что вам нужно правильно его фильтровать, чтобы просто получить нужную информацию, что может быть надоедливым. Кроме того, они могут иметь более высокие накладные расходы.

Answer 2

Единственный способ проверить это - получить доступ ко всему прикладному коду, к которому обращается база данных, и увидеть, как этот код используется в приложении. Если у вас нет запросов, таких как select * from table, вам будет легко работать.

Рассмотрение кода заявки: ничего не даст вам более точного обзора, чем ручное исследование, но это может занять много времени. Если код доступа к базе данных хранится в одном наборе классов, а классы тесно связаны с таблицами базы данных, вы можете просто «найти все ссылки» для каждого столбца базы данных.

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

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

Сторонние инструменты: Используйте эти инструменты, чтобы найти все объекты, на которые не ссылается какой-либо другой объект в базе данных. Может быть полезно определить подозрительные таблицы/столбцы. Попробуйте SQL Dependancy tracker или