web-dev-qa-db-ja.com

テキスト比較が失敗する原因は何ですか？

DBバージョン：PostgreSQL 8.2.15 (Greenplum Database 4.3.4.1 build 2) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Feb 10 2015 14:15:10

単純なクエリを実行すると、1つのスキーマのテーブルが正しく動作しないように見える環境の1つで問題が発生し、文字列がリテラル文字列または他の列と比較されません。スキーマ内の他の同一の列への結合は機能しますが、スキーマ外のテーブルへの結合は機能しません。リテラル文字列を使用した簡単な例を次に示します。

私はこれをします：

SELECT *
FROM carriers
WHERE carrier_code = 'FR'

次に、character（32）列から値をコピーして貼り付け、次のようにします。

SELECT *
FROM carriers
WHERE carrier_hash = '11aedd0e432747c2bcd97b82808d24a0'

これは何も返しません。これは、最初のクエリで返された実際の列からの直接のコピーアンドペーストです。ただし、これを行うと、次のようになります。

SELECT *
FROM carriers
WHERE carrier_hash like '11aedd0e432747c2bcd97b82808d24a0'

それは同じレコードを返します。これも機能します：

SELECT *
FROM carriers
WHERE substring(carrier_hash,1,32) = '11aedd0e432747c2bcd97b82808d24a0'

なぜ=とlikeは、単純な文字列では動作が異なり、_または%文字？これは何ヶ月も働いています。最近変更されたのは、データベースをバックアップ、クリア、および復元したことだけです。復元中に何かが台無しになった可能性はありますか？

同じ列を持つ他のスキーマに他のテーブルがあり、それらは問題なく機能します。

DBAは最近、バックアップからこの環境を復元しました。それが適切かどうかわからない。

greenplum
1
PhilHibbs

これは、データの配布方法が変更されたために発生しています。一部のテーブルは、他のテーブルと同じ方法で配布されていません。レコードは、配布アルゴリズムが示すはずのノードとは異なるノードにあります。そのため、特定の値を検索するクエリを実行すると、マスターはそのキー値を保持する必要があるノードにのみそのクエリを送信しますが、それが見つかりません。結合でも同じことが起こります。セグメントノードは、両方のテーブルが同じ結合キーに分散されているため、結合をローカルで実行できると想定しています。テーブルの1つが正しく分散されていないため、結合が失敗します。

何が原因なのかはまだわかりません。わかったら更新を投稿します。それが何であるかについて何か提案はありますか？

この問題はgreenplum固有であることが判明したため、postgresqlタグを削除しました。

さて、これが何が起こったのかです。 DBAはバックアップから復元していましたが、バックアップ内のファイルが予期された名前と一致しなかったため、失敗しました。復元にはsomething_0_2_somethingと_0_3_と_0_4_というファイルが必要でしたが、バックアップには代わりに_0_22_と_0_23_と_0_24_が含まれていました。そこで彼はPivotalに電話をかけましたが、答えを得るのに時間がかかっていたので、番号から20を引いて名前を変更し、復元を続けました。このように、データが間違ったノードに復元されてしまったようです。ファイル名の問題点とその修正方法について、Pivo​​talからの回答を待っています。

詳細情報：明らかに、バックアップはプライマリセグメントではなくミラーセグメントをバックアップしていたため、ファイル名が異なります。プライマリを削除し、ミラーに復元し、プライマリを元に戻し、バランスを取り直すことで、この問題を回避しています。なぜそれが起こったのかはわかりません。プライマリとミラーのステータスは正常に見えました。 Pivotalはwebexでシステムを検討してきましたが、これがこれまでに発生したことは一度もないと言われているため、成果があります。

1
PhilHibbs