パフォーマンスを考慮してバックアップを取得する方法を軽くまとめてみたいと思います。バックアップを取得する際にも有効な方法となります。詳しいですので、ご意見ご要望はこちらに。データディスクで構成されているドライブに取得するときのパフォーマンスをベースラインとしてみます。本のデータディスクを記憶域スペースで束ねたものを使用しています。バックアップは以下のクエリの実行時間をベースラインとします。10GOこの時の処理時間が以下のようになります。分程度かかっています。それでは、このバックアップ取得時間を改善するためにはどのような方法があるかを考えてみます。オプションを使用することが可能となっています。以降で使用できるようになっているかと。このオプションを使用することで、バックアップを圧縮して取得することが可能となります。回数を減らすことができます。圧縮されたデータを書き込むため、データのサイズが減り書き込み回数も抑えられるため。オプションを指定して実行してみたいと思います。COMPRESSIONGO圧縮をすることで、処理時間は以下のようになります。秒になりましたので、圧縮をすることでバックアップ時間が倍以上短縮できていますね。それでは、このバックアップ時間をさらに短縮する方法を考えてみたいと思います。バックアップは複数のバックアップファイルに分散して書き込むことができます。具体的には以下のようなクエリになります。COMPRESSIONGO先ほどまでは、「TESTDB_01.bak」としてバックアップを取得していたのですが、これを「TESTDB01_01.bak」「TESTDB01_02.bak」として取得を行っています。バックアップのコピーではなく、二つのファイルで一つのバックアップとなります。これにより、バックアップの書き込みを分散させ、バックアップの取得時間をさらに向上させることができます。圧縮のみでは「305秒」だったものが、複数のファイルにバックアップを取得することで、「193秒」に処理時間が短縮されています。ファイルとバックアップファイルを増やしてバックアップを取得してみるとどうでしょう。バックアップファイル数を調整しながら取得した結果が下表となります。使用していますが、取得方法によってバックアップのパフォーマンスを向上することができています。短縮することができています。ディスクの構成は変更せずに取得の方法のみを変えて、これだけ性能の差が出ていますので、バックアップを取得する際には取得方法を考慮するのは重要となってきます。使用できるディスク自体が高速なものを使用する必要があると考えています。性能は向上しないと私は考えています。厳密には違うのかもしれませんので私の考えとしてです。あれば、データディスクの本数を上げることで処理時間をさらに短縮することは可能です。本に増やして、ストライプされたディスクに取得した場合の処理時間が以下になります。今回のディスク構成では、データベースの読み取り性能のほうが上限に達ししてしまい、バックアップの取得先のディスク本数を増やしても効果が薄いという結果になってしまっています。この辺はデータベースとバックアップ取得先のバランスが大事になってくるかと。さまざまな処理で、「何スレッド」で「どのようなI/Oを発生させれているか」はディスク性能を考慮するうえでポイントとなってくるかと。ストレージに直接取得することができます。バックアップすることはサポートされていません。次のコードではエラーが返されます。複数のバックアップファイルを指定することがサポートされていません。構文エラーとなります。区切りにしてもエラーとなります)そのため、パフォーマンスを重視したバックアップを実行する場合、データディスクを割り当てる必要が出て来ますので、これについても注意が必要かもしれないですね。チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたらTwitterfacebookやブログのコメントでご連絡いただけると幸いです。ブログにコメント頂いた内容は私が承認しない限り表示されません。受賞させていただきました。本ブログの内容は個人的に検証したものとなり、検証結果を含め記載している内容を保証するものではありません。体験記の連載をさせていただきました。最後まで飲み切れず...。