Oracle管理コンソールへのアクセスURL

すぐに忘れてしまうOracle Enterprise Manager へのURLですが、下記フォルダにインストールした際の設定が保存されているようです。

C:\oracle\product\10.2.0\db_1\install

忘れてしまったら見てみましょう。。

Powered by ScribeFire.

SQL*Loaderのrowsとreadsize,bindsize

書籍を読んで実施したSQL*Loaderでの取込作業でしたが、rows=1000指定しているのになぜか４６件ずつしかコミットしてくれない。。
という問題が勃発し、100万件以上のデータを取り込むのに、、何時間かかるのかという衝撃の展開を迎えました。
他のデータも１００万件以上あるのでこのままでは、一体何日掛ってしまうのかわからないということに・・・

調べてみたところ。。
下記それぞれのサイズが、デフォルトで下記指定になっているため、いくらrowsを指定してもサイズ側で制限値を迎えるとそのタイミングでコミットされてしまうらしい。

readsize 1,048,576 byte
bindsize 256,000 byte

そこで、下記に変えてみたところ。。

readsize 10000000 byte(10M)
bindsize 10000000 byte(10M)

かなり早くなった。１００万件で３０分程度
上記指定をより大きくしかつrowsを10000位にするとより早くなりそう。。

いや。。無知ってこわいです。。

・・・

その後、索引がついているテーブルに実施してしまったため徐々に遅くなり、、結局途中で断念してやりなおすことに。。

索引を削除して実施したら、10時間⇒45分　基本を忘れたらいかんですね。件数が多くなれば多くなるほど、このオーバーヘッドは大きくなりますね。

SQLLoaderで取り込めない

お客さんから取り込めるはずというＣＳＶファイルを受け取ってＳＱＬＬｏａｄｅｒで取り込んでみたところ。。。

論理レコードが終了する前に列が見つかりませんでした。(TRAILING NULLCOLSを使用)

こんなエラーがでてＮＧでした。
ＴＲＡＩＬＩＮＧ　ＮＵＬＬＣＯＬＳ　は、カラム数が足りないときにNULLで補うという指定でこれを指定したらとりこめました。
つまり、カラムが1つ足りないということですね。

さて、なぜこういうことが起きるかというとＣＳＶファイルをエクセル君で開いて保存すると最後のカラムが空っぽの場合,をつけてくれないという衝撃の挙動をします。たぶんこれが原因。
取り込めるはずのデータが、なぜかカラム数が足りないとなったらまずは、エクセルを疑ってみましょう。。
（今回ＣＳＶファイルをエクセルでは開いていないので、たぶんお客さんが中身を確認するときに見たのではないかと）

ちなみに指定の仕方は、ctl（コントロールファイル）で、下記のようにする。

Powered by ScribeFire.

PL/SQLでスクリプト

Oracleを使って開発しているときなど、開発しつつテーブル名を変えたり、シーケンスを再作成したりすることがありますが、その際に毎回データすべてを作りなおすのはかなり面倒です。
そんなときには、スクリプトで何とかしたいもの。
PL/SQLを使ってスクリプトを書いてそれを、SQL*Plusから実行すればサクッとそのあたりのことができます。

今回はたまたま、同僚からシーケンスの再作成（大量に行いたい）を行いたいと相談を受けたので、PL/SQLを使って既存のテーブルから最新のＰＫの値を取得してその値に＋１をしてシーケンスを作りなおすというPL/SQLスクリプトを作ってみた。

function化した方が良かったのと、シーケンスの最大値は、既存のシーケンスから取得するべきですが、まあ参考程度ということで。。

DECLARE   max_id number(8);   drop_seq_sql varchar2(4000);   create_seq_sql varchar2(4000); BEGIN   select max(sample_id)+1 into max_id from TBL_SAMPLE;   drop_seq_sql := 'drop sequence TEST_SEQ';   execute immediate drop_seq_sql;   create_seq_sql := 'create sequence TEST_SEQ start with ' || max_id;   execute immediate create_seq_sql; END; /

表ロックの備忘録

表ロックを行う必要がありちょっと調べたので備忘録。

Lock用のSQLは、トランザクション内で用いトランザクションをコミット、ロールバックすると
ロックが開放される。(Oracle,PostgreSQL)

SQL方言は、この２つのDBは基本的に同じらしい。

LOCK [ TABLE ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ]
(WAITの設定が、Oracle側にあるかは不明。。）

lockmodeは、下記のようにあるがOracleとPostgreSQLで同じように扱えるのは、下記。
ROW SHARE | ROW EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE 

PostgreSQLには、それ以外に
ACCESS SHARE、ACCESS EXCLUSIVE、SHARE UPDATE EXCLUSIVE
というモードがあるらしい。

--PostgreSQL

LOCK

--Oracle


表ロックの種類と相互関係 - Oralce/オラクルをマスターするための基本と仕組み

Powered by ScribeFire.

索引の作成について

索引を作成する条件は一般的に以下みたい。

・その列が問合せの条件、または結合条件として頻繁に利用される。
・列が広い範囲の値を含む場合（Flag系は、いらないっていう話かな。。）
・表が大きく、ほとんどの問合せ結果は表の数%となると予想される。
・列が多数のNULL値を含み、かつNULLでない値を検索する。

http://hagihara08.fc2web.com/gijutu.html#0

Oracleのバッファヒット率計算式

ちょっと備忘録的

＠IT：Oracleパフォーマンス障害の克服（5） Page 1/3

データベース・バッファ・ヒット率＝
　 1 -（physical reads / （consistent gets＋db block gets））

powered by performancing firefox

Oracleデータベースチューニングの裏技？

Oracle9i（１０ｇ)でもかなり有効だと思われるチューニング方法を教えていただいたので備忘録的エントリー。

下記ＳＱＬのように１テーブルの限られたフィールドのみで生成されるＳＱＬでは、普通にＷｈｅｒｅ句に索引を作っただけではパフォーマンスに限界がある。
そこで、Select句とOrder by　のフィールドと合わせて複合索引を作成することでかなりのパフォーマンスアップが期待できる。

Select data_field from table_xxx where data_type = 'A' order by create_date ask;

create index IDX_TABLEXX_F_T_C ON table_xxx (data_field,data_type,create_date) TABLESPACE %INDEX用表領域% などなど；

実際に上記ＳＱＬで、data_typeのみの索引では2分かかっていたが、上記索引では10秒弱となった。

powered by performancing firefox