冗長性をチェックするためにテーブルを削除せずに非表示/無効にする方法は？

12

使用されなくなったWebサービスメソッドとデータベーステーブルを含む古いレガシーシステムを維持および拡張する必要があります。テーブルが実際に冗長であるかどうかは完全にはわからないので、それらを削除することを恐れています。

それらを削除せずに同じ効果を達成する他の方法はありますか（テーブルはこれ以上使用できません）？私の考えは、それらを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を無効にすることの短所は、再度有効にするにはインデックスを再構築する必要があることです。他のオプションの1つは、データベースの所有者またはシステム管理者が引き続きそれらを表示し、場合によっては所有権の連鎖を通じて、パブリックロールに対するテーブルのアクセス許可を拒否することです。

— マーティンスミス

テーブルを削除する前、またはテーブルから列を削除する前に、名前の末尾に「_deprecated」などを追加して名前を変更することがよくあります。次に、エラーがない場合、それを参照するものがあってはなりません。

— ジェイ

権限の変更は簡単です。アプリケーションを実行しているサービスアカウントがdboであるか、さらに悪いことにsysadminである場合、すべてのタイプの拒否を完全に無視します。そうでないことを願っていますが、実際に起こります。

— ケネスフィッシャー

6

[使用する可能性のある]ロール/グループ/アカウントからテーブルの権限を削除します。

何かが膨らんだら、すぐに戻してください。

ヒント：スクリプトを使用してこれらの変更を行うことは、本当に良いアイデアです。

— フィル・W
ソース

非実稼働データベースでのテストと同様。;）うまくいけば、それはOPにとって明らかだった。

— jpmc26

@ jpmc26。最初に非実動データベースでテストします。しかし、問題は、関数またはデータベースオブジェクトが外部から使用されているかどうかを知りたいということです（Webサービスメソッドだけでなく、会社の他の場所のデータベースまたは管理ツールでも直接）。

— ティムシュメルター

ふむ DBAによる直接のDBアクセスを探している場合、ロギングが正常に行われているように聞こえます。手作業でprodとnon-prodで同じ使用法を見る可能性は非常に低いかもしれません。これらの操作をログに記録することがどれほど簡単かはわかりませんが、ログインしていた場合は、それを分析して使用状況を調べることができます。

— jpmc26

@ jpmc26：それらの管理者が顔を出しても大丈夫です、彼らはそれを報告します。お客様には問題ありませんが、ロールアウトの前にテストシステムで確認できます。

— ティムシュメルター

3

誰かが許可を持っていないことを確認することはできないため、許可の削除は一般的に機能しません。おそらくグループ、ロール、またはシステム管理者であっても（そうではないことを期待しましょう）。

テーブルの場合、それらを無効にできます。そして、それは簡単なプロセスです。ただし、それらを有効にするには、それらを再構築する必要があり、かなり長い時間がかかる可能性のある大きなテーブルのために。

最善の方法は、オブジェクトを新しいスキーマに移動すること（提案どおり）またはオブジェクトの名前を変更することです。これらの操作は両方とも、実行と取り消しの両方が迅速かつ簡単です。許可は、両方向にもそのまま残ります。

実行できる追加の手順は、オブジェクトの拡張プロパティに「TBD note」を追加することです。変更を行ったときのメモ、および/または削除することが安全であると感じる理由についてのメモを作成できます。

すべてのオブジェクトが使用されていることを確認するために、拡張イベントセッション（またはプロファイラートレース）を数日間実行するということです。セッションをオブジェクト名のみに制限することができます。また、オーバーヘッドを減らすためにセッションに触れた時間も制限できます。また、このセッションを、月末から両側に数日間、場合によっては四半期の終わりに実行して、すべてが揃っていることを確認してください。

— ケネス・フィッシャー
ソース

3

Phil W.が示唆するように、許可を削除します。

また、テーブルを使用するストアドプロシージャからアクセス許可を削除します。SQL Serverでは、（他の人については知りませんが）アクセス許可は呼び出し元オブジェクト（ストアドプロシージャなど）から呼び出されたオブジェクト（テーブルなど）にチェーンされます。

— ピーター・ビル
ソース

タスクは、これらのテーブルにアクセスしようとするすべてのツール、関数、オブジェクト、クエリ（リモートデータベースであっても）を失敗させることでした。ストアドプロシージャを変更する必要がある場合、それを使用することを既に知っている必要があります。または、テーブルがストアドプロシージャで使用されていることを判断する簡単な方法はありますか？

— ティムシュメルター

ストアドプロシージャを変更することはお勧めしません。EXECUTE権限を削除するだけです。あなたが言うように、必要であれば許可を簡単に復元できます。ストアドプロシージャで使用されているテーブルを確認できます。SQLServer Management Studioのオブジェクトエクスプローラで、データベース->プログラマビリティ->ストアドプロシージャを選択します。sproc名を右クリックして、[依存関係の表示]を選択します。[sproc name]が依存するオブジェクトを選択します。

— ピータービル