3

2 つのデータベースがあり、CHAR 列を含む既存のテーブルをデータベース A からデータベース B に転送したいと考えています。

データベース A は Oracle 9i で、エンコーディングは WE8ISO8859P1 で、CHAR(1 char) 型の列が少なくとも 1 つあるテーブル「foo」が含まれています。データベース A はサード パーティのセットアップの一部であるため、テーブルを変更できません。

データベース B は私自身の Oracle 10g データベースであり、さまざまな理由から AL32UTF8 エンコーディングを使用しており、このデータベースに foo をコピーしたいと考えています。

データベース B からデータベース A へのデータベース リンクをセットアップします。次に、次のコマンドを発行します。

* select としてテーブルバーを作成 * from #link#.foo;*

データはうまくコピーされますが、列の型を確認すると、CHAR(1 文字) が CHAR(3 文字) に変換されていることに気付き、データベース B のデータをクエリすると、すべてスペースが埋め込まれます。 .

水中のどこかで、オラクルは自分のバイトと文字を混同していると思います。CHAR(1 byte) は CHAR(1 char) などとは異なります。私はそれについてすべて読みました。

データ型がパディングされた CHAR(3 文字) に変わるのはなぜですか? Oracle がこれを行うのを止めるにはどうすればよいですか?

編集: Oracle 9 と 10 の 2 つの特定のパッチレベル間で CHAR を転送する必要があるようです。これは実際にはバグのようです。わかり次第、更新を投稿します。その間: 私が説明したようにデータベース間で CHAR を移動しようとしないでください。VARCHAR2 は正常に動作します (テスト済み)。

編集 2:答えを見つけてここに投稿しました: Oracle DBLINK をコピーするときに Char(1) が Char(3) に変わるのはなぜですか? 私の問題は解決されたので、残念ながら私は自分の答えを受け入れることができません。

4

3 に答える 3

3

この問題は、元の列の長さの定義に基づいて、異なる文字セット間の文字変換を Oracle が (誤って) 処理する方法が原因で発生します。文字型の列のサイズをバイト単位で定義すると、Oracle は変換方法を認識せず、変換を妨げます。解決策は、文字型の長さを常に文字数で定義することです。

問題の詳細な説明と、これをどのように理解したかについては、 http: //www.rolfje.com/2008/11/04/transporting-oracle-chars-over-a-dblink/ をご覧ください。

于 2008-11-04T21:17:57.197 に答える
2

WE8ISO8859P1 NLS (文字を 1 バイトで格納する) と、文字を最大 4 バイトで格納する AL32UTF8 の違いを学ぶ必要があります。Oracle National Language Support (NLS) Documentationを読むには、ある程度の時間を費やす必要があります。Oracle は、役立つように、データベース リンクを介して自動的に変換を行います。

SQL プロンプトから次のことを試してください。

ALTER SESSION NLS_NCHAR WE8ISO8859P1 
create table bar as select * from #link#.foo;
于 2008-10-31T16:20:01.370 に答える
1

最初に試みることは、CTAS としてではなく、列定義のリストを使用してテーブルを作成し、最初の数千行の挿入を実行することです。それが成功しなかった場合、その理由は非常に明確です...そして、トーマス・ロウが正確に死んでいることがすぐに確認できます.

于 2008-10-31T16:55:15.497 に答える