SQLPLUSでORA-29283

2009-06-04 22:00:03 | Oracle
（現象）
Solaris9で、SQLPLUSでUserID/Password@SIDで接続し、UTL_FILEパッケージを使用すると、ORA-29283が発生する。
ただし、環境変数 ORACLE_SIDを設定し、SQLPLUSでUserID/Password（BEQ接続）で接続すると、正常に実行できる。
（原因）
UTL_FILEパッケージで開こうとしているファイルの権限が原因だった。
UserID/Password@SIDで接続した場合は、リスナーを経由するので、リスナーを起動したユーザで、ファイルにアクセスしに行くが、BEQ接続で接続した場合は、リスナーを経由しないので、SQLPLUSを実行したユーザでファイルをアクセスしに行く。
リスナーを起動したユーザは、UTL_FILEパッケージで開こうとしているファイルの参照権限を与えられていなかった。

Oracle Linux dbca,netca,netmgrでの日本語文字化け

2008-02-27 22:09:58 | Oracle
Oracle10.2.0.1, SUSE Linux 10.3環境で、Oracle10gインストールと同様に日本語が化ける。
原因は、インストールの場合と同様、日本語フォントが見つからないことが原因である。

インストールの場合と同様に、以下のディレクトリのfont.properties.jaを修正する。

$ORACLE_HOME/jdk/jre/lib/

また、同様に以下のディレクトリにttfファイルをコピーするとともに、fonts.dirを修正する。

$ORACLE_HOME/jdk/jre/lib/fonts/

上記を行った後に、起動すれば、日本語が正しく表示されるはす。

Oracle Linux環境でのインストール時の日本語文字化け

2008-02-26 22:18:40 | Oracle
Oracle Linux環境で、runInstallerの日本語が文字化けしてしまう。この原因は、日本語フォントが見つからないことが原因である。runInstallerを起動する前に、日本語フォントを準備して、設定ファイルを変更してあげれば、日本語が正しく表示される。

以下の例は、Oracle10gの例である。

１．フリーフォントの準備
こちらからsazanamiフォントをダウンロードする。
＊IPAフォントで最初試したが、一部の文字が文字化けしたままだった。原因は追究していない。

ダウンロードしたフォントファイル（拡張子がttf）を任意のフォルダーに解凍。
フォントファイルを解凍したディレクトリで、mkfontscale(SUSE Linuxの場合)で、fonts.scaleを作成する。
作成されたfonts.scaleのjisx0201.1976-0,jisx0208.1983-0以外は削除
する。また最初の数字(フォントの数)も削除する。

２．Oracleのjre解凍database/stage/Componnents/oracle.swd.jre/1.4.2.8.0/1/lib/DataFilesの中ののfilegroup2.jarを任意のディレクトリに解凍する。
ex) unzip filegroup2.jar <任意のディレクトリ>

*oraparam.iniのJRE_LOCATIONを変更する方法の場合、/tmp/Oracle～に書き込めないか、60M以上必要というようなエラーでうまくいかなかった。Oracle9iではうまくいったが。

３．フォントファイルのコピー
１で手に入れたフォントファイルを２で解凍した以下のディレクトリにコピーする。
jre/1.4.2/lib/fonts

４．fonts.dirの編集
jre/1.4.2/lib/fontsの下のfonts.dirに１で手に入れたfonts.scaleを追記する。また、fonts.dirの１行目の数値に、追記した行数分だけ加算する。

５．font.properties.jaの編集
Oracle10gの場合は、wadalab-gothicをsazanami gothicに変更、wadalab-minchoをsazanami minchoに変更する。また、sazanamiに変更した-m-の部分も-p-に変更する。

６．jarの作成
jreをjarファイルに圧縮し，圧縮したjarファイルを、
database/stage/Componnents/oracle.swd.jre/1.4.2.8.0/1/lib/DataFilesに置く。
ex) zip -r filegroup2.jar ./jre

以上の作業を行った後、runInstallerを起動すると、日本語が正しく表示される。


Oracle データベースのリカバリ（５）

2007-01-09 01:13:23 | Oracle
4. 制御ファイルのリカバリ
制御ファイルが全滅した場合のリカバリ方法には、以下の２つがある。
・制御ファイルを再作成する（create controlfileコマンド）
・バイナリバックアップ制御ファイルをリストアし、リカバリコマンドを使用する。

4-1. 制御ファイルの再作成
制御ファイルの再作成は、制御ファイルのトレースがあれば、スクリプトを実行するだけで完了できるため、簡単に行うことができる。
なお、制御ファイルを再作成した後には、以下の作業を実行する必要がある。
・一時ファイルの追加
・読み取り専用表領域がある場合は、読み取り専用表領域のデータファイルのリネーム

4-2. バックアップ制御ファイルでのリカバリ
読み取り専用表領域がある場合、以下の点に気をつける。
・バックアップ制御ファイルを取得したときも、現在も読み取り専用表領域であれば、読み取り専用表領域のデータファイルをオフラインにする必要がある。
・障害発生時に読み書き可能表領域だった場合は、読み書き可能になった後のバックアップ制御ファイルが必要
・障害発生時に読み取り専用表領域だった場合は、読み取り専用になった後のバックアップ制御ファイルが必要

・以下は、SQLによるバックアップ制御ファイルを利用したリカバリの例である。

shutdown
OSコマンドによる全てのデータファイルのバックアップ
OSコマンドによるバックアップ制御ファイルと全てのデータファイルのリストア
startup mount
recover database until time '2007-01-08:15:30:00' using backup controlfile
*バックアップ制御ファイルによるリカバリの場合は、using backup controlfileを指定する。また、カレントREDOログファイルをリカバリで使用するときは、リカバリセッションで、ファイル名を直接指定する必要がある。

alter database open resetlogs;

・以下は、RMANによるバックアップ制御ファイルを利用したリカバリの例である。

shutdown
rman target /
startup nomount
set dbid データベースID
* データベースIDは、v$databaseビューのdbidやrmanセッションで表示される情報,自動バックアップ制御ファイルの書式化された名前(CONFIGURE CONTROLFILE AUTOBACKUP FORMATコマンドで指定）で確認できる。

run {
restore controlfile from autobackup;
alter database mount;
recover database;
}

alter database open resetlogs;
alter tablespace temp add tempfile 'データファイル名' size...
*一時ファイルの追加が必要

5. RESETLOGSを介したリカバリ
アーカイブREDOログにRESETLOGS識別子情報を含めれば、RESETLOGS以前のバックアップファイルを使用したリカバリが可能になる。アーカイブREDOログにRESETLOGS識別子を含めるには、LOG_ARCHIVE_FORMAT初期化パラメータにて%rを含める。ただし、フラッシュリカバリ領域にアーカイブREDOログファイルを格納する場合は、フラッシュリカバリ領域は、OMFを使用している為、LOG_ARCHIVE_FORMAT初期化パラメータは無視される。

Oracle データベースのリカバリ（４）

2007-01-08 23:39:24 | Oracle
3. REDOロググループのリカバリ

REDOロググループの一部のREDOログメンバーに発生した障害の場合は、データベースはオープンできる。
REDOロググループの全てのREDOログメンバーに発生した障害の場合は、データベースをオープンできない。

v$logビューのstatusが「INACTIVE」のREDOロググループの場合は、REDOログファイルのクリアでリカバリ可能。
ex)
アーカイブREDOログファイルが作成済み（v$logビューのarchivedがYES）で、回復処理が必要でない（v$logビューのstatusがinactive）場合は、以下のSQLでクリアする。
alter database clear logfile group グループ番号;

アーカイブREDOログファイルが未作成（v$logビューのarchivedがNO）で、回復処理が必要でない（v$logビューのstatusがinactive）場合は、以下のSQLでクリアする。 ただし、この場合はアーカイブREDOログファイルが欠落してしまうので、バックアップ計画の見直しが必要になる。
alter database clear unarchived logfile group グループ番号;

v$logビューのstatusがactiveやcurrentのREDOロググループの場合は、全てのデータファイルをリストアし、不完全リカバリを行う。
以下は、SQLによるカレントREDOロググループのリカバリの例である。
ex)
shutdown
OSコマンドによるデータファイルのバックアップ
OSコマンドによるデータファイルのリストア
startup mount
recover database until cancel
cansel...カレントREDOロググループのログ順序番号が表示された時に行う。左記以外の場合は、enterキーを入力
alter database open reserlogs;

以下は、RMANによるカレントREDOロググループのリカバリの例である。

shutdown
OSコマンドによるデータファイルのバックアップ
rman target /
startup mount;
run {
set until sequence カレントREDOロググループのログ順序番号 THREAD 1;
restore database;
recover database;
}
alter database open restlogs;

*1 REDOロググループのstatus,archivedは以下のSQLで確認が可能。
selcet group#, sequence#, bytes, status, archived from v$log;


Oracle データベースのリカバリ（３）

2007-01-08 19:50:03 | Oracle
2. 不完全リカバリ

REDOログと同時にクリティカルなデータファイルを失った場合（失ったREDOログまでしかリカバリできない。）や、最新の状態でなくある時点まで戻したい時に、不完全リカバリを行う。

不完全リカバリの流れは以下にようになる。

a. リカバリ前のバックアップ
不完全リカバリが失敗した場合に備え、クローズ状態での全体バックアップを行う。全体バックアップが難しいようであれば、現在の制御ファイルとREDOログファイルのバックアップを行う。

b. 全てのデータファイルのリストア
制御ファイルとREDOログファイルは現在のものを使用し、全てのデータファイルのバックアップファイルをリストアする。

c. 不完全リカバリの実行
SQLコマンド、RMAN、Enterprise Managerを使用して不完全リカバリを行う。全てのデータファイルが同じSCNになるまでREDOログ情報を適用する。
不完全リカバリのタイプには時間ベース、変更ベース、取り消しベースがある。
時間ベース...障害発生時刻が明確な場合、使用
変更ベース...戻す時点のSCNが分かっている場合、使用
取り消しベース...アーカイブREDOログやカレントREDOロググループの損失の場合に使用

d. RESETLOGSオプションを使用してデータベースをオープンする。

e. 不完全リカバリの完了の確認

2-1.SQLによる不完全リカバリコマンドの例

shutdown
OSコマンドでのデータファイルのバックアップ
OSコマンドによるリストア
startup mount
recover automatic database until '2007-01-07:13:30:00'
alter database open resetlogs;

2-2.RMANによる不完全リカバリコマンドの例

shutdown
OSコマンドでのデータファイルのバックアップ
rman target /
startup mount
run {
set until time="to_date('2007-01-07:15:30:00','YYYY-MM-DD:HH24:MI:SS');
restore database;
recover database;
}
alter database open resetlogs;

Oracle データベースのリカバリ（２）

2007-01-08 19:12:01 | Oracle
■データベースのリカバリ（２）

1-2. RMAN使用
recoverコマンドを使用した場合と大きな流れは変わらない。

データベース全体をリカバリする場合の手順が以下である。
a. データベースを停止する。
ex) shutdown

b. RMANに接続する。
ex) RMAN target /

c. データベースをマウントする。
ex) stratup mount

d. データベースのリストア
ex) restore database;

e. データベースのリカバリ
ex) recover database;

f. データベースのオープン
ex) alter database open;

表領域単位でのリカバリする場合の手順が以下である。
a. RAMに接続する。
ex) RMAN target /

b. 表領域をオフラインにする。
ex) sql 'alter tablespace 表領域 offline immediate';

c. 表領域のリストア
ex) restore tablespace 表領域;

d. 表領域のリカバリ
ex) recover tablespace 表領域 delete archivelog
* delete archivelogを使用すると、バックアップよりリカバリされたアーカイブログをリカバリ後に自動的に削除してくれる。

e. 表領域のオンライン
ex) sql 'alter tablespace 表領域 online';

データファイルのリストアを元の場所に戻せない場合は、リストア直前、リカバリ直前に以下の処理が必要になる。* set newnameはrun{}ブロック内でのみ実行できる。
ex)
run {
set newname for datafile 元のデータファイルのファイル番号 to '新データファイル名'
restore ...
switch datafile 元のデータファイルのファイル番号 to datafilecopy '新データファイル名'
recover ...
}

Oracle データベースのリカバリ（１）

2007-01-08 18:57:38 | Oracle
■ データベースのリカバリ（１）
以下の２つのリカバリがある。
「完全リカバリ」...最新のSCN（制御ファイルが認識している最新の状態）までリカバリを行う。
「不完全リカバリ」...最新の状態までリカバリするのではなく、ある時点までのリカバリを行う。

1. 完全リカバリ

1-1. RECOVERコマンド使用
SYSTEM表領域、アクティブなUNDO表領域は、マウントした状態でリカバリを行う必要がある。以下の手順で行う。
a. データベースを停止する。
ex) shutdown

b. データベースをマウントする。
ex) stratup mount

c. 損失したデータファイルをリストアする。（OSコマンド等により。）

d. 損失したデータファイルに対するリカバリを行う。
ex) RECOVER [AUTOMATIC] DATABASE;

e. データベースをオープンする。
ex) alter database open;

SYSTEM表領域、アクティブなUNDO表領域以外の表領域は、オープンした状態でリカバリが行える。以下の手順で行う。
a. 表領域またはデータファイルをオフラインにする。（障害が発生しているデータファイルに対して、不要なチェックポイントを避ける為に、immediate句を指定するほうが良い。）
ex) alter tablespace 表領域名 offline immediate;

b. 損失したデータファイルをリストアする。（OSコマンド等により。）

c. 損失したデータファイルに対するリカバリを行う。
ex) recover [automatic] tablespace 表領域名;

d. 表領域またはデータファイルをオンラインにする。
ex) alter tablespace 表領域名 online;

*1 recover automatic またはリカバリセッションで「AUTO」を入力すると、アーカイブREDOログが自動適用される。もし左記を行わないと、必要なアーカイブログが１つずつ表示され、ENTERキーで確認していく。
*2 制御ファイルが認識している場所にリストアできなかった場合は、リカバリの実行前にリネームを行う。
ex)
オープン時
alter tablespace 表領域名 rename datafile '元ファイル名' to '新ファイル名'

マウント時
alter database rename file '元ファイル名' to '新ファイル名'