備忘録

SQL*Loader の TRUNCATE

SQL*Loader で TRUNCATE とすると、ロードする前に TRUNCATE してくれるが、セグメント解放してくれなかったので調べた。

SELECT *FROM DBA_SEGMENTS WHERE OWNER = 'XXX' AND SEGMENT_NAME='テーブル名' AND SEGMENT_TYPE='TABLE';


とするとセグメントの情報を取得できる。BYTES や BLOCKS を見れば良い。詳細はマニュアル参照。
TRUNCATE すると、BLOCKS が 1 になるはずだが、そうなっていなかった。
※CREATE TABLE で SEGMENT CREATION DEFERRED を指定していると 0 になると思われる。

SQL*Loader のマニュアルを見ると次のように書いてあった。

TRUNCATEオプションを使用すると、SQLのTRUNCATE TABLE table_name REUSE STORAGE文が実行され、表のエクステントが再利用されます。
TRUNCATEオプションにより、表またはクラスタからすべての行が短時間で効率的に削除されるため、最大限の処理パフォーマンスを実現できます。


TRUNCATE TABLE のデフォルトは DROP STORAGE で、セグメントが解放されるが、REUSE STORAGE だと解放されない。デカイテーブルで DROP STORAGE すると時間がかかる時がある。
それが嫌だから、Loader の TRUNCATE は REUSE STORAGE なのだろうが、オプションで変更できない。

SQL*Loader でセグメント解放したい場合は、事前に TRUNCATE TABLE すべし、ということね。

VirtualBox + AMD 64bitホストOS

VirtualBox に CentOS/Redhat Enterprise Linux/Oracle Enterprise Linux の 32bit/64bit をいろいろな設定でインストールしようとしても全部出来なかった。
インストールして最初のリブート時にエラーで落ちるし、再起動後の初期設定でも kdump の設定の後同じように落ちてつかえない。

使っているマシンが DELL の INSPIRON 15 M5030 というやつで、ホストOSが Windows7 64bit、CPU が Athlon Ⅱ P320 という代物。
AMD Virtualization(AMD-V)をBIOSで有効・無効にしてみたがだめ。
VirtualBox + AMDの相性がわるいもよう。

最近、VMwareを使っていなかったのでしらなかったが、VMware Serverはもうサポートされず、個人Useでは、VMware Player でVMイメージを作れるようになっていたので、そっちでやってみたらあっさり32bit/64bitともにインストールできた。
ユーザ数の違いが品質の違いにあらわれているのかも。

ちなみ、microsoft の Windows7 HomePremium でも動く仮想化ソフト（名前は忘れた）も入れてみたが、VirtualBoxよりもダメだった。

ORA-12034:マテリアライズド・ビュー・ログは最終リフレッシュよりも新しいものです。

マテビューの元表に対してのTRUNCATE
の検証をしているときに、ORA-12034 が発生した。
良くわからないのが、起きたのが1回だけで何回同じことをやっても発生しない。
マテビューの件数が減っていることから、リフレッシュ自体は完了しているが、その後でこけているっぽい。
超微妙なタイミングで発生するOracleのバグ？

マニュアルで関係しそうなものを見てみた。
まず疑ったのは、マテビューログのパージ。
CREATE MATERIALIZED VIEW LOG でログのパージタイミングを指定できる。
mv_log_purge_clause

  • IMMEDIATE SYNCHRONOUS: マテリアライズド・ビュー・ログは、リフレッシュの直後に消去されます。これはデフォルトです。

  • IMMEDIATE ASYNCHRONOUS: マテリアライズド・ビュー・ログは、リフレッシュ操作後に、別のOracleスケジューラ・ジョブで消去されます。

  • START WITH、NEXTおよびREPEAT INTERVALは、CREATEまたはALTER MATERIALIZED VIEW LOG文で開始される、マテリアライズド・ビューのリフレッシュに依存しないスケジュール実行のパージを設定します。これは、CREATEまたはALTER MATERIALIZEDVIEW文の、スケジュール実行のリフレッシュ構文と似ています


とあり、今回はオプションを何も指定していないので同期で削除されるから問題なさそう。

次に疑ったのは、COMMIT SCN
WITH ROWID, PRIMARY KEY でマテビューを作っている。デフォルトでは「COMMIT SCN句を使用しない場合、マテリアライズド・ビュー・ログはタイムスタンプ・ベースになり」と言っているので、これに起因する問題か？
と思ったが、「COMMIT SCN」はローカルマテビューでしか使用できないので、これで回避することは出来ない。

結局理由わからずで、起きないことを祈るのみ。
運用では、TRUNCATEは基本無く、更新しているタイミングでリフレッシュはしないのでまず起きないと期待したい。


SQL> truncate table tbl03;

表が切り捨てられました。

SQL>
SQL> select UNUSABLE, KNOWN_STALE, INVALID from USER_MVIEW_ANALYSIS WHERE MVIEW_NAME='MV01';

UN KN IN
-- -- --
N  N  Y

SQL> select count(*) from mv01;

  COUNT(*)
----------
         2

SQL> exec DBMS_MVIEW.REFRESH( 'MV01', '?');
BEGIN DBMS_MVIEW.REFRESH( 'MV01', '?'); END;

*
行1でエラーが発生しました。:
ORA-12034: "TEST"."TBL03"のマテリアライズド・ビュー・ログは最終リフレッシュよりも新しいものです。
ORA-06512: "SYS.DBMS_SNAPSHOT", 行2563
ORA-06512: "SYS.DBMS_SNAPSHOT", 行2776
ORA-06512: "SYS.DBMS_SNAPSHOT", 行2745
ORA-06512: 行1


SQL> select UNUSABLE, KNOWN_STALE, INVALID from USER_MVIEW_ANALYSIS WHERE MVIEW_NAME='MV01';

UN KN IN
-- -- --
N  Y  N

SQL> select count(*) from mv01;

  COUNT(*)
----------
         1

なんで東電だけ叩かれるのか？

最初に断っておきますが、私は東電の利害関係者ではありません。
原発事故で、東電ばっか叩かれれ、リストラしているのにすごい違和感があります。
日本航空と同んなじで良い給料・年金もらっているからっていうのもあるかもしれません。
しかし、原子力行政に関わっていた・いる公務員が何の責任も取らない・追求されないのは納得がいかない。
奴らの年金全額カットしたって良いぐらいだ。
よく企業が不祥事を起こすと、監督省庁に行ってふんぞりがえっている役人に詫びをいれている画を見る。
しかし、詫びる相手は実際に被害をこうむった消費者等にすべきで、役人は監督不行で一緒に謝り、処分されるべき。

iPhoneの使いにくい点

iPhone4を使っているが使いにくい点を羅列してみます。
・クリップボードに複数コピー出来ない
・横にして向きが切り替わらないアプリがある
・Capsロックが出来ない
→実は⇧キー連打で出来た
・アプリ切り替えのディスプレイ外のボタンのダブルクリックがうまくいかない時が多い
・DELボタンはあるがバックスペースが無い
・矢印キーが無い
・電話機としてはダメ。スピーカーがダメ。
・PC無しで大きなアプリを入れられない
・ブラウザで履歴を一気に飛べない
・地下鉄に乗っていると基地局を探して動作が重くなる
次のページ

FC2Ad