『[Oracle] ORA-00600エラーへの対処方法』
Oracleのエラーで一番厄介なのはなんといっても「ORA-00600: 内部エラー」でしょう。 内部エラーというのは、文字通りOracleの内部で発生したエラーで、メッセージが定義されていないものがすべてこのコードで返されるというわけです。 つまりはOracleにとっては想定外のエラー、ユーザーから見れば「そりゃOracleのバグだろ」というようなエラーです。 マニュアルを見ても「サポートに問い合わせろ。」としか書いていません。 ということで、内部エラーが出たときには、サポートに素直に連絡するのが賢明です。 ただ、サポートに連絡してもすぐに解決できる場合とそうでない場合があります。 そうでない場合には、エラー発生時の詳細な情報の提供などを求められるため、相手をしているだけでも大変です。 また、そもそもサポートに入っていない場合には、問合せすらできないので自力で解決するしかありません。 ど
![『[Oracle] ORA-00600エラーへの対処方法』](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed239427f781d723ae5cf65616a522073f68d378/height=288;version=1;width=512/https%3A%2F%2Fstat.profile.ameba.jp%2Fprofile_images%2F31%2Farchive-redo-blog%2F1180840362506.jpg)
『[Oracle] データファイルを移動する方法』
データベースの運用を続けていると、ディスク容量やディスクI/Oの問題により、データファイルを物理的に移動させたくなる、あるいは移動せざるを得ない状況になることがあります。 データファイルを物理的に移動させるには、以下の２つの方法があります。 １．ALTER TABLESPACE ～ RENAME DATAFILE ～ ALTER TABLESPACE文を使う場合、データベースを停止させずに、移動させるデータファイルが属する表領域を一時的にオフラインにするだけでデータファイルを移動させることができます。 ただし、システム表領域やアクティブなUNDO表領域などを構成するデータファイルはこの方法で移動させることはできません。 手順は以下の通り。 １）表領域をオフラインにします。 SQL> ALTER TABLESPACE USERS OFFLINE; 表領域が変更されました。 ２）OS上でデータ
『[Oracle] データ・ファイル破損時のメディアリカバリ方法』
Oracleを運用中、ごくまれにデータ・ファイルに破損が生じることがあります。 そんな時、該当データ・ファイルのバックアップとバックアップ以降のREDOログが全て揃っている場合は、完全メディアリカバリによって容易に復旧することができます。 例えば、何か処理を実行した際に、以下のようなエラーが発生した場合．．． ORA-01115: ファイル11(ブロック番号332831)からの読込みI/Oエラーが発生しました。 ORA-01110: データ・ファイル11: 'C:\ORACLE\ORADATA\ORCL\USERS01.DBF' ORA-27091: skgfqio: I/Oをキューできません。 ORA-27070: skgfdisp: 非同期の読込み/書込みに失敗しました。 OSD-04006: ReadFile()に失敗しました。ファイルからの読込みができません O/S-Error:
『[Oracle] DBMS_OUTPUTパッケージを使用する際の問題解決法』
DBMS_OUTPUTパッケージは、ストアドプロシージャのデバッグなどの目的でよく使用します。 例えば、ストアドプロシージャの中に DBMS_OUTPUT.PUT_LINE( 'COUNT=' || wk_count ); というようなデバッグコードを埋め込んでおけば、その時点での変数wk_countの値が画面に出力されます。 ただし、このDBMS_OUTPUTパッケージにはいろいろと制限があります。 そのため、多用する場合は制限にひっかからないようにうまく扱わなければなりません。 まず、SQL*PlusでDBMS_OUTPUTパッケージの出力を表示するには、事前に以下のSQL*Plusコマンドを実行しておく必要があります。 SET SERVEROUT ON これを実行しておかなければ、DBMS_OUTPUTパッケージでいくらメッセージを出力しても画面には何も表示されません。 よく使うので
[Oracle] ORA-01000エラーの原因特定のためにV$OPEN_CURSORを利用する | Archive Redo Blog
アプリケーションでのカーソルの閉じ忘れによって「ORA-01000: 最大オープン・カーソル数を超えました。」が発生する場合、そのエラーが発生した箇所に閉じ忘れがある場合は改修も容易ですが、そうでない場合はカーソルを閉じ忘れている箇所を特定するのに四苦八苦することも多いです。 単純にソースを逆に追っていけばいつかはカーソルを閉じ忘れている箇所にいつかはたどり着くはずですが、あちらこちらで大量のSQLを実行しているような複雑なアプリケーションではたどり着くまでにかなりの時間を費やす可能性もあります。 このようなときには、V$OPEN_CURSORビューを活用すればカーソルを閉じ忘れている箇所をすばやく特定できる可能性があります。 例えば、単純にどのセッションでどんなSQL文のカーソルがオープンされているかを調べるなら以下のようなSELECT文を実行すればOKです。 SQL> SELECT S
『[Oracle] 11gではデフォルトでパスワードの大文字小文字を区別する』
Oracle 11g をインストールして、Object Browser 9 で接続しようとすると、以下のようなエラーが発生しました。 ORA-01017: ユーザー名/ パスワードが無効です。ログオンは拒否されました。 11g からデフォルトでパスワードの大文字小文字を区別するようになったことが原因のようです。 Object Browser 9 はパスワードを小文字で入力しても大文字に自動変換して Oracle に投げるため、小文字のパスワードが設定されている場合、ログオンできなくなってしまうというわけです。 10g 以前のバージョンと同じようにパスワードの大文字小文字を区別しないようにするには、初期化パラメータ SEC_CASE_SENSITIVE_LOGON を FALSE に変更する必要があります。 ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON
『[Oracle] 11gでUTL_INADDRパッケージを使用するとORA-24247が発生』
Oracle サーバーの IP アドレスを取得するため、以下のような SQL を実行すると、 SELECT UTL_INADDR.GET_HOST_ADDRESS('server1') FROM DUAL; 10g では正常に IP アドレスが取得できますが、11g では以下のようなエラーが発生するようになりました。 ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました ORA-06512: "SYS.UTL_INADDR", 行19 ORA-06512: "SYS.UTL_INADDR", 行40 ORA-06512: 行1 これは 11g から UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、UTL_INADDR といったパッケージを使用する際にファイングレイン・アクセス制御が効くようになったためだで、10g 以前のバージ
『[Oracle] 外部プログラムをスケジュール実行する』
Oracle 10g では DBMS_SCHEDULERパッケージを利用すると様々なプログラムをスケジュール実行することができます。 このような機能は Oracle 9i でも DBMS_JOBパッケージとして提供されていましたが、ストアド・プロシージャしか実行できませんでした。 それが、DBMS_SCHEDULERパッケージになって大幅に機能が拡張され、ストアド・プロシージャのほか、PL/SQLブロック、外部プログラムを実行できるようになったのですが、中でも外部プログラムが実行できるようになったことはありがたいですね。 DBMS_SCHEDULERパッケージを利用した外部プログラムのスケジュール設定例は以下のような感じです。 BEGIN DBMS_SCHEDULER.CREATE_PROGRAM( program_name => 'SYS.RMAN_BACKUP_PROGRAM', pr
『[Oracle] バインド・ピーク機能の落とし穴』
値（リテラル）のみが異なるような SQL を繰り返し実行する場合、バインド変数を利用することにより SQL が共有され、パフォーマンスが向上するというのは、データベースのパフォーマンスチューニングでは常識とされています。 （Oracle9i からは CURSOR_SHARING という初期化パラメータを設定することによって、SQL に含まれるリテラルを自動的にバインド変数化し、SQL を共有させることもできますが、原則的には SQL を発行する側で考慮すべきでしょう。） ただ、バインド変数化した場合、オプティマイザの挙動が気になります。 従来の Oracle では、リテラルで記述した SQL の場合はリテラル値を参考にして最適な実行計画を決定しますが、バインド変数化した SQL の場合はバインド変数にセットされた値を考慮せずに SQL の実行計画を決定していました。 しかし、Oracle
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
