データベース作成後に設定された初期サイズまでデータベースを縮小する
SQLサーバーでは、すべてのデータベースにプロパティ初期サイズ（MB）があり、SSMSのデータベースのプロパティで確認できます。デフォルトでは、mdfの場合は3 MB、ldfファイルの場合は1 MBです。
したがって、新しいデータベースを作成すると、デフォルトのサイズに設定されます（mdfの場合は3 MB、ldfファイルの場合は1 mb）。しかし、データベースを作成した後、初期サイズを他の値に変更します（たとえば、mdf 10 MBおよびldf 5 MBの場合）（リアルタイムで、データベース管理者は、データベースの作成後に初期値を変更する場合があります）。
しかし、データベースを縮小すると、作成後に設定した初期サイズを超えて縮小します（データベースにデータがないことを考慮してください。それ以外の場合は、実際のコンテンツサイズに縮小されます）。データベース作成時の初期サイズ（mdfの場合は3mb、ldfの場合は1mb）まで縮小されます。私が設定した初期サイズ（つまり、mdfに10 mb、ldfに5 mb）まで縮小することを期待していました。できますか？可能であれば、どうやって？
Dbcc SHRINKFILEを使用して初期サイズを超えて縮小でき、dbcc SHRINKDATABASEを初期サイズを超えて縮小できないような記事を見たことがあります。ただし、設定した初期サイズまでしか縮小したくない。
注：縮小は悪いことであり、実行すべきではないことはわかっていますが、どのようにして縮小できるか知りたいですか？ SQLサーバーがデータベースの作成中に設定された初期サイズのみを考慮する場合、データベースの作成後に初期サイズを設定する使用法は何ですか？
編集：
Microsoftの縮小関連記事から：DBCC SHRINKDATABASEを使用すると、データベースを初期サイズ以下に縮小できません。
私の質問は、既存のデータベース自体の初期サイズを変更できますか？
編集：
約5つのSQLサーバーインスタンスがあります。作成されたすべてのデータベースは、データ用にデフォルトのサイズ3 mb、ログ用に1 mb（約3年前）で作成されました。現在、すべてのデータベースは100〜1000 MBの範囲にあります。データベースは適切な方法ではないため、通常は縮小しません。しかし、一部のデータベースは10 GBを超えて大きくなります（大量のデータを挿入すると、mdfファイル自体になります）。そのため、データベースが大きい場合は、重要ではない古いコンテンツをこのデータベースから別のサーバーにシフトします。これは、そのサーバーでは必要ないためです。そのため、データベースのサイズは10 GBから1 GBに減少します。現在、残りの9 Gbは未使用のままになっています。ここで、データベースサイズを2 GBに縮小して1 GBの空き領域を確保するように指定します（2 GBもこのデータベースの理想的なサイズです）。これを使用して、次の1 GBのデータがいっぱいになるまで自動拡張を回避できます。 。また、このような大規模なデータベースに100 MBの自動拡張を設定しました。したがって、shrinkfileコマンドでサイズを2 GBと指定する代わりに、初期サイズを2 GBに変更できる場合（これは、縮小を考慮します）、それがより適切でした。このデータベースの作成中、サイズ、オートグロスなどの計画はありませんでした。約3年前に作成されたためです。現在、自動拡張などを設定する予定です。新しい初期サイズとシフトデータで新しいデータベースを再度作成することはできません。それで、既存のデータベースの初期サイズを変更できるかどうか尋ねていましたか？
初期サイズは3MBだけではなく、モデルデータベースから取得されます（ユーザーデータベースの作成中に指定されていない場合）。したがって、ユーザーデータベースの作成中に初期サイズを指定しておらず、変更していないとします。 userdbを作成した後のモデルデータベースファイルのサイズは次のとおりです。
_--Create testDB
CREATE DATABASE [TEST_100]
GO
--grow your database file size
ALTER DATABASE [Test] MODIFY FILE ( NAME = N'Test', SIZE = 100MB )
GO
--switch context
USE [TEST_100]
GO
--Find size of modelDB mdf file, this is your initial file size used for the userdb
DECLARE @TargetFileSize int
SELECT @TargetFileSize = (size * 8 / 1024)
FROM sys.master_files
WHERE database_id = 3 --model database
AND file_id= 1 --first file is mdf, assuming you have a model with just one mdf. If you have multiple files, change for the one you need to find.
--shrink the the first file of your current database to the target size that you just found.
DBCC SHRINKFILE (1,@TargetFileSize)
_[〜＃〜]編集[〜＃〜]
さて、編集とコメントの後にいくつかの追加情報が必要です。
まず第一に。 SSMSでファイルのプロパティを表示したときに表示される「初期サイズ」のラベルは、誤った名称であると思います。基本的に、初期サイズは単なる概念です。これは、データベースの作成時に使用される最初のサイズです。これを_CREATE DATABASE_ステートメントで明示的に指定するか、SQL Serverで作成中にその情報を省略してモデルデータベースから暗黙的にコピーすることができます。
ただし、データベースが作成されると、DBAの観点からは「初期サイズ」というものはありません。DBAに表示されるプロパティは1つだけです。つまり、実際のサイズです。 SSMSの「初期サイズ」プロパティでさえ、初期サイズではなく実際のサイズを表示します。
では、なぜ_DBCC SHRINKFILE_または_DBCC SHRINKDATABASE_が初期サイズを「知っている」のでしょうか。サイズを変更した後でも。興味深い質問です。
Dattabaseファイルの最初のページはファイルヘッダーページです。そこには、とりわけ、サイズと最小サイズの2つのプロパティがあります。
ファイルの作成時に、両方のファイルヘッダープロパティに初期値が入力されます。
_DBCC TRACEON(3604)
--parameters for DBCC PAGE: (Dbname, fileID, pageID, outputTypeID)
DBCC PAGE('Test_100',1,0,3)with tableresults
_
どちらのサイズもデータページの量です。この場合。 288データページ。
ファイルサイズを変更した場合：
ALTER DATABASE [test_100] MODIFY FILE ( NAME = N'test', SIZE = 50MB )
「サイズ」プロパティが新しいサイズを反映するように変更されていることがわかります。ただし、「MinSize」プロパティにはまだ「初期」サイズが含まれています。これは、shrinkコマンドの最小サイズです。
しかし、このすべてを言った。最初のサイズを変更してから、最初のサイズに縮小して複雑にする理由をまだ理解できません。目標サイズに直接縮小するのではなく、.
とにかく、あなたの質問に答えます。 「初期」サイズは、プロパティとしてユーザー/データベースに公開されません。
@Edwardは、モデルに設定された初期サイズに基づいてファイルを縮小する方法に関して素晴らしい答えを持っています。私はこれに答えます：
データベース作成後に初期サイズを設定する用途は何ですか？
そしてあなたが意味したと仮定します：
初期サイズの設定の用途は何ですかwhenデータベースの作成？
これは、データベースのサイズを事前に知っている場合に、データファイルとログファイルの両方に非常に役立ちます。構成データ用とトランザクションデータ用の2つのデータベースを作成する場合、データベースの成長パターンは大きく異なる可能性があります。したがって、（サイズと成長の両方の設定の）ひどい、ひどい、ひどいデフォルトをモデルから取得するのではなく、（データベースのひどいデフォルトをさらに変更した場合でも）必要に応じてデータベースごとに常にこれをカスタマイズする方がはるかに理にかなっています。合理的であり、それは通常、万能ではありません）。また、忙しい期間を除いて、いつでも手動でファイルを自動拡張して、最初の予測の変更に対応することができます。データ収集への変更の性質だけでなく、初期の、正しくない設定を使用して成長をガイドするのではなく、.
データベースを作成するための長期的な目標の1つは、すべてのファイルサイズ変更イベントを最小限に抑えるか、完全になくすことです。キャパシティプランニングに関しては常に100％正確であるとは限りませんが、たとえば、来月、1年などの間に収集する予定のデータ量について、ある程度の心構えが必要です。これは、ログですが、予想されるデータ量がわかったら、次のような式を使用してログサイズの大まかな計算を行うことができます（このアイデアはGeoff Hitenからのもので、実際に昨日机を渡ったところです）。
(Largest index * 1.25)
+
(largest amount of log created during reindex run * 2.1)
したがって、最大のインデックスが4 GBで、最後の再インデックスで2 GBのログが作成された場合、4 * 1.25 + 2 * 2.1 = 9.2 GBのログファイルになります。これにより、物理ファイルを拡張することなく、通常の再構築（ロールバックを含む）を処理できるログファイルが提供されます。
最適な自動拡張設定は、バランスのため、予測が少し難しいです。ファイルが大きくなる回数を最小限にしたいが、毎回大きくなるのにかかる時間も最小限にしたい。これは、1 MBの拡張サイズが不要になることを意味します。 15 MBのデータを挿入するトランザクションがあるとします。 15の独立した成長イベントで成長するよりも、その成長（および次の2つのトランザクションも同様）に対応するために1回50 MB成長する方がはるかに優れています。また、20 GBの拡張サイズは、それだけでは時間がかかりすぎる可能性があるため、おそらく望まないでしょう。特にログファイルの場合、 インスタントファイル初期化 の恩恵を受けることができないため、サイズを小さくする方が良いのですが、平均サイズがわからないのに最適なマジック番号があることはわかりません典型的なトランザクションと、ログファイルが存在するストレージのパフォーマンス特性。
繰り返しますが、肝心なのは疫病のような成長と縮小のイベントを避けることです。
必要な場合もありますが、増加イベントと縮小イベントの両方がデータベースのパフォーマンスに悪影響を及ぼします。ログファイルをゼロにする必要があるため、データファイルでのみ可能なファイルの即時初期化が有効な場合でも、ファイルを拡張する間、すべてのトランザクションを一時停止する必要があります。縮小は通常、断片化を引き起こします。これは、特に遅いI/Oで、大きなテーブルの読み取り中に実際に感じる可能性があります。 SSDを使用すると、これはますます関連性が低くなり、すべてのデータがメモリに収まる場合はそれほど重要ではありません。しかし、それらの両方を除外すると...
常にファイルを圧縮している人々について私が得ていないことは何ですか？データまたはログファイルが一度そのサイズまで大きくなると、再びそのサイズまで大きくなります。その間にスペースを解放することは、私にとっては無駄に思えます。その間、スペースを何に使用しますか？ SQL Serverがファイルを再び拡張できるようにスペースを空けておく必要があるため、そこに何も置くことができません。その後、再び縮小できます。その後、再び拡張できます。等々。
データファイルの場合は、今日ではなく、長期的に必要になるスペースを割り当てる必要があります。ログファイルについては、ログファイル内で使用される領域を 適切な復旧モデルに属し、その復旧モデルに適切なバックアップ戦略を実装する で管理する必要があります。
緊急または異常なイベント以外でファイルを圧縮する場合は、処理方法を変更する必要があります。
- http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/
- https://sqlblog.org/2009/07/27/oh-the-horror-please-stop-telling-people-they-should-shrink-their-log-files
- http://www.straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/
- http://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/
ログファイルが特定の初期サイズで作成されたと想定していますが、ldfファイルの初期サイズを小さくしたいですか？
たとえば、MyDatabaseログファイルは、初期サイズ10240 MB（10 GB）で作成されましたが、何らかの理由で（おそらく、より多くのスペースを利用するために）この初期サイズを小さくしたいと思います。
残念ながら、データベースの状態がオンラインのときは、DBCC SHRINKFILEまたはALTER DATABASE構文を使用してログ（* .ldf）ファイルの初期サイズを減らすことはできません。
ただし、ログファイルを削除して再作成することでそのジョブを実行できます。このプロセスでは、データベースをオフラインに設定する必要があります。これは、DBが最初に作成されたときのログの初期サイズを初期サイズよりも小さくする唯一の方法です。
ここで、さらに調査が必要なリンク http://blog.sqlauthority.com/2010/04/26/sql-server-attach-mdf-file-without-ldf-file-in-database/