Как скрыть / отключить таблицы, не удаляя их, чтобы проверить избыточность?

12

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

Есть ли другой способ достижения того же эффекта (таблицы больше не могут использоваться) без их удаления? Моя идея состояла в том, чтобы перенести их в другую схему (например, Deleted) из текущего значения по умолчанию dbo.

IF NOT EXISTS (SELECT * FROM sys.schemas WHERE name = 'Deleted')
BEGIN
   EXEC('CREATE SCHEMA Deleted')
END

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

Есть ли другой вариант или есть какие-то недостатки в подходе схемы?

— Тим Шмельтер
источник

7

Есть ли другой способ добиться того же (таблицы больше не могут использоваться), не отбрасывая их?

Изменение схемы - это очень быстрая операция - требуется только изменение метаданных. Первоначальная идея, которую я получил, была из блога Аарона Бертрана - Schema Switch-A-Roo .

Вы можете следовать инструкциям моего ответа здесь

Очевидно, что есть другие методы, такие как sp_rename N'old table ', N'new table' или просто запрещение доступа к таблице.

— Кин Шах
источник

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

— Тим Шмельтер

@TimSchmelter Рад, что вы нашли это полезным. Не имеет смысла повторять здесь, что за статья или мой ответ (ссылка). Вот почему я ссылался на это.

— Кин Шах

12

Несколько других опций - просто переименовать таблицы, или, если они имеют кластерные индексы, вы можете отключить кластерный индекс.

— Чад Мэттокс
источник

Благодарю. Я не знал, что отключение кластеризованного индекса делает таблицу непригодной для использования. Каковы плюсы и минусы этих подходов (+ схема)?

— Тим Шмельтер

5

@TimSchmelter Смысл отключения CI заключается в том, что для его повторного включения необходимо перестроить индекс. Еще один вариант - запретить разрешения на доступ к таблице для публичной роли, хотя владелец базы данных или администраторы sys по-прежнему будут их видеть, а также, возможно, через цепочку владения.

— Мартин Смит

Перед удалением таблицы или удалением столбца из таблицы я часто переименовываю ее, добавляя «_deprecated» или некоторые другие в конец имени. Тогда, если нет ошибок, не должно быть ничего, ссылающегося на это.

— Джей

Изменения в разрешениях являются случайными. Если служебной учетной записью, на которой запущено приложение, является dbo или, что еще хуже, системный администратор, он будет полностью игнорировать любой тип DENY. Надеюсь, что нет, но это случается.

— Кеннет Фишер

6

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

Если что-то взорвется, положите их обратно [быстро].

Подсказка: Использование сценария , чтобы сделать , чтобы эти изменения были бы очень, очень хорошая идея.

— Фил В.
источник

Как бы тестирование на непроизводственной базе данных. ;) Надеюсь, это было очевидно для ОП, хотя.

— jpmc26

@ jpmc26. Сначала я буду тестировать в непроизводственной базе данных. Но проблема в том, что я хочу знать, используются ли функции или объекты базы данных извне (не только с помощью методов веб-сервиса, но также непосредственно в базе данных или в инструментах администратора в других местах компании).

— Тим Шмельтер

Гектометр Если вы ищете прямой доступ к БД со стороны администраторов баз данных, похоже, логирование в порядке. Маловероятно, что вы увидите одинаковое использование в prod и non-prod из ручной работы. Я не совсем уверен, насколько легко было бы регистрировать эти операции, но если бы у вас был продукт для входа в систему, вы могли бы проанализировать его для поиска использования.

— jpmc26

@ jpmc26: нормально, если эти администраторы упадут им в лицо, они сообщат об этом. Не хорошо с клиентами, но это можно проверить в тестовой системе перед развертыванием.

— Тим Шмельтер

3

Удаление разрешений, как правило, не сработает, потому что нельзя быть уверенным, что у кого-то нет прав. Возможно, через группу, роль или даже потому, что они сисадмины (хотя будем надеяться, что нет).

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

Лучше всего будет переместить объект в новую схему (как вы предложили) или переименовать объект. Обе эти операции являются быстрыми и легкими как для выполнения, так и для отмены. Разрешения также будут оставаться в силе в обоих направлениях.

Дополнительным шагом, который вы можете предпринять, является добавление «заметки TBD» в расширенные свойства объекта. Вы можете сделать заметки о том, когда вы внесли изменения, и / или любые заметки, которые могут у вас появиться, о том, почему вы чувствуете, что от них безопасно избавляться.

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

— Кеннет Фишер
источник

3

Удалить разрешения, как предлагает Фил У.

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

— Питер Билл
источник

Задача состояла в том, чтобы позволить всем инструментам, функциям, объектам, запросам (даже в удаленных базах данных) завершиться неудачно, пытаясь получить доступ к этим таблицам. Если мне нужно изменить хранимую процедуру, я уже должен знать, что она ее использует. Или есть какой-нибудь простой способ определить, что таблица используется хранимой процедурой?

— Тим Шмельтер

Я не предлагал изменять хранимую процедуру, только удалив ее разрешение EXECUTE. Как вы говорите, это легко восстановить разрешение в случае необходимости. Вы можете увидеть, какие таблицы используются хранимой процедурой: В SQL Server Management Studio, Object Explorer, выберите свою базу данных -> Программируемость -> Хранимые процедуры. Щелкните правой кнопкой мыши имя спрока и выберите «Просмотр зависимостей». Выберите объекты, от которых зависит [имя пользователя].

— Питер Билл