私が現在作業している場所では、プライマリビジネスデータベースは仮想サーバー(SQL Server 2005標準)にあります。一時DBとログは1つのディスクにあり、データベース自体は別のディスクにあります。 SANは、512GBのディスクしかプロビジョニングできないように構成されています(4Kブロックと言われていますが、SANについては何もありません)。ディスクには約4%の空き容量があります。 DBを保持します。
私は古いデータをアーカイブし、データベースから1年間のチャンクにパージして、テープにアーカイブする方法を検討する必要がありました(私は請負業者であり、実際には開発者ですが、過去にDBAの世界に手を出しました。 DBAではなくSQLServerを使用して開発した経験が15年ほどあり、ドアに入るとすぐに渡されました。DBAがあるので、なぜこれを行っているのかわかりませんが、気にしないで)。それは約6か月前のことで、それ以来、私はオンとオフを問わず、まさにそれを行う何かを構築してきました。しかし、結果のデータベースを十分にテストして、実際に何かが壊れていないことを確認できない可能性があることをますます懸念しており、別の解決策を模索しています。
私は最初にパーティショニングについて考えましたが、SEがあり、6か月ほどでEEにアップグレードする機会がないため、Shebang全体がより大規模で最新のインフラストラクチャを備えた専用のデータセンターに移動し、システム全体が新しいものに置き換えられます。今後2〜4年の開発。しかし、データベースをファイルグループ内の複数のファイルに分割し、それらを複数のディスクに分散できることは確かです(512GBのディスクをさらにプロビジョニングすることに問題はありません)。これにより、DB全体がそのまま残り、パフォーマンスがわずかに向上する場合もありますが、ここではそれが主な目的ではありません。
これはSEでは問題ないと確信しています(繰り返しますが、私はDBAではありません)。これはリスクがはるかに低く、実装が迅速になる可能性があると考えています。だから私の質問:
現在1つのディスク上の1つのファイルにある既存のDBを、複数のディスクにまたがる複数のファイルに分割することは可能ですか?
実稼働データベースからデータをパージする数百万ポンドのビジネスを混乱させるリスクを冒すのは愚かなことだと正気な人に納得させるために、この情報以上のものを提示する必要がありますか?
1)はい
2)はい、
新しいファイルの作成 の後、ターゲットテーブルのクラスター化インデックスを削除して再作成し、それらを新しいファイルグループに移動してデータを移動する必要があります。
CREATE CLUSTERED INDEX CIX_YourTable
ON dbo.YourTable(YourClusteringKeyFields)
WITH DROP_EXISTING
ON [filegroup_name]
3)DBAにこのソリューションのバックアップを依頼できれば、大丈夫だと思います。制限に基づくと、これは完全に合理的な移動のように思われますが、データを移動する前にバックアップすることを忘れないでください。