Technical Articles
より柔軟な方法で SAP SQL Anywhere へデータをロードする – パート 2 (過去のブログ記事より)
このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。
https://blogs.sap.com/2014/04/30/loading-data-in-more-flexible-ways-part-deux/
この記事のオリジナルは、Glenn Paulley が sybase.com に 2009 年 7 月に掲載したものです。その中で、Glenn は データがクライアントにある場合に、LOAD TABLE を使用して SQL Anywhere にデータをロードする方法について語っています。
このトピックに関する私の以前のブログ記事では、READ_CLIENT_FILE()機能を使用した SQL Anywhere の CSV ファイルのクエリー内からの直接の参照機能について説明しました。
今回のブログ記事では、Version 11 以降でサポートされている LOAD TABLE 文の同様の拡張機能について説明したいと思います。
LOAD TABLE でクライアントに存在するファイルをロードする
SQL Anywhere サーバーにおける、データを retrieve するための READ_CLIENT_FILE()を使用したクライアントへのコールバック機能は、LOAD TABLEでも使用可能です。 以前の SQL Anywhere のバージョンでは、LOAD TABLE は、サーバーマシンから直接アクセス可能なファイルへのアクセスのみ可能でした。現在のバージョンでは、適切な権限 (READCLIENTFILE authority) があり、有効化 (the ALLOW_READ_CLIENT_FILE database option) されていれば、クライアントマシンからファイルを直接サーバーのデータベースやテンポラリーテーブルへロードすることが可能です。
StatCounter アカウントから生成した CSV ファイルの処理について説明したパート 1 に続いて、LOAD TABLE を使用して、CSV ファイルをパーマネントテーブルにロードする例を以下に示します。
- CREATE TABLE visitor_summary (
- dayoftheweek CHAR(9) NOT NULL,
- record_date CHAR(30) NOT NULL,
- page_loads INT NOT NULL,
- unique_visitors INT NOT NULL,
- first_time_visitors INT NOT NULL,
- returning_visitors INT NOT NULL );
- LOAD TABLE visitor_summary USING CLIENT FILE ‘c:\gpaulley\blog\Summary-6July2009.csv’ DELIMITED BY ‘,’ SKIP 1
USING CLIENT FILE は、サーバー上のファイルのコンテンツをマテリアライズしません。なぜならば、クライアントファイルは 任意のサイズである可能性があるからです。
Version 11では、LOAD TABLE はファイルをロードする以上のことをサポートしています。LOAD TABLE のシンンタックスには、USING VALUE 句が含まれ、OPENSTRING にとって同様のやり方である CHAR、NCHAR、BINARY、LONG VARCHAR、LONG NVARCHAR、 LONG BINARY 型のいずれの拡張からもテーブルへのデータロードが可能です。
そのため、上記の LOAD TABLE 文は、以下のように書くことが可能です。
- LOAD TABLE visitor_summary USING VALUE READ_CLIENT_FILE(‘c:\gpaulley\blog\Summary-6July2009.csv’ ) DELIMITED BY ‘,’ SKIP 1
テーブルカラムからデータをロードする
Version 11 では、LOAD TABLE 文には、他のテーブルの他のカラムからデータをロードするための明示的なシンタックスがあり、そのテーブルカラムには、BLOT または CLOB としての「行」が、1 つ以上含まれています (そのためサイズは 2GB に制限されています)。
例を挙げると:
- BEGIN
- DECLARE summary_data LONG VARCHAR;
- DECLARE LOCAL TEMPORARY TABLE summary_temp ( summary_line INT NOT NULL PRIMARY KEY, summary_contents LONG VARCHAR NOT NULL NO INDEX) ON COMMIT PRESERVE ROWS;
- SET summary_data = xp_read_file( ‘c:\gpaulley\blog\Summary-6July2009.csv’ );
- INSERT INTO summary_temp VALUES ( 1, summary_data );
- LOAD TABLE visitor_summary USING COLUMN summary_contents FROM summary_temp ORDER BY summary_line SKIP 1 DELIMITED BY ‘,’ WITH ROW
- END
シンタックスは以下のとおりで
- LOAD TABLE … USING COLUMN column_name FROM table_name ORDER BY key [ loading options ]
「table_name.column_name」からの値を処理するためのロードが発生します。ORDER BY 句は、オプショナルではありません。プライマリキー、ユニークインデックス、または「table_name」のユニークな制約をカバーするカラムを参照することで「table_name」 内の行の total ordering を特定しなければなりません。LOAD は、この order 内の「table_name」の全ての 行を処理します。
テンポラリーテーブルに複数の行を挿入するよう上記の例を修正するならば、 (つまり：ライン14 のINSERTを重複）：
- BEGIN
- DECLARE summary_data LONG VARCHAR;
- DECLARE LOCAL TEMPORARY TABLE summary_temp ( summary_line INT NOT NULL PRIMARY KEY, summary_contents LONG VARCHAR NOT NULL NO INDEX) ON COMMIT PRESERVE ROWS;
- SET summary_data = xp_read_file( ‘c:\gpaulley\blog\Summary-6July2009.csv’ );
- INSERT INTO summary_temp VALUES ( 1, summary_data );
- INSERT INTO summary_temp VALUES ( 2, summary_data );
- INSERT INTO summary_temp VALUES ( 3, summary_data );
- LOAD TABLE visitor_summary USING COLUMN summary_contents FROM summary_temp ORDER BY summary_line SKIP 1 DELIMITED BY ‘,’ WITH ROW LOGGING;
- END
その後、StatCounter のサマリーデータの各行の重複コピー3つが「visitor_summary」 にロードされます。
データとトランザクションログをロードする
LOAD TABLE over INSERT 文を使用するパフォーマンス上の主なメリットは、実行スピードがより高速になるということです。
実行スピードがアップした方法の 1つとして、まずロード中のテーブル上のトリガーが fire しないということがあります。
もう1つのスピードアップテクニックとして、デフォルトではロード中のデータのコンテンツはトランザクションログには書かれていないということです。LOAD TABLE 文のテキストのみが、ログに書かれます。これには、注意すべき重要なポイントがいくつかあります。
- 高可用性システムの一部として、データベースがミラリングされている場合、新たにロードされたデータはミラーリングサーバーに送ることができません。
- 同様に、
LOAD TABLEを使用してロードされた行は、ログベースの同期 (Mobile Link または SQL Remote) では問題を引き起こす可能性があります。なぜならば、行自体はトランザクションログに現れないからです。 - データベースのリカバリーが必要な場合には、
LOAD TABLE文を返す必要があります。ロードされたオリジナルのファイルは、 サーバーがトランザクションログからLOAD TABLE文を返すために利用可能でなければなりません。もしファイルが利用不可能な場合には、リカバリーはできません。もしファイルがオリジナルと異なる場合には、データベースが論理的に壊れてしまう可能性があります。SQL Anywhere の Version 11 では、
LOAD TABLEに関連する問題に対して追加のメカニズムを提供しています。LOAD TABLE文でその文がどのようにログされるべきか明示的に特定するためにWITH LOGGING句を提供しています。可能なオプションは以下のとおりです。WITH FILE NAME LOGGING句。この句は、サーバーにあるファイルをロードする場合のサーバーのデフォルトの動作とマッチします。これは、トランザクションログに記録されるべきLOAD TABLE文のみ発生します。このレベルのロギングは、表現またはクライアントファイルからロードされる場合には使用できません。LOAD TABLE文にロギングレベルを特定しない場合には、 以下を特定する場合のデフォルトレベルはWITH FILE NAME LOGGINGです。- LOAD TABLE … FROM filename-expression
- LOAD TABLE … USING FILE filename-expression
WITH ROW LOGGING句。WITH ROW LOGGING句は、INSERT文としてトランザクションログ内に記録されるべきそれぞれの行を発生させます。このレベルのロギングは、同期が含まれるデータベースで推奨されます。またミラーリングでサポートされています。しかしながら、大量のデータをロードする場合には、このロギングのタイムは、パフォーマンスに影響を及ぼす可能性があり、トランザクションログの結果が非常に長くなります。このレベルはまた、計算カラムや
CURRENT TIMESTAMPデフォルトなどのロード先のテーブルが非決定的値を含む場合のデータベースに理想的です。WITH CONTENT LOGGING句。WITH CONTENT LOGGING句は、データベースサーバーにロードされている行のコンテンツを一緒に chunkさせます。これらの chunk は、例えば、トランザクションログからのリカバリーの最中など、後で行に再構成することができます。
大規模なデータをロードしている場合には、このロギングタイプは、それぞれの行をロギングする場合と比較してパフォーマンスにほとんどインパクトを与えず、データ保護は強化されます。しかしながら、WITH CONTENT LOGGINGを使用すると、結果としてトランザクションログは長くなってしまいます。このレベルのロギングは、ミラーリングにかかわるデータベースや、あるいは後のリカバリーにオリジナルデータを維持しない場合などで推奨されます。
WITH CONTENT LOGGING句は、データベースが同期に絡んでいる場合には使用することができません。
LOAD TABLE文でロギングレベルを特定しない場合は、以下を特定した場合、WITH CONTENT LOGGINGがデフォルトのレベルになります。LOAD TABLE … USING CLIENT FILE client-filename-expression
LOAD TABLE … USING VALUE value-expression
LOAD TABLE … USING COLUMN column-expression
===
SAP SQL Anywhere に関する詳細情報は、SAP SQL Anywhere Communityページを参照してください。
SQL Anywhere に関してはまずはこちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。
SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。
Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。