Ola Hallengren Scriptsを使ったことはありません。
インデックス最適化用のOla Hallengrenスクリプトを初めて展開する予定です。それらをPRODにデプロイする必要があるので、さらに注意が必要です。とにかく、まず開発環境でテストします。しかし、OH Index最適化スクリプトをデプロイする前に、覚えておくべき重要なことを理解してください。
リンクと以下のコマンドからメディアをコピーしました:
前述したように、これまでOHスクリプトを展開したことはありません。
OHインデックス最適化スクリプトを既にデプロイして正常に使用している人なら誰でも私を以下に案内できますか?
注:私たちはAOAG 2014を使用しています。
これを覚えておいてください。最初にDevでテストし、後でPRODにデプロイできます。
Ola Hallengrenのソリューションは、ベセットプラクティスと長年の経験に基づいています。ただし、いくつかの癖があります。見てください...
最初のスクリプトを実行する前に、最初のいくつかのパラメーターと使用されているデータベースを確認してください。
use [master]
@CreateJobs
@BackupDirectory
@CleanupTime
@OutputFileDirectory
@LogToTable
ヒント:テーブルとプロシージャは、スクリプト(
use [master]
)の20行目で指定されたデータベースに作成されるため、次のことを検討してください。これらのオブジェクトを別のデータベースに保存するには、スクリプトを次のように変更します。msdb
データベース、またはその他のユーザー指定のデータベース。ヒント:各パラメーターの説明を読み、要件または制限に従って変更します。
ソリューションはMaintenanceSolution.sql
という名前の1つのスクリプトとして展開され、それ自体がストアドプロシージャ、テーブル、およびジョブを作成します。
次に、作成されるオブジェクトのリストを示します。
OlaのMaintenanceSolution.sql
スクリプトを使用すると、次のジョブが作成されます。
ヒント:Olaのソリューションはしないを作成することに注意してくださいジョブスケジュール!これは、計画を立てて自分で作成する必要があるものです。
これらのジョブがOlaのソリューションに属していることがわかっている場合は、そのままにしておくことができます。それ以外の場合は、それらをマークしたい場合は、スクリプトを実行する前に、MaintenanceSolution.sql
内に文字列をプレフィックスすることを検討します。適切なテキストエディターで文字列SET @JobName[0-9][0-9] = '
を正規表現検索し、ジョブ名にプレフィックスを追加します
例えばOLA Database Backup - SYSTEM_DATABASES - FULL
考慮事項:後でスクリプトをOlaの新しいバージョンで更新し、元の名前を変更しないでください。命名規則を使用すると、重複するジョブが発生します。ジョブ名を「そのまま」保持したい場合があります。
Olaは次の Microsoftの推奨 に従ってIndexOptimize
ストアドプロシージャを作成しました。
ヒント:一部のテーブルのデータやレコードの量に応じて、適切な異なるパラメーターを使用して個々のジョブを作成することを検討できますより大きなテーブルの要件。
バックアップジョブは、データベースのインスタンスの各レベルのサブディレクトリを作成します。したがって、MyServer
というインスタンスのサーバーMyInstance
でスクリプトを実行していて、データベースの名前がMyDatabase
であり、完全バックアップを表示している場合、バックアップファイル次のディレクトリに次の名前で保存されます。
H:\MyServer\MyInstance\MyDatabase\FULL\MyServer_MyDatabase_FULL_20170712_105500.bak
DIFFバックアップは次のようになります。
H:\MyServer\MyInstance\MyDatabase\DIFF\MyServer_MyDatabase_DIFF_20170712_105500.bak
等.
ソリューションをそのまま開発サーバーにデプロイすることを検討して(使用するデータベースを変更します)、個々のスクリプト、ジョブ、テーブルを確認します。ソリューションをよく理解し、要件に応じて変更します。
そしてもちろん、彼のサイトでOlaのドキュメントを読むことを検討してください:
パラメータは、必要なタスク、実行する頻度とタイミングによって異なります。これは本当にあなた次第です。
デフォルトの場所はmaster dbですが、他の場所に置くことができます。しかし、私はそれをすることで多くの利益を見ません。
スクリプトを実行して、最初にコマンドログテーブルを作成します。
コマンドログテーブルは、イベントをログに記録するためにスクリプトで使用できます。
可用性グループがサポートされています。
これらの質問のほとんどは OlaのFAQ で回答されています。読んでみることを強くお勧めします。
個人的には、完全なメンテナンスソリューションは多すぎると思います。提供されている例を使用して、必要なタスクを呼び出すだけです。
ただし、エージェントジョブを作成する方法の実用的な例を示すため、devで実行する価値があります。これには「正しい答え」はありません。実際に実験して、自分にとって適切なものを選択する必要があります。
私が苦労したことの1つは、ネットワークアドレスにバックアップする場合は、SQL Serverが使用するアカウントにアクセス許可を付与する必要があるということです。したがって、ドメインアカウントである必要があります。
Ola Hellengrenが提供するメンテナンスソリューション全体、つまりバックアップ、データベースの整合性、インデックスの最適化を使用します。
私たちが行うことは、DBA向けの新しいデータベースを作成し、それを使用してメンテナンスソリューションを展開することです。これにより、システムデータベースは、/ DBAが作成した他のオブジェクトから分離されます。そのためにスクリプトを少し変更するだけです(データベース名を使用)。
1 .変更する必要がある重要なパラメータ値
インデックスの最適化については、SPを確認し、スクリプト自体でのインデックスの断片化の必要性に応じて構成します。
2。これらのコマンドはどこにSPおよび関連するコマンド実行とコマンドログを作成しますか、すべてマスターデータベースまたはMSDBにありますか?
はい、スクリプトをそのまま使用すると、masterを使用してすべてのオブジェクトが作成されます。ただし、これは要件に応じてカスタマイズできます。別のデータベースを使用してこれをデプロイします。
3 .一連のコード実行-最初に実行する必要があるコードは?
ソリューションが展開されると、ジョブが作成され、そこからスケジュールを設定できます。
これは、自由にカスタマイズできる最適なソリューションです。使い始めると、日常の負担が大幅に軽減されます。