スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
新しい記事を書く事で広告が消せます。
十分なページ・サイズを持つ SYSTEM TEMPORARY 表スペースが存在しません。
こんばんわ、ふぃぶです。
さて、今日は表題のお話です。
この憎き表題のお話です。
DB2でSELECT文組んでるときにこのエラー出ることがたまにありました。
DB2に明るくないあたしのような人間には「なんのこっちゃぁ!」って感じです。
エラー情報なんかで検索するとまず有力そうな情報があるのは次のサイトさんのページです。
参考サイト様
今回さらっと読んでたんですが余り意味を理解していませんでした。
SYSTEM TEMPORARYテーブルってののページサイズが足りないのね。くらいの認識です。
いわゆる一般で言う「一時表」のサイズが足りないそうです。
まぁそのとおりなんですけど・・・。
では一体何が原因だったのかを書いていきます
【事例】
今回あたしは次のようなSELECT文を作成していました。
ざっくりとこんな感じです。
発行すると先に述べたエラーが発生します。
上記の参考サイト様では、ソートで食いつぶしてる事例がかかれているため
とりあえずあたしもORDER BYを外してみましたが、エラーは出続けます。
一体何!?って思ったらですね、列数が多かったみたいです。
今回扱ってるシステムではSYSTEM TEMPORARYは1つしか作成されていません。
用意されているSYSTEM TEMPORARYのページサイズは4Kとなっていました。
※ db2 list tablespace show detail というコマンドで確認できます
で、SELECT文の取得項目に今回たくさんデータを指定しているわけですが、
どうもコレの合計サイズが4Kを超えたみたいです。
例えばCOLUMN_1~COLUMN30はそれぞれVARCHAR(256)で定義されているとします。
そうするとこれらを全て取得すると7680Byteの領域を必要としますね。
SYSTEM TEMPORARYは4K、つまり4096Byteなので思いっきり超過しています。
SYSTEM TEMPORARYは4Kと定義されている場合、
4K以上の作業領域が必要なものにはそもそも使われないらしいです。
ので↑以外のテンポラリーテーブルは存在しないので、SQL結果の作業スペースがまったくなくなり
エラーするっぽい。
現に、SELECTで取得する項目をCOLUMN1~15に減らすとエラーは起きず実行結果が帰ってきました。
(VARCHAR(256)* 15 = 3840Byteなので足りてる)
ということっぽい。
これの恒久的な対応としてはSELECTの取得項目をSYSTEM TEMPORARY以下に収めるか
またはページサイズがもっと大きいSYSTEM TEMPORARYを作成するかの2つになりそうです。
またやってみたところ、4Kのテンポラリと8Kのテンポラリが定義されていた場合、
SELECTで4K超えた場合8Kのほうをちゃんと使ってくれるっぽいです。
8Kのほうが使われているかどうかは8Kのほうに定義してあるコンテナーのパス配下に
一時ファイルが作成されているかどうかで多分判断できます。
てんぽらりの作り方も機会があれば書きたいなぁ・・・
でわでわ
さて、今日は表題のお話です。
この憎き表題のお話です。
DB2でSELECT文組んでるときにこのエラー出ることがたまにありました。
ERROR [54048] [IBM][CLI Driver][DB2/NT] SQL1585N 十分なページ・サイズを持つ SYSTEM TEMPORARY 表スペースが存在しません。SQLSTATE=54048
DB2に明るくないあたしのような人間には「なんのこっちゃぁ!」って感じです。
エラー情報なんかで検索するとまず有力そうな情報があるのは次のサイトさんのページです。
参考サイト様
今回さらっと読んでたんですが余り意味を理解していませんでした。
SYSTEM TEMPORARYテーブルってののページサイズが足りないのね。くらいの認識です。
いわゆる一般で言う「一時表」のサイズが足りないそうです。
まぁそのとおりなんですけど・・・。
では一体何が原因だったのかを書いていきます
【事例】
今回あたしは次のようなSELECT文を作成していました。
SELECT
A.COLUMN_1
,A.COLUMN_2
,A.COLUMN_3
~以下続く~
,A.COLUMN_29
,A.COLUMN_30
FROM HOGE_TABLE A
INNER JOIN HOGE_2_TABLE B
ON A.COLUMN1 = B.COLUMN
~以下結合~
ORDER BY A.COLUMN_1
ざっくりとこんな感じです。
発行すると先に述べたエラーが発生します。
上記の参考サイト様では、ソートで食いつぶしてる事例がかかれているため
とりあえずあたしもORDER BYを外してみましたが、エラーは出続けます。
一体何!?って思ったらですね、列数が多かったみたいです。
今回扱ってるシステムではSYSTEM TEMPORARYは1つしか作成されていません。
用意されているSYSTEM TEMPORARYのページサイズは4Kとなっていました。
※ db2 list tablespace show detail というコマンドで確認できます
で、SELECT文の取得項目に今回たくさんデータを指定しているわけですが、
どうもコレの合計サイズが4Kを超えたみたいです。
例えばCOLUMN_1~COLUMN30はそれぞれVARCHAR(256)で定義されているとします。
そうするとこれらを全て取得すると7680Byteの領域を必要としますね。
SYSTEM TEMPORARYは4K、つまり4096Byteなので思いっきり超過しています。
SYSTEM TEMPORARYは4Kと定義されている場合、
4K以上の作業領域が必要なものにはそもそも使われないらしいです。
ので↑以外のテンポラリーテーブルは存在しないので、SQL結果の作業スペースがまったくなくなり
エラーするっぽい。
現に、SELECTで取得する項目をCOLUMN1~15に減らすとエラーは起きず実行結果が帰ってきました。
(VARCHAR(256)* 15 = 3840Byteなので足りてる)
ということっぽい。
これの恒久的な対応としてはSELECTの取得項目をSYSTEM TEMPORARY以下に収めるか
またはページサイズがもっと大きいSYSTEM TEMPORARYを作成するかの2つになりそうです。
またやってみたところ、4Kのテンポラリと8Kのテンポラリが定義されていた場合、
SELECTで4K超えた場合8Kのほうをちゃんと使ってくれるっぽいです。
8Kのほうが使われているかどうかは8Kのほうに定義してあるコンテナーのパス配下に
一時ファイルが作成されているかどうかで多分判断できます。
てんぽらりの作り方も機会があれば書きたいなぁ・・・
でわでわ
コメント
コメントの投稿
« Eclipceが突然GalaxyS2を認識しなくなる l ホーム l [DB2]DB2のUDF作成で困ったり困りまくったり »