彼らが言うように、毎日は学校の日です。今日、私は自分の職場がSQL Server Standardエディションを実行していることを知りました。ここでは、Enterpriseが配置されていると想定していました。実際には驚かないでください!
状況によっては、倉庫データを格納する非常に大きなデータベースがあります。データベースのサイズが大きくなるにつれ、サーバーのスペースやアプリケーションのパフォーマンスに問題が発生します。それで、私の観点からそれを見ると、PROD環境に18か月のデータのみを格納するために、PRODデータベースをアーカイブしてパージすることを提案しました。
私のスクリプトを書いて、それらをすべてテストしました。次に、データを削除したテーブルを圧縮し、SQL Server Standardでは圧縮が利用できず、Enterpriseエディションが必要であるというエラーメッセージを見つけました。
私の次のステップはここにあるのだろうか?私の想定では、大量のデータを削除していますが、テーブルが圧縮されるまで、パフォーマンスやスペースの確保という点では実際にはメリットがありません。
縮小は私がいつも恥ずかしがり屋だったと思いますが、ここの多くの記事や投稿はそれを使わないことを勧めます。
疑問に思う、ここにはどのようなオプションがありますか?
私の仮定は正しいですか?圧縮しないと、トリミングされたデータベースからスペースを取り戻すことはできませんか?
2016sp1以降、すべての圧縮機能がすべてのエディションで使用できるようになりましたが、運用環境のアップグレード(2014年以前に実行されていると思いますか?)は気まぐれに実行するものではないため、まったく役に立たない可能性があります。
次に、データを削除したテーブルを圧縮しました
データを削除する場合、本当に必要なのは圧縮ですか?そうである場合、残りのデータのサイズをどのように減らすかを提案するには、そのデータとその使用についてlotを知る必要があります。
収縮は私がいつも恥ずかしがり屋だったと思いますが、
縮小は通常、実行したくないことなので、慎重に行う必要があります。データが再び増加してスペースを使用できるようになった場合は、将来的にデータベースを割り当てたままにしておくとよいでしょう(将来的にパフォーマンスが低下する可能性があります)。これらは不都合なときに発生します)拡大操作であり、特に(私が見てきたように)データファイルが定期的に縮小されている場合は、縮小プロセスが大幅な断片化を引き起こす可能性があります。
ただし、大量のデータをアーカイブ/削除することでデータベースのデータサイズを削減し、すぐにデータ量が元のサイズに戻ると予想されない場合、1回限りの縮小ではいけません。重大な副作用があります。ただし、妥当な期間が経過した後にデータが予想される大きさに縮小し、現在のデータが収まる最小に縮小しないでください。