この記事では、データベースの初期化プロセス中に管理者がよく直面する実際的な問題、つまり大量のデータをデータベース システムにインポートする方法について紹介します。 データベースの初期化プロセス中に、管理者が直面する必要がある実際的な問題は、大量のデータをデータベース システムにインポートする方法です。 SQL Server データベースには、データベース管理者が使用できる大容量データのインポートおよびエクスポート ツールがいくつか用意されています。たとえば、管理者は bcp ユーティリティ ツールを使用して、大量のデータをエクスポートしたり、大量のデータをインポートしたり、フォーマットされたファイルを生成したりできます。たとえば、一括挿入ステートメントを使用すると、大容量のデータをデータ ファイルからデータベース テーブルや非パーティション ビューなどに直接インポートできます。
これらのユーティリティは SQL Server データベースで提供されます。ただし、実際の作業では管理者は注意が必要です。具体的には、大容量データのインポート・エクスポート時には以下の点に注意する必要があります。
1. システムが提供するツールを使用して、大容量データをインポートおよびエクスポートしてみます。
上記で著者が言及したいくつかの実用的なツールには、インポート プロセス中に大容量データに対して特定の最適化を実行するという共通の機能があります。たとえば、一部のデータの形式を標準化し、インポートとエクスポートの時間を節約します。ただし、これらのツールを使用する場合、他の通常のデータ インポートおよびエクスポート ツールと異なる点が 1 つあります。つまり、大容量インポート操作では、テキスト ファイルと呼ばれることが多いカンマ区切りファイルでのデータのインポートがサポートされていません。現時点では、管理者は他のツールを使用して大容量データをファイル形式でインポートすることもできますが、これは通常はお勧めしません。他のツールはインポートプロセス中の最適化機能をサポートしていないためです。このため、著者は、ACCESS やその他の中間ツールなどの他のツールを使用して、最初にテキスト ファイル内のデータを通常の表形式に変換してから、上記のツールを使用してシステムにインポートすることをお勧めします。作業負荷は増加しますが、大容量データの品質を確保できます。そのため、私の実際の業務でも、このような問題が発生した場合には、システムが提供する大容量データのインポート・エクスポートツールを利用することを強く推奨しています。
さらに、フォーマット済みファイルを使用して大容量データの標準化を強化することも良い選択です。上記の大容量インポートおよびエクスポート ツールのいくつかは、元のデータ ファイルの各フィールドの形式情報を保存するための特殊な形式ファイルの使用をサポートしています。フォーマット ファイルには、対応するデータベース テーブルに関する情報も含めることができます。フォーマット ファイルを使用すると、データベース インスタンスからのデータの一括エクスポートおよびデータベース インスタンスへのデータの一括インポートに必要なすべてのフォーマット情報を提供できます。平たく言えば、フォーマット ファイルは、インポート中にデータ ファイル内のデータのフォーマットを解釈し、エクスポート中にデータ ファイル内のデータをフォーマットするための柔軟な方法を提供します。この柔軟性により、データを解釈するための特殊なコードを作成したり、データベースや外部アプリケーションの特別なニーズを満たすためにデータを再フォーマットしたりする必要がなくなります。フォーマットされたファイルを柔軟に使用すれば、後からフォーマットを調整することなく、大容量のデータを必要なフォーマットで直接エクスポートまたはインポートできます。
2. 適切なデータベース ログ操作モードを選択します。
誰もが知っているように、ユーザーがデータベースに加えた変更は、関連するログに記録されます。大量のデータのインポートとエクスポートも例外ではありません。ただし、大容量データは比較的大きなデータであるため、トランザクションログ機能の占有量も比較的大きくなります。このため、大容量のデータをインポートする前に、適切なデータベース ログの運用モードを選択することをお勧めします。著者のアプローチは、ユーザーが大容量のデータをインポートする必要がある場合は、大容量のログ回復モードを選択するのが最善であるというものです。インポート作業が完了するまで待ってから、元のモードに戻ります。
これは主に、大容量ログモードでは大容量データのインポート作業への対応が比較的良好であるためです。他のログ記録された復旧モデル (完全復旧モデルなど) と比較して、一括ログ復旧モデルはバルク操作を最小限に記録するだけです。このため、大容量ログ操作リカバリ モデルは、大量の操作をハードウェア障害から保護し、より優れたパフォーマンスを提供し、必要なログ領域を最小限に抑えます。したがって、一括ログ リカバリではログ行が挿入されないため、一括ログ リカバリを使用すると、トランザクション ログの領域不足を防ぐことができます。この一括ログ操作モードは、完全復旧モデルを使用するデータベースに非常に適しています。一括ログ復旧モデルは、インデックスのないテーブルに対して一括操作を実行する場合に役立ちます。
ただし、大容量ログ運用モードにはリスクもあります。一括ログなどの復旧モデルでは、これらの一括コピー操作によるデータ損失のリスクが増加します。一括ログ動作モードでは、データベース システムが各トランザクションに加えられた変更を 1 つずつキャプチャできなくなるためです。ログ バックアップに一括ログ操作が含まれている場合、そのログ バックアップ内の特定の時点に復元することはできず、ログ バックアップ全体を復元することしかできません。また、一括ログ復旧モデルでは、ログ バックアップが一括操作をカバーする場合、ログ バックアップには、一括操作によって変更されたログ レコードとデータ ページが含まれます。これは、一括ログ操作の結果を取得するために重要です。結合されたデータ領域により、ログ バックアップが非常に大きくなる可能性があります。さらに、ログをバックアップするには、大量のログ トランザクションを含むデータ ファイルにアクセスする必要があります。影響を受けるデータベース ファイルにアクセスできない場合、トランザクション ログはバックアップされず、このログ内でコミットされたすべての操作が失われます。したがって、大容量ログバックアップモードは安全なログモードではありません。
3. 最初にテーブルのインデックスを一時的に削除する必要があるかどうかを検討します
インデックスは特別なファイルであり、データベース内でのその役割は非常に重要です。簡単に言うと、データベースを本に例えると、インデックスは本の目次のようなものです。インデックスには、データ テーブル内のすべてのレコードへの参照ポインターが含まれています。インデックスによってデータベースのパフォーマンスが向上することは間違いありません。しかし、インデックス作成があらゆる場面でプラスの効果をもたらすとは限りません。特殊なケースでは、大容量データのインポートなど、一部の操作のパフォーマンスが低下します。
インデックスを使用すると、データの取得操作を高速化できますが、データの変更操作が遅くなる可能性があります。データ レコードが変更または挿入されるたびに、インデックスを更新する必要があるためです。つまり、100 万件のレコードが挿入された場合、インデックスは 100 万回更新される必要があります。大容量のデータをインポートすると、インデックスが大量のデータベース リソースを消費し、データベースのパフォーマンスが低下することがわかります。宛先テーブルにインデックスがある場合、データベースへの大容量データのインポート速度に影響を与えるだけでなく、他のユーザーのデータベースへの通常のアクセスのパフォーマンスも低下します。
このため、作成者は、インポートするテーブルにそれほど多くのデータがない場合は、最初にインデックスを削除して、大容量データのインポートのパフォーマンスを向上させるのが最善であると提案しています。インポート後にインデックス作成を再度有効にします。ただし、インポートする必要があるテーブルにすでに大量のデータがあり、インポートする必要があるデータが既存のデータと同等かそれ以下である可能性がある場合は、インデックスを削除する必要はありません。この時点でインデックスを削除すると逆効果になります。データベース システムがインデックスを再構築するのにかかる時間は、一括インポート操作中に節約される時間よりも長くなる可能性があるためです。このとき、管理者は対象テーブルのインデックスを削除することで得られる以上の損失が発生します。
4. データインポート後すぐにデータベースのバックアップを実行します。
データベース オブジェクトの構築と同様に、大容量のデータをデータベース システムにインポートした後、管理者は既存のデータベースを適時にバックアップする必要があります。システムの大容量インポート ツールがタイムリーに提供されるため、このデータ インポート作業は依然として非常に面倒で時間がかかります。このため、大容量データをデータベースシステムに取り込んだ後、管理者は適時にデータベースをバックアップする必要があります。ここで著者が皆さんに注意していただきたいのは、操作ログのモードが異なるとバックアップ方法が異なる場合が多いということです。
大容量データをインポートした後、管理者はデータベースをバックアップする必要があります。著者の提案は、その時点で管理者が単純なログ回復モデルを採用している場合、管理者は一括インポート操作が完了した直後に完全バックアップまたは差分バックアップを実行する必要があるということです (時間が許せば完全バックアップを実行するのが最善です)。 。また、その時点でデータベース管理者が大容量ログ復旧モデルや完全復旧モデルを採用している場合でも、時間があまりない場合や、その時点で完全バックアップによるユーザーのアクセスへの影響が心配な場合には、ログバックアップのみを実行することも可能です。十分です。データベース サーバーが運用サーバーになっていない場合 (つまり、データベース サーバーを使用しているユーザーがまだいない場合)、データベースの完全バックアップを実行する方が安全です。
5. よくある間違い
大容量データのインポート中に最も一般的なエラーはおそらく 2 つあります。
まず、提供されたファイルの形式が正しくありません。前述したように、通常、データベースによって提供される一括インポート ツールはテキスト ファイルをサポートしません。この目的のために、管理者は事前に変換を実行する必要があります。次に、隠し文字は問題を引き起こす可能性があることに注意してください。多くのソフトウェアやテキスト エディタでは隠し文字が表示されます。これらの隠し文字は通常、データ ファイルの最後にあります。一括インポート操作中に、データ ファイル内の隠し文字により、予期しないヌル文字エラーなどの予期せぬ問題が発生する可能性があります。この間違いは避けるのが簡単です。データベース管理者がデータをインポートする前にすべての隠し文字を探して削除する限り。実は、この問題は大容量のデータをインポートする場合だけでなく、少量のデータをインポートする場合にも発生します。