i2i無料WEBパーツ
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
■試験名:Gold DBA10g 新機能 1Z0-040J

合格ライン73% 結果正答率80%

・・・あぶねぇ(・_・;;;)

いやぁ、やばかったっすねぇ。
これから受ける人は、iStudyで100%とっていても注意したほうがいいですよ。

今回間違った問題。

・一時表領域グループのユーザー割り当て

・ブロックメディアリカバリ(BMR)、試行リカバリ<Part2>
 今回は、RECOVERYのTEST句は出ませんでした。
 V$DATABASE_BLOCK_CORRUPTIONについての問題だったかなぁ・・・。

・Flashback VersionsQuery機能

・表領域の名前変更
 ※これは、UNDO表領域にしていされている表領域グループの名前を更新したときの問題でしたなぁ。SPFILEを使用していない場合は、アラートログファイルに警告が表示されるってのを覚えておかなきゃいかんってことですな。
  
・列レベルのVPDポリシー

・ファイングレイン監査(FGA)<Part2>
 むぅ・・・この問題、今回、また迷ったんだよねぇ。statement_typesに指定できる文は?って問題ではなくて、「監視できる文は、SELECT,INSERT,UPDATE,DELETEである。」って感じのが選択肢にあったんですけど・・・今回はMERGE文がないからってことで、選ばなかったんだよね。そしたら、×みたいだからなぁ・・・・。

・DataPumpインポートにおけるTRANSFORMの使用
 この問題もまったく、盲点でしたなぁ・・・・。
  TRANSFORM=SEGMENT_ATTRIBUTES:N
  (※SEGMENT_ATTRIBUTESは複数形ってのを覚えとかなきゃいかんらしい。さらに、Nの位置もね。
  TRANSFORM=SEGMENT_STORAGE:N
  (※TRANSFORM=SEGMENT_STORAGEは単数ってのを覚えとかなきゃいかんらしい。さらに、Nの位置も。

・異なるプラットフォーム間での表領域転送
 
・AutomaticSharedMemoryManagement(自動共有メモリー管理)

・サーバーが生成するアラート監視および管理

・自動タスク機能

・SQL Tuning Advisor

以上ですね。さて、つぎは何の勉強しようかなぁ。。。
Teedaでもうちょっと遊びたい気もするが、SQL SERVERもとっておきたいし、ソフトウェア開発の勉強もちょこちょこ始めたいところですなぁ。
スポンサーサイト
さてさて、明日が受験日です。
あっというまに、2週間ですか・・・早いもんですなぁ。

明日、攻殻機動隊2.0の公開日ですからねぇ・・・試験をささっとクリアして
気持ちよく映画をみて、その後、らめーらでワインを飲む!!

・・と、いきたいところですなぁ・・・。前回、100%の自信をもって挑んだのに不本意な結果だったので、かなり不安ですが・・・・(・_・;;)


・Oracleスケジューラを使用することで可能となる処理
  →OS上のシェルスクリプトを実行するジョブを作成できる
  →スケジュールとプログラムを再利用したジョブを作成できる
  →リソースプランを使用した優先順位を設定できる

 ※Oracleスケジューラ(DBMS_SCHEDULERパッケージ使用)にて、日常的なメンテナンス作業やアプリケーションロジックの定期的な実行を行うことができます。従来のジョブ機能(DBMS_JOBパッケージ使用)ではできなかったものには次の機能があります。

 ※リソースプランの使用」
  →スケジューラでは、ウィンドウ(時間枠をつくるオブジェクト)を使用することで、リソースプランとの対応づけが可能。リソースコンシューマグループはジョブクラス(ジョブをグループ化するオブジェクト)と対応づけができるため、ジョブの実行時にリソースマネージャによるリソース制限を適用できる
 ※「再利用」
  →プログラム(特定の実行可能スクリプト、プロシージャに名前をつけたオブジェクト)とスケジュール(実行間隔に名前をつけたオブジェクト)を作成し、これらを使ったジョブを作成できる。そのため、プログラムの修正やスケジュールの修正は、使用したジョブに反映できるため、管理が容易になる
 ※「OS上のシェルスクリプトの実行」
  →従来のジョブでは、プロシージャの実行しかできないが、スケジューラではOS上に配置してあるスクリプトや実行可能ファイルをコールできる

・Database Controlからセグメントアドバイザにアクセスできるページ

  →スキーマオブジェクト
  →セントラルアドバイザ
  →表領域

  ※セグメントの未使用領域を開放するには、セグメントの縮小(ALTER TABLE ... SHRINK SPACE)を使用できます。そして、セグメントの縮小が可能なセグメントを分析することができるのが「セグメントアドバイザ」です。
  ※セグメントアドバイザは、Database Controlの次のページからアクセスできます。

・Data Pumpを使ったエクスポートの時間がかかっているので一度停止し、マシン負荷の低い時間帯に、この続きを実行するということになりました。
 停止させたジョブ、ジョブの名前を確認するにはどのビューを使用したらよいか。
  →DBA_DATAPUMP_JOBS

 ※Data Pumpジョブは、既存のジョブに連結し、対話型モードを使用することで、ジョブを一時停止/再開したり、ジョブを解除(削除)したり、並列度を変更したりすることができます。
 どのようなジョブが存在しているかは、DBA_DATAPUMP_JOBSビューで確認できます。ジョブが完了するとレコードは表示されなくなりますが、一時停止している場合は、再開するまでの間、情報を表示することができます。


SQL> SELECT owner_name,operation,job_name,state
2 FROM dba_datapump_jobs;

OWNER_NAME OPERATION JOB_NAME STATE
---------- ---------- -------------------- ----------
SYSTEM EXPORT SYS_EXPORT_SCHEMA_01 IDLING


・使用可能、使用禁止の切替ができるスケジューラオブジェクト
  →プログラム
  →ウィンドウ
  →ジョブ
  →ウィンドウグループ

 ※スケジューラオブジェクトの中で、「ジョブ」、「プログラム」、「ウィンドウ」、「ウィンドウグループ」は使用可能、使用禁止を切り替えることができます。
  手動で切り替える場合は、DBMS_SCHEDULER.ENABLEプロシージャ/DBMS_SCHEDULER.DISABLEプロシージャを使用します。プログラム、ウィンドウ、ウィンドウグループの場合は、使用しているジョブすべてに影響を与えることができるため、スケジューラの管理が容易になります。

・フラッシュバックトランザクション問合せ機能に関する説明として正しいもの
  →FLASHBACK_TRANSACTION_QUERYビューを確認する
  →SELECT ANY TRANSACTIONシステム権限が必要
↓このPart2ってなんなんだ・・・?(・_・;)
試験結果レポートに書いてある間違った項目なんだけど、黒本にはPart2なんて章はないんですけど・・・(汗。

ファイングレイン監査(FGA)<Part2>

・ファイングレイン監査を使用して監視できる文をすべて含めているもの

  →SELECT、INSERT、UPDATE、DELETE、MERGE
  ※10gのファイングレイン監査(FGA)では、INSERT、UPDATE、DELETE、MERGE文の監査が可能になっている。
  ※監査するSQL文は、DBA_FGA.ADD_POLICYSTATEMENT_TYPESパラメータで指定します。
  ※デフォルトでは、SELECT文のみ監査します。
SQL> EXEC DBMS_FGA.ADD_POLICY (     -
   >  object_schema   => ’hr’,    -
   >  object_name    => ’employees’, -
   >  policy_name    => ’hr_policy’, -
   >  statement_types  => ’select,insert,update,delete’);

  ※MERGE文は記述することはできません。
   記述しなくても、MERGE文が実行されるとターゲット表ではINSERT文とUPDATE文に分解されるので、監査対象となります。
   10gのファイングレイン監査(FGA)では、デフォルトですべての行、すべての列となっているため、上記のコマンドによって、SELECT文とDML文が監査されます。

  ※↑怪しい問題が出たんだよなぁ・・・。「statement_typesに指定できる文を選べ」って問題だったら、MERGE文は記述できないんだからバツだよね。注意しとかねば・・・。

・コマンドに関する説明として正しいもの
 EXEC DBMS_RLS.ADD_POLICY (     -
  object_schema  => ’hr’,    -
  object_name   => ’employees’,-
  policy_name   => ’hr_policy’,-
  function_schema => ’hr’,    -
  policy_function => ’hrsec’,  -
  statement_types => ’select’,  -
  policy_type   => dbms_rls.static)

  →ポリシーファンクションは1度だけ実行される
  →ポリシー述語はSGAにキャッシュされる
 
  ※10gのファイングレインアクセスコントロール(FGAC)では、5種類のポリシータイプをサポートしている。

  ※「DBMS_RLS.STATIC
  → 静的ポリシー。データベースは各問合せについてポリシーファンクションを1度だけ実行し、2回目以降の処理ではSGAにキャッシュされた述語を利用するだけのため、高速。ポリシーファンクションを再構築する予定がないのであればSTATICにしておくとよい。
  ※「DBMS_RLS.SHARED_STATIC
  → STATICと同じ特徴に加え、複数のポリシーで同じポリシーファンクションを使用できる。
  ※「DBMS_RLS.CONTEXT_SENSITIVE
   → 状況依存ポリシー。基本的には静的ポリシーと同じだが、アプリケーションコンテキストを使用した述語において、コンテキストがなんらかの方法で変化する可能性がある場合に備え、セッションメモリーにキャッシュする。2回目以降の処理では、セッションメモリーのキャッシュを検索するため、比較的高速。
  ※「DBMS_RLS.SHARED_CONTEXT_SENSITIVE
   → CONTEXT_SENSITIVEと同じ特徴に加え、複数のポリシーで同じポリシーファンクションを使用できる。
  ※「DBMS_RLS.DYNAMIC」
   → 動的ポリシー。Oracle9iと同じ方式。ポリシーを施行した表へのアクセスのたびにポリシーファンクションを評価する。ポリシーファンクションがたびたび変化するならば動的ポリシーにするとよいが、基本的には低速

  ※ポリシータイプは、ポリシー作成(DBMS_RLS.ADD_POLICY)のPOLICY_TYPEパラメータで設定する。

・コマンドに関する説明として正しいもの
EXEC DBMS_FGA.ADD_POLICY ( -
object_schema => 'hr', -
object_name => 'employees', -
policy_name => 'hr_policy', -
audit_confiltered=> NULL, -
audit_column => 'salary, commission_pct', -
audit_column_opts => DBMS_FGA.ALL_COLUMNS, -
audit_trail    => DBMS_FGA.DB,       -
statement_types => 'insert, update');

  →監査証跡にはSQLテキストとSQLバインド情報は書き込まれない

  ※10gのファイングレイン監査(FGA)では、次の機能が追加されている。

  ※「DML文のサポート」
   INSERT、UPDATE、DELETE、MERGE文の監査が可能。監査するSQL文は、DBMS_FGA.ADD_POLICYのSTATEMENT_TYPESパラメータで指定する
  ※「複数列のサポート」
   Oracle9iでは、列を指定(AUDIT_COLUMNパラメータ)すると、その列すべてを含む場合のみ監査対象であったが、いずれかを含む場合という指定が可能となった。DBMS_FGA.ADD_POLICYのAUDIT_COLUMN_OPTSパラメータで次の値によって使い分けることができる
   - DBMS_FGA.ALL_COLUMNS すべての列が含まれる場合
   - DBMS_FGA.ANY_COLUMNS いずれかの列が含まれる場合(デフォルト)
  ※「ポリシー述語のNULLサポート」
   DBMS_FGA.ADD_POLICYのAUDIT_CONDITIONパラメータは、すべての行を監査対象とする場合、Oracle9iでは、「1=1」などの指定が必要であったが、NULLが指定(デフォルト)できるようになった。NULLが設定されているとき、すべての行が監査対象となる
  ※「SQL情報の書込みをさせない」
   Oracle9iでは、監査証跡には常にSQLテキストとSQLバインド情報が書き込まれていたが、書き込ませない設定が可能となった。DBMS_FGA.ADD_POLICYのAUDIT_TRAILパラメータの次の値によって使い分けることができる
   - DBMS_FGA.DB SQLテキストとSQLバインド情報は書き込まない
   - DBMS_FGA.DB_EXTENDED SQLテキストとSQLバインド情報を書き込む(デフォルト)

・ポリシーファンクションから戻された述語がセッションメモリーに保持されるポリシータイプ
  →DBMS_RLS.CONTEXT_SENSITIVE
  →DBMS_RLS.SHARED_CONTEXT_SENSITIVE

ADDM

・Automatic Database Diagnostic Monitor(ADDM)の特徴に関する説明
  →問題の原因を特定し、推奨事項を生成する
  →問題のないシステム領域もドキュメント化する
  →結果は自動ワークロードリポジトリ(AWR)に格納される

 ※Automatic Database Diagnostic Monitor(ADDM)は、自己診断エンジンとしてOracleデータベース内に格納、構築された機能。この機能の仕事は総合的な診断を行うところにあり、実際の処置はSQLチューニングアドバイザやSQLアクセスアドバイザなどのコンポーネントに任る。
 ※10gでは、問題の検出や自己チューニングを目的としたパフォーマンス統計の収集、処理、メンテナンスのための「自動ワークロードリポジトリ(AWR)」が提供されており、ADDMの診断結果もまたAWRに格納される。
 ※ADDMは、診断結果を作成するために問題の根本的な原因を特定し、その結果が及ぼす影響と推奨事項を生成します。このとき、問題が発生していない領域もドキュメント化することで、そのような領域の修正が不要であるという情報も知ることができるようになっている。

AutomaticUndoRetentionTuning(自動UNDO保存チューニング)

自動UNDO保存チューニングに関する説明として正しいもの
  →デフォルトで有効である
  →最長の問合せにあわせてUNDOデータの保存期間が自動調整される

  ※10gでは、自動UNDO機能(UNDO_MANAGEMENT=AUTO)を使用している場合、UNDOデータの保存期間はデフォルトで自動調整される。この機能により、UNDO_RETENTION初期化パラメータで指定する値は、UNDOデータの保存期間の最小値として動作することになり、問合せの時間が30秒毎に収集され、最長の問合せにあわせてUNDOデータの保存期間が自動調整されます。ただし、UNDO表領域のサイズが不足している場合などは、UNDO保存期間を段階的に小さくしたり、もっとも古いエクステントから再利用するなどの調整が入ることになります。


◆データベース管理・監視の自動化
FlashbackTable機能

表領域の名前変更
・デフォルト一時表領域として設定されているTEMP表領域に対し、次のコマンドを実行しました結果。

  ALTER TABLESPACE temp RENAME TO temp01;

  →表領域名は変更され、デフォルト一時表領域名および一時表領域としてTEMPが設定されていたユーザーの一時表領域名はTEMP01に変更される
  ※10gから、表領域名の変更が可能になった。これにより、従来まではなんらかの形式でデータをコピー(exp/impや別表領域に退避など)してから表領域を再作成するなどの手順が必要なくなり、特に同じ表領域名のためにトランスポータブル表領域を使用できないといったことがなくなりました(トランスポートする前にソースデータベースで表領域名を変更しておくか、ターゲットデータベースで表領域名を変更しておくことができる)。

  ALTER TABLESPACE tablespace_name RENAME TO new_tablespace_name;

  ※ただし、表領域名の変更は、ローカル管理表領域のみ可能で、SYSTEM表領域、SYSAUX表領域を除く表領域に限る。
  ※COMPATIBLE初期化パラメータは10.0.0以上である必要があります。
  ※この問題のようにインスタンスで使用するデフォルト一時表領域に指定されている場合でも表領域名の変更は可能。

SQL> SELECT property_value FROM database_properties
2 WHERE property_name = ’DEFAULT_TEMP_TABLESPACE’;

PROPERTY_VALUE
--------------
TEMP

SQL> SELECT temporary_tablespace FROM dba_users
2 WHERE username = ’SCOTT’;

TEMPORARY_TABLESPACE
------------------------------------------------------
TEMP

SQL> ALTER TABLESPACE temp RENAME TO temp2;

SQL> SELECT property_value FROM database_properties
2 WHERE property_name = ’DEFAULT_TEMP_TABLESPACE’;

PROPERTY_VALUE
--------------
TEMP2

SQL> SELECT temporary_tablespace FROM dba_users
2 WHERE username = ’SCOTT’;

TEMPORARY_TABLESPACE
-----------------------------------------------
TEMP2

  ※上記のとおり、デフォルト一時表領域が割り当てられていたユーザーの一時表領域も自動的に変更されます。


・UNDO表領域として設定されているUNDOTBS1表領域に対し、次のコマンドを発行しました。このコマンドの実行結果。

ALTER TABLESPACE undotbs1 RENAME TO undotbs2;

  →表領域名は変更され、UNDO_TABLESPACE初期化パラメータも変更される
  ※10gから、表領域名の変更が可能になりました。これにより、従来まではなんらかの形式でデータをコピー(exp/impや別表領域に退避など)してから表領域を再作成するなどの手順が必要なくなり、特に同じ表領域名のためにトランスポータブル表領域を使用できないといったことがなくなりました(トランスポートする前にソースデータベースで表領域名を変更しておくか、ターゲットデータベースで表領域名を変更しておくことができる)。

ALTER TABLESPACE tablespace_name RENAME TO new_tablespace_name;


表領域名の変更後、下記のように、初期化パラメータの一部はすぐに変更が表示できないものもあります。しかしながら内部的には同期がとれているので問題はありません。

SQL> SELECT tablespace_name FROM dba_tablespaces;

TABLESPACE_NAME
---------------
SYSTEM
UNDOTBS2
SYSAUX
TEMP
USERS
EXAMPLE

SQL> SELECT segment_name, tablespace_name, status FROM dba_rollback_segs;

SEGMENT_NAME TABLESPACE_NAME STATUS
------------------------------ --------------- ----------
SYSTEM SYSTEM ONLINE
_SYSSMU1$ UNDOTBS2 ONLINE
_SYSSMU2$ UNDOTBS2 ONLINE
_SYSSMU3$ UNDOTBS2 ONLINE
_SYSSMU4$ UNDOTBS2 ONLINE
_SYSSMU5$ UNDOTBS2 ONLINE
_SYSSMU6$ UNDOTBS2 ONLINE
_SYSSMU7$ UNDOTBS2 ONLINE
_SYSSMU8$ UNDOTBS2 ONLINE
_SYSSMU9$ UNDOTBS2 ONLINE
_SYSSMU10$ UNDOTBS2 ONLINE
_SYSSMU11$ UNDOTBS2 OFFLINE
_SYSSMU12$ UNDOTBS2 OFFLINE
_SYSSMU13$ UNDOTBS2 OFFLINE
_SYSSMU14$ UNDOTBS2 OFFLINE
_SYSSMU15$ UNDOTBS2 OFFLINE
_SYSSMU16$ UNDOTBS2 OFFLINE
_SYSSMU17$ UNDOTBS2 OFFLINE
_SYSSMU18$ UNDOTBS2 OFFLINE
_SYSSMU19$ UNDOTBS2 OFFLINE

SQL> SHOW PARAMETER UNDO_TABLESPACE

NAME TYPE VALUE
------------------------------- ----------- ---------------
undo_tablespace string UNDOTBS1

AutomaticStorageManagement

・/devices/A1デバイスは、dgroup1ディスクグループのメンバー。
 下記のコマンドの結果として正しいもの。

 CREATE DISKGROUP dgroupA NORMAL REDUNDANCY
 FAILGROUP controller1 DISK
  ’/devices/A1’,
  ’/devices/A2’,
  ’/devices/A3’
 FAILGROUP controller2 DISK
  ’/devices/A4’,
  ’/devices/A5’,
  ’/devices/A6’;

  →/devices/A1が別のディスクグループのメンバーのためエラーとなる

  ※自動記憶域管理(ASM)を使用することで、Oracle用に設計された論理ボリュームマネージャを使用できます。従来のサードパーティ製のボリュームマネージャ(LVM)を使用することなく、ディスクのストライピング、ミラーリングを提供する。
  ※ASMでは、ASMディスクグループの作成時にASMディスクを指定し、ミラー化レベルを指定できます。問題でも使用しているNORMAL REDUNDANCYは通常の冗長性で、少なくとも2つの障害グループを持ちます。
  ※ASMディスクに指定したディスクが、すでに別のASMディスクグループで使用されている場合、FORCEオプションを指定しない限りはエラーとなる。

列レベルのVPDポリシー

・このコマンドに関する説明として正しいもの。

 EXEC DBMS_RLS.ADD_POLICY (      -
  object_schema   => ’hr’,    -
  object_name    => ’employees’,-
  policy_name    => ’hr_policy’,-
  function_schema  => ’hr’,    -
  policy_function  => ’hrsec’,  -
  long_predicate  => true,     -
  statement_types  => ’select’,  -
  sec_relevant_cols => ’salary,commission’)

  →ポリシーファンクションから32KB以下の述語を戻すことができる
  →SALARY列とCOMMISSION列にアクセスするSELECT文でのみポリシーが施行される

  ※10gのファイングレインアクセスコントロール(FGAC)では、列レベルの制限が可能になりました。ポリシーを作成するときに、SEC_RELEVANT_COLSパラメータで列を指定すると、その列に対するアクセス(*やCOUNT(*)などの暗黙的なアクセスも含める)があるときのみ制限を行うことができます。
  ※また、LONG_PREDICATEパラメータがTRUEの時は、ポリシーファンクションが戻す述語として32KBまでのサイズを戻すことが可能になっています。このパラメータがFALSE(デフォルト)の場合は、ポリシー述語は4000バイト以下である必要があります。


OracleNetServicesの管理

Oracle Database 10gのOracle Net Servicesの新機能

バックアップ新機能
・高速増分バックアップに関連する説明

  →ブロックチェンジトラッキングファイルへの書込みはCTWRが行う
  →ブロックチェンジトラッキングファイルにはOMFを使用できる
  →REDOログの生成時に変更されたブロックが追跡される


・ブロックチェンジトラッキングを有効化した場合、ブロックチェンジトラッキングファイルへの書込みを行うバックグラウンドプロセス。

  →CTWR

  ※10gのRMANによるバックアップでは、高速増分バックアップがサポートされています。高速増分バックアップでは、ブロックチェンジトラッキングファイルを使用し、このファイル内にREDO生成時に変更されたブロックが追跡されるようになっている。RMANを使用した増分バックアップでは、ブロックチェンジトラッキングファイルを確認し、必要なブロックのみアクセスするため、高速なバックアップが可能となっている。

  ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING ’ファイル名’;

  ※上記の構文を使用してブロックチェンジトラッキングを有効化すると、CTWR(Change Tracking Writer)という新しいバックグラウンドプロセスが起動する。CTWRは、ブロックチェンジトラッキングファイルへの書込みを行う。


・RESETLOGSに関する情報がアーカイブログファイルに含まれるようにするための、変数を選択しなさい。

  →%r

 ※10gからアーカイブログファイルにRESETLOGS識別子とよばれるRESETLOGSを行うたびに異なる番号が割り当てられる識別子を含めることができるようになりました。これにより、RESETLOGSでオープンする前に取得したバックアップをRESETLOGSでオープンした後のリカバリにも利用できるようになりました(以前のバックアップでも、RESETLOGS識別子によって、どのアーカイブログファイルを適用すればよいかが判断できる)。
 ※RESETLOGS識別子をアーカイブログファイルに含めるためには、LOG_ARCHIVE_FORMATにて「%r」を含めるようにします。デフォルトでは、「%t_%s_%r.dbf」です(Windowsは「ARC%S_%R.%T」)。
 ※「%t」→ スレッド番号。RAC環境では、インスタンスごとにREDOログスレッドが作成されるため、RAC環境では必要です。
 ※「%s」→ ログ順序番号です。

・RMANを使用して、フラッシュリカバリ領域からバックアップされていないものをテープにバックアップできるコマンド。

  →BACKUP RECOVERY FILES;
  →BACKUP RECOVERY AREA;

  ※フラッシュリカバリ領域からテープへのバックアップをサポートするコマンドとして次の2つがある。

  ・「BACKUP RECOVERY AREA;」
   → フラッシュリカバリ領域からテープにバックアップされていないものをバックアップ
  ・「BACKUP RECOVERY FILES;」
   → テープにバックアップされていないディスク上のものをバックアップ

  ※これらのコマンドでは、全体バックアップ、増分バックアップ、制御ファイル自動バックアップ、アーカイブログファイル、データファイルコピーがバックアップされる。
さて、そろそろお勉強の再開です・・・疲れるねぇ・・しかし^^;

高速増分バックアップに関連する説明として正しいもの
  →ブロックチェンジトラッキングファイルへの書込みはCTWRが行う
  →REDOログの生成時に変更されたブロックが追跡される
  →ブロックチェンジトラッキングファイルにはOMFを使用できる

  ※「ブロックチェンジトラッキングファイルへの書込みはCTWRが行う」
  ※ ブロックチェンジトラッキングファイルへの書込みはCTWR(Change Tracking Writer)が行います。このバックグラウンドプロセスは、高速増分バックアップが有効になっているときに起動する。
  ※「REDOログの生成時に変更されたブロックが追跡される」
  ※ 高速増分バックアップ機能では、REDOログの生成時に、CTWRバックグラウンドプロセスによってブロックチェンジトラッキングファイルへの書込みが行われる。
  ※ 高速増分バックアップを有効化するときに、OMFのための初期化パラメータであるDB_CREATE_FILE_DEST初期化パラメータが有効であれば、ブロックチェンジトラッキングファイル名を指定する必要はない。
   OMF無効時:ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING ’ファイル名’;
   OMF有効時:ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Oracleスケジューラを使用することで可能となる処理
  →OS上のシェルスクリプトを実行するジョブを作成できる
  →スケジュールとプログラムを再利用したジョブを作成できる
  →リソースプランを使用した優先順位を設定できる

■間違った項目の問題の復習でふ・・・orz
◆Undo Advisor(UNDOアドバイザ)

24時間以内の情報を使用して、UNDOデータが3日間は保証されるようにするにはどのくらいのUNDO表領域のサイズが必要かどうかを確認するには、どのようにしたらよいか。
  →「UNDOアドバイザ」ページでUNDO保存期間を3日間とし、分析期間を「過去1日間」に設定して分析とグラフの更新を実行する

・自動UNDO保存チューニングに関する説明として正しいもの
  →最長の問合せにあわせてUNDOデータの保存期間が自動調整される
  →デフォルトで有効である
  ※10gでは、自動UNDO機能(UNDO_MANAGEMENT=AUTO)を使用している場合、UNDOデータの保存期間はデフォルトで自動調整される。この機能により、UNDO_RETENTION初期化パラメータで指定する値は、UNDOデータの保存期間の最小値として動作することになり、問合せの時間が30秒毎に収集され、最長の問合せにあわせてUNDOデータの保存期間が自動調整されます。ただし、UNDO表領域のサイズが不足している場合などは、UNDO保存期間を段階的に小さくしたり、もっとも古いエクステントから再利用するなどの調整が入ることになる。

UNDOアドバイザページを使用して推奨される要素
  →現在のUNDO表領域にて可能な保持期間
  →UNDOデータの保存に必要な表領域サイズ
  →拡張可能なUNDO表領域の最大サイズ

 ※そういえば、Undoアドバイザのグラフから推奨される表領域を答えるような問題がでてたような・・・こんな感じかしら?↓グラフの見方は理解しておかなきゃないって事ですな。しかし、よく考えたら、「UNDO保存○○日で何MBが推奨されてるか?」って問題だったとしたら、スゲー単純な話だったわけですなぁ・・・ただ、アップしたサンプルのグラフよりも、問題のグラフのほうが吹き出しが多かったような気がする。

UNDOアドバイザのグラフ


一時表領域グループのユーザー割り当て

・一時表領域グループに関する説明として正しいもの
  →デフォルト一時表領域に一時表領域グループ名を指定することができる
  →デフォルト一時表領域に一時表領域グループ名を指定しているときは、そのグループに含まれる一時表領域を削除できない
  →デフォルト一時表領域に一時表領域グループ名を指定しているときはグループを削除することはできない

 ※一時表領域グループとは、その名のとおり、一時表領域をグループ化して管理すること。一時表領域でなく一時表領域グループを割り当てられたユーザーは、同じユーザー名でもそのグループ内の異なる表領域を使用できます。また、パラレルクエリーを実行するときは、各クエリープロセスで異なる一時表領域を使用することができる。このように一時表領域グループを使用することで、一時表領域の使用を分散することができる。
 ユーザーの一時表領域を一時表領域グループ名にするときは、従来と同じく「ALTER USER user_name TEMPORARY TABLESPACE」コマンドを使用し、グループ名を指定する。

SQL> SELECT * FROM dba_tablespace_groups;

GROUP_NAME TABLESPACE_NAME
--------------- ---------------
TEMP_G1 TEMP
TEMP_G1 TEMP2

SQL> ALTER USER hr TEMPORARY TABLESPACE temp_g1;


パーティションでのDDL実行中のグローバル索引のメンテナンス

・ハッシュパーティショングローバル索引で使用することのできないメンテナンスコマンド
  →ALTER INDEX ... MODIFY PARTITION ... NOLOGGING;
  ※Oracle Database 10gから可能なハッシュパーティショングローバル索引では、レンジパーティショングローバル索引であれば可能なコマンドの一部が使用できない。

  ※「MODIFY PARTITION」
   UNUSABLE句を除き、ハッシュパーティショングローバル索引ではMODIFY PARTITIONは使用できない。

SQL> SELECT index_name,partitioning_type,partition_count,locality,alignment
2 FROM user_part_indexes
3 WHERE index_name LIKE ’SALES1%’;

INDEX_NAME PARTITIONING_T PARTITION_COUNT LOCALITY ALIGNMENT
-------------------- -------------- --------------- ------------ --------------
SALES1_PROD_ID_IDX HASH 4 GLOBAL PREFIXED
SALES1_PROM_ID_IDX RANGE 4 GLOBAL PREFIXED
SALES1_TIME_ID_IDX RANGE 28 LOCAL PREFIXED

SQL> ALTER INDEX sales1_prom_id_idx
2 MODIFY PARTITION sales1_prom_id_idx_p1 NOLOGGING;

索引が変更されました。

SQL> ALTER INDEX sales1_prod_id_idx
2 MODIFY PARTITION sys_p453 NOLOGGING;
MODIFY PARTITION sys_p453 NOLOGGING
*
行2でエラーが発生しました。:
ORA-14192: ハッシュ索引パーティションの物理索引属性は変更できません。

SQL> ALTER INDEX sales1_prod_id_idx
2 MODIFY PARTITION sys_p453 UNUSABLE;

索引が変更されました。


・10gで作成可能なグローバル索引
  →ハッシュパーティション
  →レンジパーティション

  ※10gでは、グローバル索引としてレンジパーティションとハッシュパーティションをサポートします(Oracle9iではレンジパーティションのみ)。
 レンジパーティションの場合は、パーティション範囲に基づいてデータが格納されますが、ハッシュパーティションではパーティションキーをハッシングしてデータを分散します。そのため、INSERT文で常に大きい値が格納されるような列の索引では、レンジを使うよりハッシュを使ったほうが競合を減らすことができる(逆キー索引と考え方は同じ)。
 SQL> CREATE INDEX sales1_prod_id_idx ON sales1(prod_id) GLOBAL
  2  PARTITION BY HASH (prod_id)
  3  PARTITIONS 4
  4  STORE IN (ts01,ts02,ts03,ts04);


http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/server.111/E05765-02/partconc.htm#655747
グローバル・パーティション索引のメンテナンス

デフォルトでは、ヒープ構成表のパーティションに次の操作を行うと、グローバル索引すべてにUNUSABLEマークが設定されます。

 ADD (HASH)
 COALESCE (HASH)
 DROP
 EXCHANGE
 MERGE
 MOVE
 SPLIT
 TRUNCATE

操作のためのSQL文にUPDATE INDEXES句を追加すると、これらの索引をメンテナンスできます。グローバル索引をメンテナンスすることには、次の2つの利点があります。

* 操作の間中、索引が使用可能かつオンラインな状態にあります。そのため、他のアプリケーションがこの操作の影響を受けません。
* 操作の後、索引を再作成する必要がありません。

例:ALTER TABLE DROP PARTITION P1 UPDATE INDEXES;

フラッシュバック・データーベース・ログに関する説明

・フラッシュバックデータベースを構成するための設定を3つ選択しなさい。

  →ALTER DATABASE FLASHBACK ON;
  →ARCHIVELOGモードにする
  →フラッシュリカバリ領域を構成する

・次のコマンドを発行しました。
  ALTER DATABASE FLASHBACK ON;
  フラッシュバックデータベースが正しく有効になったことを確認するために使用されるビュー
  →V$DATABASE
  
  ※10gでサポートするフラッシュバックデータベースは、フラッシュバックログを使用して、データベースを過去の状態にリカバリする(巻き戻す)機能です。この機能のメリットは、バックアップのリストア作業がいらないため、非常に高速に不完全リカバリができること、RESETLOGSでオープンする前に読取専用でオープンしてデータを確認できることです。
   V$DATABASEビューのFLASHBACK_ON列を使用して、フラッシュバックデータベース機能が有効であるかどうかを確認できます。
   SQL > SELECT flashback_on FROM v$database;
   FLA
   ----
   YES
フラッシュバックデータベースを使用できない状況

  →RESETLOGS操作前の時点にフラッシュバックを行う
  →制御ファイルがリストアまたは再作成されている
  →表領域が削除されている
  →データファイルが縮小されている

  ※10gでサポートするフラッシュバックデータベースは、フラッシュバックログを使用して、データベースを過去の状態にリカバリする機能(巻き戻す)です。この機能のメリットは、バックアップのリストア作業がいらないため、非常に高速に不完全リカバリができること、RESETLOGSでオープンする前に読取専用でオープンしてデータを確認できることです。

ブロック・メディア・リカバリ(BMR)、試行リカバリ<Part2>
http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/backup.111/E05700-02/rcmblock.htm

ブロック・メディア・リカバリを使用すると、データファイル内の1つ以上の破損したデータ・ブロックをリカバリできます。ブロック・メディア・リカバリには、データファイルのメディア・リカバリにはない次のようなメリットがあります。

  * リカバリが必要なブロックのみがリストアおよびリカバリされるため、平均リカバリ時間が小さくなります。
  * リカバリ中、影響を受けるデータファイルをオンラインのままにしておくことができます。
   ブロック・メディア・リカバリを使用しないと、1つのブロックが破損した場合でも、データファイルをオフラインにしてデータファイルのバックアップをリストアする必要があります。バックアップの作成後にデータファイルに対して生成されたすべてのREDOを適用する必要があります。メディア・リカバリが完了するまで、ファイル全体が使用不可となります。ブロック・メディア・リカバリを使用すると、実際にリカバリされているブロックのみがリカバリ中に使用不可となります。
  破損ブロックの識別

V$DATABASE_BLOCK_CORRUPTIONビューに、Recovery Managerコマンド、ANALYZE、dbv、SQL問合せなどのデータベース・コンポーネントによって破損とマークされたブロックが表示されます。次のタイプの破損が、このビューに行として追加されます。


 ・ブロック・メディア・リカバリの前提条件
 次の前提条件がRECOVER ... BLOCKコマンドに適用されます。

* ターゲット・データベースがARCHIVELOGモードで実行されており、現行の制御ファイルを使用してオープンまたはマウントされている必要があります。
* ターゲット・データベースは、スタンバイ・データベースにすることができません。
* 破損ブロックが含まれているデータファイルのバックアップは、プロキシ・コピーではなく全体またはレベル0のバックアップである必要があります。
プロキシ・コピー・バックアップのみが存在する場合は、それらをディスク上のデフォルト以外の場所にリストアできます。この場合、Recovery Managerは、プロキシ・バックアップをデータファイルのコピーとみなして、ブロック・メディア・リカバリ中にプロキシ・バックアップ内のブロックを検索します。
* Recovery Managerは、リカバリでアーカイブREDOログのみを使用できます。
Recovery Managerは、レベル1の増分バックアップを使用できません。ブロック・メディア・リカバリでは、アーカイブREDOログが欠落しているか、またはアクセスできない場合はリカバリを実行できません。ただし、REDOレコードが欠落している場合はリカバリを実行できる場合もあります。
* Recovery Managerがフラッシュバック・ログで破損ブロックの完全な状態に近いコピーを検索するには、フラッシュバック・データベースがターゲット・データベースで有効になっている必要があります。

破損していない古いバージョンの破損ブロックが含まれている場合にフラッシュバック・ロギングが有効になっていると、Recovery Managerは、それらのブロックを使用し、リカバリに必要な時間を短縮できます。


個々のブロックのリカバリ

通常、ブロック破損は次の場所に表示されます。

* LIST FAILURE、VALIDATEまたはBACKUP ... VALIDATEコマンドの結果
* V$DATABASE_BLOCK_CORRUPTIONビュー
* 標準出力のエラー・メッセージ
* アラート・ログ
* ユーザー・トレース・ファイル
* SQLコマンドANALYZE TABLEおよびANALYZE INDEXの結果
* DBVERIFYユーティリティの結果
* サード・パーティのメディア管理の出力

特定のデータ・ブロックをリカバリする手順

1. 破損ブロックのデータファイル番号およびブロック番号を取得します。
トレース・ファイルおよびアラート・ログを検索する最も簡単な方法は、SQL*Plusをターゲット・データベースに接続し、次の問合せを実行する方法です。

SELECT NAME, VALUE
FROM V$DIAG_INFO;

2. Recovery Managerを起動し、ターゲット・データベースに接続します。ターゲット・データベースは、マウントまたはオープンされている必要があります。
3. SHOW ALLコマンドを実行して、適切なチャネルが事前構成されていることを確認します。
4. Recovery Managerプロンプトで、ファイルおよび破損ブロックのブロック番号を指定してRECOVER ... BLOCKコマンドを実行します。

次の例では、2つのブロックをリカバリします。

RECOVER
DATAFILE 8 BLOCK 13
DATAFILE 2 BLOCK 19;

Recovery Managerの動作を制御する様々なオプションを指定することもできます。次の例は、ブロックの検索時にタグmondayamが含まれているバックアップのみが使用されることを示しています。FROM BACKUPSETオプションを使用して、Recovery Managerによって検索されるバップアップのタイプを制限できます。または、EXCLUDE FLASHBACK LOGを使用して、Recovery Managerによるフラッシュバック・ログの検索を制限できます。

RECOVER
DATAFILE 8 BLOCK 13
DATAFILE 2 BLOCK 199
FROM TAG mondayam;

V$DATABASE_BLOCK_CORRUPTION内のすべてのブロックのリカバリ

この例では、Recovery ManagerがV$DATABASE_BLOCK_CORRUPTIONビューに表示されているすべてのブロックを自動的にリカバリします。
V$DATABASE_BLOCK_CORRUPTIONに記録されているすべてのブロックをリカバリする手順

  1. SQL*Plusを起動し、ターゲット・データベースに接続します。
  2. V$DATABASE_BLOCK_CORRUPTIONを問い合せて、破損ブロックが存在するかどうかを確認します。たとえば、次の文を実行します。

   SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;

  3. Recovery Managerを起動し、ターゲット・データベースに接続します。
  4. V$DATABASE_BLOCK_CORRUPTION内の破損とマークされたすべてのブロックをリカバリします。
   次のコマンドを実行すると、ビューに記録された物理的に破損しているすべてのブロックが修復されます。

  RMAN> RECOVER CORRUPTION LIST;

  ブロックは、修復された後、データベースによってV$DATABASE_BLOCK_CORRUPTIONから削除されます。

・ブロック・メディア・リカバリ(BMR)
  BLOCKRECOVERコマンドを実行すると、破損したブロックだけのリストア、リカバリを行うことができる。
  BMRを使用する場合、データファイルをオフラインにする必要がなく、データファイル全体をリストアする必要もないためMTTRが短縮される。
  破損ブロックはトレースファイルかV$BACKUP_CORRUPTIONビュー、V$COPY_CORRUPTIONビューを参照して判断することができる。
 
・試行リカバリ
 RECOVER DATABASEコマンドにTEST句を指定すると試行リカバリを実行することができる。これによりリカバリ不可能なデータブロックリカバリが失敗する可能性を予測することができる。破損ブロックを無視してリカバリを行う場合はRECOVER DATABASEコマンドにALLOW n CORRUPTION句を指定して実行する。

※試行リカバリ
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/backup.102/B19192-02/ostroubl006.htm#CIHEDGCC
リカバリの問題が分離されているかどうかを確認するために、診断用の試行リカバリを実行できます。試行リカバリでは、REDOストリームをスキャンして問題が検索されますが、リカバリされたデータベースに対して実際の変更は行いません。試行リカバリでリカバリの問題が検出された場合、alert_SID.logで報告されます。 試行リカバリを起動するには、RECOVER ... TEST文を使用します。

試行リカバリの仕組み

デフォルトでは、試行リカバリでスタック・リカバリやその他の問題が検出されると、常に、メモリー内でデータ・ブロックに破損しているというマークが付けられます(このアクションによってリカバリを続行できる場合)。試行リカバリ中に生成されたエラーは、アラート・ファイルに書き込まれます。これらのエラーは、テスト実行のエラーであることが明示されます。

試行リカバリでは、通常のメディア・リカバリと同様に、アーカイブ・ログのファイル名を指定するプロンプトが表示され、ユーザーは、ログを適用するかどうかを判断するように求められます。試行リカバリは次の場合に終了します。

  * 試行リカバリ用に使用できるメモリー内の最大バッファ数がすべて使用された場合
  *リカバリ不能なエラー(データ・ブロックを破損させても解決できないエラー)が通知された場合
  *ユーザーがリカバリ・セッションを取り消したか中断した場合
  *REDOストリーム内の次のREDOレコードによって制御ファイルが変更された場合
  *必要なREDOがすべて適用された場合

試行リカバリが終了すると、アラート・ファイル内のエラー・メッセージを除き、テスト実行のすべての影響がシステムから削除されます。試行リカバリ中にインスタンスの障害が発生した場合は、試行リカバリが変更をディスクに書き込むことはないため、試行リカバリのすべての影響がシステムから削除されます。

試行リカバリを使用することによって、通常のリカバリを続行した場合に発生する可能性のある問題を予測できます。進行中のメモリーの破損を原因とする問題の場合は、試行リカバリと通常のリカバリで発生するエラーが異なることがあります。
RECOVER ... TEST文の実行

TESTオプションはすべてのRECOVERコマンドで使用できます。たとえば、SQL*Plusを起動し、次のいずれかのコマンドを発行できます。

 RECOVER DATABASE TEST
 RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL TEST
 RECOVER TABLESPACE users TEST
 RECOVER DATABASE UNTIL CANCEL TEST

 ※↑こんな問題でてたなぁ・・・「TESTなんて句しらねぇ~^^;;」って思ったしな・・(汗

RecoveryManagerの使用

・RMANを使用して非ASMファイルをASMファイルに移行したときに自動で再作成されるもの
  →CONTROL_FILES初期化パラメータ

 ※前提には、サーバーパラメータファイル(SPFILE)とOMFを使用したデータベースの移行という条件がつきます。

 ※データベースで使用しているファイルを非ASMファイルからASMファイルに移行する手順は次のとおりです。
  ①既存のファイルの確認
  V$CONTROLFILE、V$LOGFILEビューを使用して、制御ファイルとREDOログファイル名を確認しておきます。
  ②SPFILEの修正
  CONTROL_FILES初期化パラメータを削除し、DB_CREATE_ONLINE_LOG_DEST_nパラメータにてASMディスクグループを指定しておきます。

  SQL> ALTER SYSTEM SET control_files=’’ SCOPE=SPFILE;
  SQL> ALTER SYSTEM SET DB_CREATE_ONLINE_LOG_DEST_1=’+dgroup1’;

  ③データベースの停止
  ④RMANコマンドを実行して移行

  RMAN> STARTUP NOMOUNT
  RMAN> RESTORE CONTROLFILE FROM ’/u01/oradata/ctrl1.ctl’;
  RMAN> ALTER DATABASE MOUNT;
  RMAN> BACKUP AS COPY DATABASE FORMAT ’+dgroup1’;
  RMAN> SWITCH DATABASE TO COPY;
  RMAN> SQL "ALTER DATABASE RENAME ’/u01/oradata/log1.log’ TO ’+dgroup1’";
  RMAN> SQL "ALTER DATABASE RENAME ’/u01/oradata/log2.log’ TO ’+dgroup1’";
  RMAN> ALTER DATABASE OPEN RESETLOGS;
  RMAN> SQL "ALTER TABLESPACE temp ADD TEMPFILE ’+dgroup1’";
  RMAN> SQL "ALTER DATABASE TEMPFILE ’/u01/oradata/temp01.dbf’DROP’";

上記のコマンドで、各データベースファイルがASMファイルになります。

  ※制御ファイルはOMFにてASMファイルが作成され、SPFILE内でCONTROL_FILES初期化パラメータが再設定されます。
  ※REDOログファイルは、ALTER DATABASE RENAME~コマンドで新しい名前で認識され、最後のALTER DATABASE OPEN RESETLOGSによってASMファイルになります。
  ※データファイルは、BACKUPコマンドでイメージコピーが作成され、そのファイルはASMファイルとしています。そのイメージコピーを現データベースとするようにSWITCHコマンドで切り替えています。
  ※一時ファイルに関してはバックアップされないので、手動で追加する。

ASMにデータベースを移行するためのコマンド
  RMAN > BACKUP AS COPY DATABASE FORMAT ’+dgroupA’;
  RMAN > SWITCH DATABASE TO COPY;

  ※データベースで使用しているファイルを非ASMファイルからASMファイルに移行するには、RMANを使用します。RMANを使用してASMファイルとしてバックアップを作成し、SWITCHコマンドを使用して制御ファイル内のデータファイルの場所を変更することで、非ASMファイルからASMファイルに移行することができる。

>>次のページ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。