ラベル Oracle の投稿を表示しています。 すべての投稿を表示
ラベル Oracle の投稿を表示しています。 すべての投稿を表示

2012年6月10日日曜日

OEMが起動しなくなっていた。

久しぶりにLinuxマシンのOracle11gを起動したら、OEMを起動する部分でエラーが発生している。どうやら、リスナーやDBは起動しているようだ。

SAMBA+LDAP でPDCを作成するために、ドメインやホスト名を変更したことが原因のようです。

■Oracleを起動するとOEMの起動部分でエラーが発生。

[root@hoge ~]# service dbora start
Starting Oracle Database:Processing Database instance "ora02": log file /opt/oracle/app/product/11.2.0/ora02/startup.log
OC4J Configuration issue. /opt/oracle/app/product/11.2.0/ora02/oc4j/j2ee/OC4J_DBConsole_ora02.horisawa.info_ora02 not found.

[oracle@hoge ~]$ echo $ORACLE_SID
ora02
[oracle@hoge ~]$ emca -config dbcontrol db -repos recreate

EMCAの開始 2012/06/10 17:27:11
EM Configuration Assistant, リリース11.2.0.0.2 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

次の情報を入力してください:
データベースのSID: hoge
リスナーのポート番号: 1521
リスナーORACLE_HOME [ /opt/oracle/app/product/11.2.0/hoge ]: 
SYSユーザーのパスワード:  
DBSNMPユーザーのパスワード:  
SYSMANユーザーのパスワード:  
通知用の電子メール・アドレス (オプション): 
通知用の送信メール(SMTP)サーバー (オプション): 
-----------------------------------------------------------------

次の設定が指定されています

データベースのORACLE_HOME ................ /opt/oracle/app/product/11.2.0/hoge

ローカル・ホスト名 ................ hoge.hogehoge.com
リスナーORACLE_HOME ................ /opt/oracle/app/product/11.2.0/hoge
リスナーのポート番号 ................ 1521
データベースのSID ................ hoge
通知用の電子メール・アドレス ............... 
通知用の送信メール(SMTP)サーバー ............... 

-----------------------------------------------------------------
続行しますか。 [はい(Y)/いいえ(N)]: y
2012/06/10 17:29:19 oracle.sysman.emcp.EMConfig perform
情報: この操作は/opt/oracle/app/cfgtoollogs/emca/hoge/emca_2012_06_10_17_27_10.logでロギングされています。
2012/06/10 17:29:20 oracle.sysman.emcp.EMReposConfig invoke
情報: EMリポジトリの削除中(少し時間がかかります)...
2012/06/10 17:32:39 oracle.sysman.emcp.EMReposConfig invoke
情報: リポジトリは正常に削除されました
2012/06/10 17:32:40 oracle.sysman.emcp.EMReposConfig createRepository
情報: EMリポジトリの作成中(少し時間がかかります)...
2012/06/10 17:43:24 oracle.sysman.emcp.EMReposConfig invoke
情報: リポジトリは正常に作成されました
2012/06/10 17:43:34 oracle.sysman.emcp.EMReposConfig uploadConfigDataToRepository
情報: 構成データをEMリポジトリにアップロード中(少し時間がかかります)...
2012/06/10 17:46:01 oracle.sysman.emcp.EMReposConfig invoke
情報: 構成データが正常にアップロードされました
2012/06/10 17:46:07 oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
情報: ソフトウェア・ライブラリは正常に構成されました。
2012/06/10 17:46:07 oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
情報: プロビジョニング・アーカイブのデプロイ中...
2012/06/10 17:47:02 oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
情報: プロビジョニング・アーカイブは正常にデプロイされました。
2012/06/10 17:47:02 oracle.sysman.emcp.util.DBControlUtil secureDBConsole
情報: Database Controlの保護中(少し時間がかかります)...
2012/06/10 17:48:25 oracle.sysman.emcp.util.DBControlUtil secureDBConsole
情報: Database Controlは正常に保護されました。
2012/06/10 17:48:25 oracle.sysman.emcp.util.DBControlUtil startOMS
情報: Database Controlの起動中(少し時間がかかります)...
2012/06/10 17:49:38 oracle.sysman.emcp.EMDBPostConfig performConfiguration
情報: Database Controlは正常に起動されました
2012/06/10 17:49:39 oracle.sysman.emcp.EMDBPostConfig performConfiguration
情報: >>>>>>>>>>> Database ControlのURLはhttps://ora02.horisawa.info:5500/emです <<<<<<<<<<<
2012/06/10 17:49:50 oracle.sysman.emcp.EMDBPostConfig invoke
警告: 
************************  WARNING  ************************

管理リポジトリは、Enterprise Managerデータが暗号化されるセキュア・モードで配置されています。暗号化キーはファイル/opt/oracle/app/product/11.2.0/ora02/hoge.hogehoge.com_ora02/sysman/config/emkey.oraに配置されています。このファイルが失われると暗号化データを使用できなくなるため、このファイルは必ずバックアップしてください。

***********************************************************
Enterprise Managerの構成が正常に完了しました
EMCAの終了 2012/06/10 17:49:50
[oracle@hoge ~]$

■設定変更後は問題なく起動した。

[root@ora02 ~]# service dbora start
Starting Oracle Database:Processing Database instance "ora02": log file /opt/oracle/app/product/11.2.0/ora02/startup.log
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
https://ora02.horisawa.info:5500/em/console/aboutApplication
Starting Oracle Enterprise Manager 11g Database Control ......... started.
------------------------------------------------------------------
Logs are generated in directory /opt/oracle/app/product/11.2.0/ora02/ora02.horisawa.info_ora02/sysman/log
[root@ora02 ~]#

再構築すると、 Enterprise Managerのポート番号が変わる。
元のポート番号(デフォルト:1158)に変更したい場合は、下記のようにする。

[oracle@hoge ~]$ emca -reconfig ports -DBCONTROL_HTTP_PORT 1158

2012年1月2日月曜日

Oracle10g OEMコンソールが起動しない

WindowsXpのOracle10g OEMコンソールが昨年末から起動しなくなった。

今までだと、サイトでググッて確認した oemapp.bat のメモリ割り当て設定を変更して対応できた。
if "%ORACLE_OEM_JAVAMX%" == "" set ORACLE_OEM_JAVAMX=-mx384m
REMif "%ORACLE_OEM_JAVAMX%" == "" set ORACLE_OEM_JAVAMX=-mx128m
上記は、以前にメモリを128mから384mに変更して起動できるようになったが、今回はこの値を大きくしても起動せず、なんど768mにしたら一度起動ができたが、その後起動ができない...

これは、ちょっとおかしいよなぁ~
こんなにメモリを必要なんて考えれない。(ーー;)

仕方ないので、調査を行う事にした。
タスクマネージャを起動してからOEMコンソールを起動してメモリ使用量の推移を監視してみる。

上記の先頭行を参照のこと。
なんと、メモリ使用量がどんどん増加して384MBどころか700MB以上になっていく。そして、oemapp.bat のORACLE_OEM_JAVAMXの設定値を超えるとエラーが発生する。
一度は、設定値を768mで起動しただが、その後は768mを越えていきエラーになる。こんなのはおかしい。

そこで、オラクルのクライアントフォルダの中でOEMコンソール起動時に書き込みが行なわれるログもしくは設定ファイル的はものはないかとフォルダを検索したところ、 dbappprf.properties というファイルが更新されているので、確認するとなんと260MBものファイルになっている。
オラクルの拡張子が .properties のファイルは設定ファイル系であったと記憶しているので、これはおかしい。
実際にファイルの内容を確認してみると、案の定...
よって、上記のファイル(dbappprf.properties)を削除してからOEMコンソールを起動したところ、無事に起動することができました。

また、oemapp.batORACLE_OEM_JAVAMXの値も当初の128mに戻して起動したが問題なく起動した。

要するに、オラクルクライアント9i から 11g まで複数バージョンインストールしてあるので、インストール時のPATHの設定状況悪い時に、違うバージョンのOEM(たぶん9i)に dbappprf.properties に異なるエンコード書き込まれて設定内容を読み込む際にトラブルを起こしているのではないかと思います。

なんとか無事に起動するようになり安心した次第です。

2011年12月22日木曜日

テーブル定義情報をSQL文で出力したい。

 phpMyAdminで見れば良いだろうと言えばそうのだが、やはりSQL文で定義情報を確認および保存しておく事が必要(DBやテーブルの一括作成)な時も多々ある。

 CakePHPでschema.php に定義を追加する時なども必要になる。関連など後から作成した表が schema.php にない場合もあるので、定義情報を簡単に出力できるように確認しておくべきだ。

■MySQL では、下記の通りで対応できる。

■コマンド
[hogehoge@hoge]$ mysqldump -h[ホスト] -u[ユーザ名] -p[パスワード] -d [データベース名] [テーブル名]

■出力結果
CREATE TABLE `users` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) CHARACTER SET utf8 NOT NULL,
  `password` varchar(50) CHARACTER SET utf8 NOT NULL,
  `fullname` varchar(50) CHARACTER SET utf8 NOT NULL,
  `email` varchar(256) CHARACTER SET utf8 NOT NULL,
  `tel` varchar(20) CHARACTER SET utf8 NOT NULL,
  `memo` text CHARACTER SET utf8 NOT NULL,
  `created` datetime DEFAULT NULL,
  `updated` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=latin1;

■オラクル(Oracle10g)では下記のコマンドになります。
■コマンド
set long 10000 (出力する文字数を指定…10000文字まで)
select dbms_metadata.get_ddl('TABLE','TABLE_NAME') from dual;

■出力結果(テーブル:users)
DBMS_METADATA.GET_DDL('TABLE','users')
--------------------------------------------------------------------------------

  CREATE TABLE "HOGE"."USERS"
   ( "ID" NUMBER(6,0),
 "USERNAME" VARCHAR2(50),
 "PASSWORD" VARCHAR2(50),
 "FULLNAME" VARCHAR2(50),
 "EMAIL" VARCHAR2(256),
 "TEL" VARCHAR2(20),
 "MEMO" VARCHAR2(512),
 "CREATED" DATE,
 "UPDATED" DATE,
  CONSTRAINT "USERS_PK" PRIMARY KEY ("ID")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "USERS"  ENABLE
   ) PCTFREE 20 PCTUSED 70 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 983040 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "USERS"

※上記は別ファイルの出力結果をMySQLのテーブルと項目名を揃えた編集版です。
 よって、領域の情報は元々のテーブルの値をそのまま表示しています。

2011年12月20日火曜日

SQLPLUS 備忘録

正しいSQL文なのに、SP2-0734 のエラーが発生する

分析関数やらを駆使してSQL文を作ると100行以上の長文になり、長い行は300文字以上になってしまう事もよくある。
その際には、行単位でインデントして少しでも見やすくしておくのだが、そのインデントの空白が徒になりエラーが発生するのがこの「SP2-0734」である。

■原因
一行が長い文に行頭インデントを行うための空白が実行時に空白行を生み出しているようである。

■解決策として下記のコマンドを使う
SET SQLBLANKLINES ON
このコマンドで空白行が除去されるため無事にSQL文が実行される。

エラー発生時のSQLPLUS画面

2011年11月15日火曜日

Oracle の制約名を確認する。

Oracleの制約名を確認するには、user_constraints を検索(SELECT)すれば良いのだが、いつも困るのはsql worksheet(またはsqlplus)等で検索すると3番目の項目名欄が1文字しか表示されないので、3番目の項目で選択する際に項目名がわからずに困ってしまう。
3番目の項目名は、CONSTRAINT_TYPE列です。 C しか表示されないので困ってします。
この列は、下記のような値になっています。

  • C(表でのチェック制約)
  • P(主キー)
  • U(一意のキー)
  • R(参照整合性)
  • V(ビューでのチェック・オプション付き)
  • O(ビューで読取り専用)

2011年8月23日火曜日

Oracle 大容量データインポート時のUNDO表領域・TEMP表領域不足によるエラー対応

データをベースを再インストールするたびに忘れがちな、「大容量データインポート時のUNDO表領域・TEMP表領域不足によるエラー対応」について書き留めておきます。

結論からすると、大した事ではないのですがつい忘れてしまうオプションです。

IMPコマンドに下記のオプションを設定する。
COMMIT=Y

2011年6月15日水曜日

Eclipseの起動時に「eclipse faild to create the java virtual machine」 エラー

Oracle SQLDeveloper 等のJava系ツールと同じ様な感じのエラーなのかと思いや、ある意味では似ている現象であった。

起動対応と日本語化で下記の3行を eclipse.ini 追加した。
【起動対応】
-vm
C:/Program Files/Java/jdk1.6.0_24/bin/javaw.exe

【日本語化】
-javaagent:plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar
-startup
plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222
-product
org.eclipse.epp.package.modeling.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-vm
C:/Program Files/Java/jdk1.6.0_24/bin/javaw.exe
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m

2011年5月29日日曜日

Oracle SQL Developer 奮闘録(続)・・・一部解決

Oracle SQL Developer 3.0 で無事に Oracle10g、Oracle11gに接続できるようになった。

SQLDeveloper1.5 と SQLDeveloper2 以降では、接続の設定方法が違っていることに気づかなかった。というか、この設定が本当に正しいのか少し疑問に感じてしまっているが...

SQLDeveloper2 以降では、現時点では残念ながら「接続タイプ:TNS」でしか接続できない。
TNSでの接続の設定が自動的に表示される別名(tnsnames.ora)を選択しても接続できず、接続識別子で識別名(tnsnames.oraで定義している識別名・・・要するに別名)を入力すると問題なく接続ができた。
また、SQLDataModelerでは、JDBC ODBC Bridgeでの接続はできたので、同じようにJDBC ODBC でも接続は可能ではと思います。

設定にあたっての注意点

SQLDeveloper1.5は、Oracle9i および 10g のクライアント環境があれば動作するが、SQLDeveloper2.1 および SQLDeveloper3.0 を動作させるには、Oracle11g のクライアント環境が必要になります。また、javaのバージョンについても差異がありますが、OTNからJavaJDKを含んだクライアント環境をインストールすれば問題ないですが、それぞれに必要な java 環境へのパスが適切に通っている必要があります。(当然ながらパスの先に出現する環境が利用されます)

SQLDeveloper1.5 での設定内容

SQLDeveloper3.0 での設定内容

2011年5月24日火曜日

ORA-12518

最近またもや「ORA-12518: TNS: リスナーはクライアント接続をハンドオフできませんでした」のエラーが頻発するようになった。

以前にも発生した事があったが、少し時間を置くを発生しなかったりしたので放置していた。 エラーの原因は、メモリにあることは感じていたがこの機会にスッキリと解決に向けて努力することとした。 発生するマシンは、Macbook PRO のBootCamp にインストールした Oracle10g です。

現象としては、ウィンドウズのコマンドから sqlplus での接続は問題なく接続できるが、sqlworksheet や OEM や クライアントアプリケーションから OracleDB(10g)に接続にいくとエラーが発生するという現象である。

  • コマンドからのSQLPLUSでの接続 → 問題ない
  • Windowsアプリケーションからの Oracle DB への接続 → エラーが発生する。

いろいろと調べた結果、通常 ORA-12518 が発生する場合は、Oracleの仮想メモリが2GBを超えた場合に発生する。(Windows 4GT参照)

しかし、私のマシンで発生している原因は上記の問題ではなく、hostsの設定によるものであった。
  ↓
テスト用にノートPCにOracle10gをインストールしているが、使用する無線LANによるアドレスが変わるので、その都度設定ファイルを変更するのが面倒なので hosts ファイルでPCのホスト名のアドレスを 127.0.0.1 に設定して対応したためのようであった。
この設定を行ってたまにエラー(ORA-12518)がでたが、少し時間をおくと問題なく使用できたので気にせずに利用を続けていた。

しかし、127.0.0.1 はループバックアドレスであるので通常のアプリでの利用には問題がある旨が記載されいる情報を発見し、早速正しいIPアドレスに変更して行ったところエラー(ORA-12518)は発生いなくなった。

面倒だけど、使用する無線LANが切り替わる時は、hostsファイルでアドレスを変更して対応することになった。

2011年4月27日水曜日

Oracle SQL Developer 奮闘録

以前は、WindowsXpに問題なくインストールできていたのですが、3.0系をインストールしたらDBへ接続できない。
DBはWindowsXpの端末の10gがインストールしてあり、Linuxサーバーには11gをインストールしてあるので、それぞれ DB に Oracle SQL Developer で接続を行おうしても接続できない。

Oracle SQL Developerにもいくかバージョンがあり、1.5系、2.*系、3.0系 とありますが、1.5系以外がDBへの接続設定を行うとエラー(ステータス:失敗)接続ができない状態です。

はやめに3.0系を使えるようにしたいのだが...
時間が... ◇\(;_;)/◇

2011年3月24日木曜日

Oracle-主キーに後から項目を追加する

最初から主キーを定義する場合は問題ないのですが、仕様変更が発生して主キーの変更が必要になった場合についつい忘れがちなのがこのコマンドです。(主キーの変更が必要になる仕様変更は初期の段階でないかぎりめったに発生するものではないので...)

主キー Create文
CREATE TABLE テーブル名
(項目名 属性,
項目名 属性,
…,
〔CONSTRAINT 主キー名〕 PRIMARY KEY (項目名, 項目名, …)
);
CREATE TABLE テーブル名
(項目名 属性 〔CONSTRAINT 主キー名〕 PRIMARY KEY, --この方法は、主キーが一項目だけの場合のみ使用可能
項目名 属性,

);
主ーに後から項目を追加
■まず、主キー制約を削除する。
ALTER TABLE テーブル名 DROP PRIMARY KEY;

■主キー制約を追加する。
ALTER TABLE テーブル名 ADD 〔CONSTRAINT 主キー名〕
PRIMARY KEY(項目名, 項目名, …)
;

2011年3月21日月曜日

Oracle Database キャラクタセットについて

新規DB作成時の注意事項

ふと忘れてしまうのが、キャラクタセットのコード設定。11gのインストールがうまく終了しない ことに気をとられてしまい、キャラクタセットのコード設定でつまずく。
 Oracle11gのキャラクタセットは、無指定だと「AL32UTF8」で作成されます。 ここで注意が必要なのが JA16SJIS で作成されたDBを移行する場合です。

Oracleで許可されているデータベースオブジェクト名のサイズはマニュアルに記載されているように、データベース名とデータベースリンク名を除いて 30バイトまでとなっています。

JA16SJIS → AL32UTF8
  • ディスク容量の見直。
  • JA16SJIS2バイトであった文字がAL32UTF8では3バイトになる。

JA16SJISのデータベースで表示名や列名を日本語(マルチバイト)11文字以上で定義していた場合、キャラクタセットが AL32UTF8 であるデータベースではDDLすべてがエラーになる。
 それらを修正するとなるとSQL/DDL文・その他プログラムに至るまで、その影響は広範囲に渡ります。

DBをインストールする機会がたびたびある訳ではないので、以外に上記のことを忘れがちです。 JA16SJISで日本語で15文字以内で項目名や表名を定義しているとAL32UTF8では、10文字以内にすることが必要になり、日本語10文字ですべてをうまく表現するのはなかなか難しいものです。

いずれAL32UTF8にしようと考えている場合は、修正コストは掛かりますが日本語名から英数字名に変更するか、日本語項目名を10文字以内にして修正を行っておくことを薦めます。

2011年1月25日火曜日

Windows で Oracle Database 接続できない?

久しぶりにWindowsXpにOracleDatabaseをインストールしていたら、なぜか他の端末からDBに接続できない?

なんて事はない、ファイアウォールに例外の設定を忘れていただけでした。

2010年12月17日金曜日

Oracle Text でハマッタ...

Oracle Text を利用して中間一致検索の高速化をはかろうしてハマッてしまった。
ます、DBのバージョンが 9i であったためデータを追加・更新・削除しても Oracle Text で作成した索引に即反映させることができない。(10g以降ならデータの追加・変更時に同期可能なのだが...)
↓↓↓↓↓
よって、DBMS_JOB で定期的に更新を行うことになる。
そこでハマッタ。(T_T)

Oracle Textの利用方法(手順)の説明も兼ねて設定方法から説明します。
  1. OracleTextを利用するユーザーを作成します。
  2. ユーザー作成方法はみなさんご存知のとおりです。
    CREATE USER myuser IDENTIFIED BY myuser_password;
  3. 利用するユーザーに権限を与えます。
    (ユーザーにロールを付与します。)
    GRANT RESOURCE, CONNECT, CTXAPP TO MYUSER;
    (CTX PL/SQLパッケージでのEXECUTE権限の付与)
    すべてのOracle Textパッケージの実行権限を付与する場合。
    GRANT EXECUTE ON CTXSYS.CTX_CLS TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_DDL TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_DOC TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_OUTPUT TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_QUERY TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_REPORT TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_THES TO myuser;
    GRANT EXECUTE ON CTXSYS.CTX_ULEXER TO myuser;
  4. プリファレンス(全文検索対象のデータがどんなものかを示す指定)を作成します。
  5. connect <ユーザ名>/<パスワード>

    begin
    ctx_ddl.create_preference('<プリファレンス名>',
                                     'JAPANESE_VGRAM_LEXER');
    end;
    /
  6. 全文検索用の索引を作成します。
  7. CREATE INDEX <索引名> ON <表名> ( <項目名> )
          INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER <プリファレンス名>')
    /
  8. 索引の手動更新
  9. Oracle Text索引は、情報が挿入または更新されるたびに動的に更新されません。  Oracle Textのストアド・プロシージャであるctx_ddl.sync_indexを使用して、索引を定期的にリフレッシュ(同期化)する必要があります。

    BEGIN
    -- 引数にINDEX名を指定
    CTX_DDL.SYNC_INDEX('<索引名>');
    END;
    /

    しかし、上記だといちいち自分で実行して更新しなければならない。
  10. そこでDBMS_JOBで定期実行して索引をリフレッシュ(同期化)する。・・・ここでハマる。
  11. //■DBM_JOB
    VARIABLE jobno NUMBER;
    BEGIN
    DBMS_JOB.SUBMIT(:jobno
         , 'BEGIN CTX_DDL.SYNC_INDEX(''<索引名>''); END;'
         , SYSDATE, 'SYSDATE+10/1440');
         COMMIT;
    END;
    /

    上記で問題(エラー発生)もなく DBMS_JOB に登録できた。
    しかし、ジョブの実行時間後に内容を確認しても追加・変更されたデータが反映されていない。

    下記のように索引で保留中の内容を確認すると更新されてないことを確認。
    SELECT pnd_index_name,
     pnd_rowid,
     to_char(pnd_timestamp, 'dd-mon-yyyy hh24:mi:ss') timestamp  FROM ctx_user_pending;


    更新されないので、手動でジョブを実行するとエラーになる。
    begin    dbms_job.run(<ジョブ番号>);    end;
    *
    行1でエラーが発生しまた.
    ORA-12011:1ジョブの実行に失敗しました
    ORA-06512:"SYS.DBMS_IJOB" . 行406
    ORA-06512:"SYS.DBMS_JOB" . 行272
    ORA-06512:行1

    アラートを調べ、トレースファイルを参照してググッてみたがなかなか解決策が見つからなかった、
  12. 解決策を見つけてみると...
  13. なんと、何度か試行錯誤した中にあったのは?と思う内容であった。わずかにどこか違っていたようだ。

    解答はこれダ!

    define idxname = "<索引名>"
    define interval = "10"

    set serveroutput on
    declare
        job number;
    begin
        dbms_job.submit(job, 'ctx_ddl.sync_index(''&idxname'');',
        interval=>'SYSDATE+&interval/1440');

        dbms_output.put_line('job '||job||' has been submitted.');
    end;
    /
毎度のことながら、些細な事でかなりの時間(今回は丸一日)を費やしてしまうものだ。 やはり、知識は正確により多く貯える必要がある。(泣)

2010年9月1日水曜日

PHPからOracleへの接続

CentOSにPHPのOCI8とPDO_OCIとOracle11gをインストールした時からログに下記の2つが出力されていた。
  • 「PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/oci8.so' - libclnsh.so.11.1: cannot open shared object file: No such file or directory in Unknown on line 0」
  • 「PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/pdo_oci.so' - libclnsh.so.11.1: cannot open shared object file: No such file or directory in Unknown on line 0」
 とりあえず、PHPからOracleへ接続しないので放置しておいたが、今回Firefoxがやたら落ちるのでログを確認していたら気になるので対処することにしました。

 このエラーは、ダイナミックリンクライブラリである oci8.so や pco_oci から libclnsh.so.11.1 が参照できないことを告げています。 よって、ダイナミックリンクライブラリが参照できるように、LD_LIBRARY_PATHに追加すればよいことになります。
(手順)
  • libclnsh.so.11.1のディレクトリを確認する。
  • /etc/ld.so.conf.dに上記のパスを記載したファイル(oracle11g.conf)を作成する。
    (oracle11g.confの記載内容:/usr/oracle/app/product/11.1.0/db_1/lib)
  • ldconfigを実行してld.so.cacheを再構築します。
  • httpdを再起動してログを確認します。
以上で、やっと余計なログが解消されました。(笑)