3 ExadataでのOracle Databaseの管理
3.1 SQL処理のオフロードの管理
表スキャンおよび索引スキャンを実行する問合せのパフォーマンスを最適化するために、データベースではデータ検索および取得処理をExadataストレージ・サーバーにオフロードできます。この機能は、データベース初期化パラメータによって制御されます。
- CELL_OFFLOAD_PROCESSING
CELL_OFFLOAD_PROCESSING初期化パラメータでは、SQL処理をOracle Exadata Storage Serverにオフロードできます。 - CELL_OFFLOAD_PLAN_DISPLAY
データベース・パラメータのCELL_OFFLOAD_PLAN_DISPLAY
では、Oracle Exadata System Softwareで評価可能な条件を、SQLコマンドのSTORAGE
条件としてSQLEXPLAIN PLAN
コマンドで表示するかどうかを指定します。 - CELL_OFFLOAD_DECRYPTION
親トピック: ExadataでのOracle Databaseの管理
3.1.1 CELL_OFFLOAD_PROCESSING
CELL_OFFLOAD_PROCESSING初期化パラメータでは、SQL処理をOracle Exadata Storage Serverにオフロードできます。
パラメータの値をTRUE
に設定すると、条件評価をセルにオフロードできます。このパラメータのデフォルト値はTRUE
です。セッション・レベルまたはシステム・レベルでパラメータの値をFALSE
に設定すると、データベースでは、ブロックを使用するセルですべての条件評価が実行されます。SQLのALTER SYSTEM
コマンドまたはALTER SESSION
コマンドを使用すると、CELL_OFFLOAD_PROCESSINGを動的に設定できます。たとえば:
SQL> ALTER SESSION SET CELL_OFFLOAD_PROCESSING = TRUE;
OPT_PARAM
オプティマイザ・ヒントを使用してCELL_OFFLOAD_PROCESSINGパラメータを設定することもできます。これにより、特定のSQLコマンドで条件のフィルタ処理の有効/無効を切り替えることができます。
-
SQLコマンドのCELL_OFFLOAD_PROCESSINGを無効にするには:
SELECT /*+ OPT_PARAM('cell_offload_processing' 'false') */ COUNT(*) FROM EMPLOYEES;
-
SQLコマンドのCELL_OFFLOAD_PROCESSINGを有効にするには:
SELECT /*+ OPT_PARAM('cell_offload_processing' 'true') */ COUNT(*) FROM EMPLOYEES;
ノート:
CELL_OFFLOAD_PROCESSING初期化パラメータを使用して、Oracle Exadata Storage Serverと従来型のストレージのパフォーマンスを比較することはできません。CELL_OFFLOAD_PROCESSINGをFALSE
に設定した場合でも、Oracle Exadata Storage Serverには従来型のストレージよりも多くの利点があります。Oracle Exadata Storage Serverは、サイズの大きい問合せを高速に処理できるように最適化されています。セル内にコントローラまたはその他のレベルのボトルネックが発生することはありません。Oracle Exadataでは、最新のスケールアウト・アーキテクチャと、従来型のストレージ・ネットワークよりも非常に高いスループットを可能にする最先端のRDMAネットワーク・ファブリックを使用しています。Oracle ExadataはOracle Databaseと密接に統合されており、設定、実行、監視、診断、リソース管理および破損防止のための独自の機能が用意されています。
親トピック: SQL処理のオフロードの管理
3.1.2 CELL_OFFLOAD_PLAN_DISPLAY
データベース・パラメータのCELL_OFFLOAD_PLAN_DISPLAY
では、Oracle Exadata System Softwareで評価可能な条件を、SQLコマンドのSTORAGE
条件としてSQL EXPLAIN PLAN
コマンドで表示するかどうかを指定します。
CELL_OFFLOAD_PLAN_DISPLAY
パラメータの値は、AUTO
、ALWAYS
、NEVER
です。デフォルト値はAUTO
です。
-
AUTO
では、SQLEXPLAIN PLAN
コマンドに、STORAGE
として評価できる条件を表示するように指示します(セルが存在する場合で、そのセルに表がある場合のみ)。 -
ALWAYS
は、Oracle Exadata System Softwareが存在するか、または表がセル上にあるかどうかとは関係なく、Oracle Exadata System Softwareに基づいてSQLEXPLAIN PLAN
コマンドに対する変更を作成します。この設定を使用して、Oracle Exadata Storage Serverに移行する前にOracle Exadata Storage Serverにオフロード可能な内容を確認できます。 -
NEVER
では、Oracle Exadata System Softwareに関してSQLEXPLAIN PLAN
コマンドは変更されません。
SQLのALTER SYSTEM
コマンドまたはALTER SESSION
コマンドを使用すると、CELL_OFFLOAD_PLAN_DISPLAY
パラメータを動的に設定できます。たとえば:
SQL> ALTER SESSION SET cell_offload_plan_display = ALWAYS;
親トピック: SQL処理のオフロードの管理
3.1.3 CELL_OFFLOAD_DECRYPTION
CELL_OFFLOAD_DECRYPTION初期化パラメータでは、復号化をOracle Exadata Storage Serverにオフロードできます。この復号化は、暗号化された表領域と列の両方に適用されます。パラメータの値をTRUE
に設定すると、復号化をセルにオフロードできます。このパラメータのデフォルト値はTRUE
です。システム・レベルでパラメータの値をFALSE
に設定すると、データベースでは、ブロックを使用するセルですべての復号化が実行されます。SQL ALTER SYSTEM
コマンドを使用すると、CELL_OFFLOAD_DECRYPTIONを動的に設定できます。たとえば:
SQL> ALTER SYSTEM SET CELL_OFFLOAD_DECRYPTION = FALSE;
親トピック: SQL処理のオフロードの管理
3.2 Exadataスマート・フラッシュ・キャッシュの管理
Exadataスマート・フラッシュ・キャッシュは、頻繁に使用されるデータを高パフォーマンスのフラッシュ・メモリーに自動的にキャッシュします。
- デフォルトのキャッシュ・ポリシーのオーバーライド
- インメモリー列指向キャッシングの管理
- 分析ワークロードのためのExadataスマート・フラッシュ・キャッシュの最適化
- Exadataスマート・フラッシュ・キャッシュの手動移入
親トピック: ExadataでのOracle Databaseの管理
3.2.1 デフォルトのキャッシュ・ポリシーのオーバーライド
通常は必要ありませんが、CELL_FLASH_CACHE
セグメント記憶域オプションを使用して、Exadataスマート・フラッシュ・キャッシュの自動キャッシング・ポリシーをオーバーライドできます。STORAGE句は、表または他のオブジェクトに対するCREATE
およびALTER
コマンドの実行時に指定できます。
たとえば:
SQL> CREATE TABLE t1 (c1 number, c2 varchar2(200)) STORAGE (CELL_FLASH_CACHE KEEP);
CELL_FLASH_CACHE
オプションは、次の設定をサポートしています。
NONE
: この値により、Exadataスマート・フラッシュ・キャッシュは対応するセグメントをキャッシュしなくなります。周辺のデータベース・セグメントでこの設定を使用すると、より重要でアクセス頻度の高いデータベース・セグメントで、より多くのキャッシュ領域を使用できます。DEFAULT
: この値を指定すると、データベース・セグメントは、Exadataスマート・フラッシュ・キャッシュのデフォルトのLRU (最低使用頻度)アルゴリズムを使用してキャッシュされます。この値は、CELL_FLASH_CACHE
のデフォルト設定です。KEEP
: この値は、Exadataスマート・フラッシュ・キャッシュのセグメント優先度を高くします。この設定を使用すると、キャッシュ内の対応するセグメントのデータが保持される可能性を高めることができます。
CELL_FLASH_CACHE
セグメント・ストレージ・オプションは、パーティション化されたセグメントのパーティションごとに個別に設定できます。これは、予測可能な使用パターンに基づいて異なるパーティションのキャッシュ優先度に影響を与える場合に、特に役立ちます。CELL_FLASH_CACHE
セグメント・ストレージ・オプションをパーティションに設定するときに、DEFERRED INVALIDATION
句を追加できます。たとえば:
SQL> ALTER TABLE ptable MODIFY PARTITION p1 STORAGE (CELL_FLASH_CACHE KEEP) DEFERRED INVALIDATION;
このオプションを使用すると、依存カーソルをすぐに無効化することなく、セグメント・ストレージ・オプションを動的に変更できます。このオプションには、Oracle Databaseバージョン19.15とOracle Databaseバージョン21.6以降のリリースに含まれるバグ33456703のパッチが含まれているOracle Databaseソフトウェアが必要です。
例3-1 パーティションに対するCELL_FLASH_CACHEの設定
この例は、CREATE TABLE
コマンドで複数のパーティションに個別にCELL_FLASH_CACHE
を設定する方法を示しています。
CREATE TABLE ptable (c1 number, c2 clob) TABLESPACE TBS_1
PARTITION BY RANGE(c1) ( PARTITION p1 VALUES LESS THAN (100)
TABLESPACE TBS_2 STORAGE (CELL_FLASH_CACHE DEFAULT),
PARTITION p2 VALUES LESS THAN (200) TABLESPACE TBS_3
STORAGE (CELL_FLASH_CACHE KEEP));
例3-2 LOBセグメントに対するCELL_FLASH_CACHEの設定
この例は、CREATE TABLE
コマンドでLOBセグメントにCELL_FLASH_CACHE
を設定する方法を示しています。
CREATE TABLE tkbcsrbc (c1 number, l1 clob)
lob (l1) STORE AS securefile
(cache nologging STORAGE (CELL_FLASH_CACHE NONE))
PCTFREE 0 TABLESPACE tbs_93 STORAGE
(initial 128K next 128K pctincrease 0);
例3-3 CELL_FLASH_CACHEと組み合せたALTER TABLEの使用
STORAGE句の変更が許可されるオブジェクトの場合、これらの例に示すように、CELL_FLASH_CACHE
と組み合せてALTER
コマンドを使用できます。
ALTER TABLE tkbcsrbc STORAGE(CELL_FLASH_CACHE DEFAULT);
ALTER TABLE tkbcsrbc MODIFY LOB (l1) (STORAGE (CELL_FLASH_CACHE KEEP));
例3-4 ビューを使用したCELL_FLASH_CACHEストレージ句の問合せ
CELL_FLASH_CACHE
STORAGE句属性は、関連するオブジェクトに基づいたデータベース・ビューを使用して問い合せることができます。
SELECT TABLESPACE_NAME, TABLE_NAME, CELL_FLASH_CACHE FROM user_tables WHERE table_name='TKBCSRBC';
SELECT CELL_FLASH_CACHE FROM ALL_INDEXES WHERE index_name='TKBCIDX';
親トピック: Exadataスマート・フラッシュ・キャッシュの管理
3.2.2 インメモリー列指向キャッシングの管理
列キャッシュは、データを列形式で格納するExadataスマート・フラッシュ・キャッシュのセクションです。Oracle Databaseから指示された場合、Exadataは列キャッシュの一部を自動的に使用して、Oracle Database In-Memory形式でデータを保持します。この拡張機能を使用するためにExadataで必要な構成は何もありません。
この機能は、Oracle Database In-Memoryオプションのライセンスを所有している場合に使用可能です。この機能を有効にするには、次のいずれかのデータベース・インスタンス・パラメータを使用します。
-
INMEMORY_SIZE
データベース・インスタンス・パラメータをゼロより大きい値に設定します。 -
Oracle Databaseバージョン19.8.0.0.200714以降、
INMEMORY_FORCE=cellmemory_level
を設定できます。このオプションを使用すると、データベース・インスタンスで専用のインメモリー・キャッシュを使用せずに、Exadataスマート・フラッシュ・キャッシュでインメモリー列指向キャッシングを使用できます。
CELLMEMORY
セグメント・オプションを使用して、Exadataスマート・フラッシュ・キャッシュのインメモリー列指向キャッシングのデフォルトの動作をオーバーライドできます。
SQL> ALTER TABLE table_name [ [ NO ] CELLMEMORY [ MEMCOMPRESS FOR [ QUERY | CAPACITY ] [ LOW | HIGH ] ]
オプションおよび句 | 使用方法の説明 |
---|---|
NO CELLMEMORY |
表が12.1.0.2の列指向のフラッシュ・キャッシュ形式から12.2のDatabase In-Memory形式への書換え対象外であることを示します。 |
CELLMEMORY およびCELLMEMORY MEMCOMPRESS FOR CAPACITY |
表をデフォルトのOracle Database 12.2 In-Memoryの形式でキャッシュできます。以前に指定したNO CELLMEMORY 文を取り消すか、指定した圧縮レベルを変更する場合のみ、この句を使用する必要があります。
|
CELLMEMORY MEMCOMPRESS FOR QUERY |
このオプションは、MEMCOMPRESS FOR CAPACITY が指定された場合、インメモリー列ストアのデータをそれを下回るように圧縮する必要があることを示します。このオプションにより、問合せ時のパフォーマンスが向上しますが、約2倍のフラッシュ領域が必要です。
|
LOW およびHIGH |
現時点では実装されていません。 |
例3-5 同じ表でのCELLMEMORYおよびINMEMORYオプションの使用
INMEMORY
とCELLMEMORY
の両方を同じ表で使用できます。たとえば:
CREATE TABLE t (c1 NUMBER) INMEMORY CELLMEMORY MEMCOMPRESS FOR QUERY;
メモリーにロードされそうにない、優先順位の低い表がある場合に、これら2つのオプションを指定すると便利です。また、CELLMEMORY
を指定することでも、列指向の性能を得られます。
親トピック: Exadataスマート・フラッシュ・キャッシュの管理
3.2.3 分析ワークロードのためのExadataスマート・フラッシュ・キャッシュの最適化
デフォルトでは、Exadataスマート・フラッシュ・キャッシュは頻繁にアクセスされるデータのキャッシュを優先し、再利用の可能性が低いデータのキャッシュを制限します。具体的には、Exadataスマート・フラッシュ・キャッシュは、一時セグメントに関連付けられたI/Oを含む、再利用の可能性が低い大規模なI/Oによって占有されるキャッシュ領域の量を制限します。さらに、スラッシング(キャッシュから最近削除されたデータのキャッシュ)が検出されると、大規模なI/Oに関連するデータ(一時セグメント・データを含む)を削除することで、追加のキャッシュ領域が作成されます。
このアプローチは、オンライン・トランザクション処理(OLTP)ワークロードに当然適しています。ただし、大規模な結合およびソート操作を大規模な一時セグメントで処理する場合、通常、分析ワークロードではExadataスマート・フラッシュ・キャッシュのリソースが十分に活用されません。
Exadataスマート・フラッシュ・キャッシュを分析ワークロードに活用するために、Exadataでは、管理者がmain_workload_type
データベース・インスタンス・パラメータを設定することで、各データベースおよびプラガブル・データベース(PDB)のメイン・ワークロード・タイプを指定できます。
たとえば:
-
コンテナ・データベース(CDB)または非CDBの場合:
SQL> alter system set main_workload_type = [ OLTP | ANALYTICS ];
PDBの場合:
SQL> alter session container = <pdb_name>; SQL> alter system set main_workload_type = [ OLTP | ANALYTICS ];
使用可能なオプションは次のとおりです。
-
OLTP
: Exadataスマート・フラッシュ・キャッシュは頻繁にアクセスされるデータのキャッシュを優先し、再利用の可能性が低いデータのキャッシュを制限します。 -
ANALYTICS
: Exadataスマート・フラッシュ・キャッシュは、再利用の可能性が低いデータ・キャッシュの制限を緩和し、一時セグメントがほとんどのキャッシュを占有できるようにします。
この機能に関する次の詳細に注意してください。
-
この機能を有効にするには、Exadata I/Oリソース管理プラン(IORMPLAN)にデータベース間プラン(DBPLAN)の一部として関連付けられたデータベースが含まれている必要があり、プラン・ディレクティブに
flashCacheSize
属性を使用して指定されたフラッシュ・キャッシュ割当てが含まれている必要があります。たとえば、次のIORMPLANを使用するシステムでは、main_workload_type
設定は、sales
データベースとそれに含まれるPDBでのみ有効です。CellCLI> ALTER IORMPLAN dbplan=((name=sales, share=8, flashCacheSize=20G), - (name=finance, share=8, flashCacheLimit=10G, flashCacheMin=2G), - (name=dev, share=2, flashCacheLimit=4G, flashCacheMin=1G), - (name=test, share=1))
-
main_workload_type
設定は、PDB間で、またはCDBと任意のPDB間で異なる場合があります。PDBレベルの設定は、CDB設定より優先されます。 -
PDBに
main_workload_type
が設定されていない場合は、対応するCDB設定が使用されます。CDBにmain_workload_type
が設定されていない場合、デフォルト設定はOLTP
です。 -
最小システム要件:
-
Exadata System Softwareリリース22.1.12.0.0または23.1.3.0.0。
-
パッチ35017301を適用したOracle Database 19c。
-
親トピック: Exadataスマート・フラッシュ・キャッシュの管理
3.2.4 Exadataスマート・フラッシュ・キャッシュの手動移入
データのスキャン
Exadataスマート・フラッシュ・キャッシュがいっぱいでない場合は、通常は全表スキャンを介して必要なデータにアクセスするだけで、データをキャッシュに読み取ることができます。
Exadataスマート・フラッシュ・キャッシュに使用可能な領域があるかどうかを確認するには、FC_BY_ALLOCATED
メトリックをeffectiveFlashCacheSize
属性と比較します。たとえば、次の出力は、各セルに約4TBの使用可能領域が含まれることを示しています。
# FC_BY_ALLOCATED shows that each cell contains approximately 19 TB of data allocated
$ dcli -g cell_group cellcli -e list metriccurrent where name\=\"FC_BY_ALLOCATED\"
db01celadm01: FC_BY_ALLOCATED FLASHCACHE 19,313,940 MB
db01celadm02: FC_BY_ALLOCATED FLASHCACHE 19,311,784 MB
db01celadm03: FC_BY_ALLOCATED FLASHCACHE 19,311,688 MB
# effectiveCacheSize shows that each cell contains approximately 23 TB of flash cache space
$ dcli -g cell_group cellcli -e list flashcache attributes effectiveCacheSize detail
db01celadm01: effectiveCacheSize: 23.28692626953125T
db01celadm02: effectiveCacheSize: 23.28692626953125T
db01celadm03: effectiveCacheSize: 23.28692626953125T
次の問合せを使用して、必要なデータがExadataスマート・フラッシュ・キャッシュに移入されているかどうかを確認できます。
select name,value
from v$statname n,
v$mystat s
where s.statistic# = n.statistic#
and name in ('physical read IO requests','physical read requests optimized')
order by name;
たとえば:
-- get session statistics
SQL> select name,value
2 from v$statname n,
3 v$mystat s
4 where s.statistic# = n.statistic#
5 and name in ('physical read IO requests','physical read requests optimized')
6 order by name;
NAME VALUE
---------------------------------------------------------------- ----------
physical read IO requests 5
physical read requests optimized 11
// run the desired workload...
-- get session statistics again
SQL> select name,value
2 from v$statname n,
3 v$mystat s
4 where s.statistic# = n.statistic#
5 and name in ('physical read IO requests','physical read requests optimized')
6 order by name;
NAME VALUE
---------------------------------------------------------------- ----------
physical read IO requests 45,193
physical read requests optimized 23,140
前の例では、45188回の物理読取りリクエスト(45193 - 5)を実行したワークロードのうち、23129 (23140 - 11)が最適化されています。この場合、22059 (45188 - 23129)回の最適化されていない(ディスク)読取りが実行されています。
ワークロードを繰り返す場合、すべての読取りを最適化する必要があります(physical read IO requests
= physical read requests optimized
)。これは、必要なすべてのデータがExadataスマート・フラッシュ・キャッシュに移入されることを示します。
flashCacheMin
の使用
Exadataスマート・フラッシュ・キャッシュが統合環境で完全に移入されている場合は、I/Oリソース管理(IORM) flashCacheMin
設定を使用して領域を解放し、必要なデータをキャッシュに読み取ることができます。この場合、flashCacheMin
設定は、必要なデータを追加するための十分な領域を持つデータベースによって占有されている現在の領域よりも大きくする必要があります。
ノート:
コンテナ・データベース(CDB)を使用する場合、CDBにプラガブル・データベース(PDB)が1つのみ存在する場合でも、各PDBへのリソース割当てを管理するためにCDBリソース・プランが必要です。
各データベースの現在のExadataスマート・フラッシュ・キャッシュ領域割当てを確認するには、DB_FC_BY_ALLOCATED
メトリックを確認します。たとえば:
$ dcli -g cell_group cellcli -e list metriccurrent where name\=\"DB_FC_BY_ALLOCATED\"
db01celadm01: DB_FC_BY_ALLOCATED ASM 0.000 MB
db01celadm01: DB_FC_BY_ALLOCATED DBCDB1 1,694,241 MB
db01celadm01: DB_FC_BY_ALLOCATED DBCDB2 4,851,611 MB
db01celadm01: DB_FC_BY_ALLOCATED DBCDB3 4,638,129 MB
db01celadm01: DB_FC_BY_ALLOCATED DBCDB4 2,157,755 MB
db01celadm01: DB_FC_BY_ALLOCATED DBCDB5 9,509,356 MB
db01celadm01: DB_FC_BY_ALLOCATED _OTHER_DATABASE_ 365,790 MB
db01celadm02: DB_FC_BY_ALLOCATED ASM 0.000 MB
db01celadm02: DB_FC_BY_ALLOCATED DBCDB1 1,629,001 MB
db01celadm02: DB_FC_BY_ALLOCATED DBCDB2 4,761,316 MB
db01celadm02: DB_FC_BY_ALLOCATED DBCDB3 4,495,902 MB
db01celadm02: DB_FC_BY_ALLOCATED DBCDB4 2,106,805 MB
db01celadm02: DB_FC_BY_ALLOCATED DBCDB5 9,848,567 MB
db01celadm02: DB_FC_BY_ALLOCATED _OTHER_DATABASE_ 377,023 MB
db01celadm03: DB_FC_BY_ALLOCATED ASM 0.000 MB
db01celadm03: DB_FC_BY_ALLOCATED DBCDB1 1,664,919 MB
db01celadm03: DB_FC_BY_ALLOCATED DBCDB2 4,872,123 MB
db01celadm03: DB_FC_BY_ALLOCATED DBCDB3 4,459,631 MB
db01celadm03: DB_FC_BY_ALLOCATED DBCDB4 2,096,412 MB
db01celadm03: DB_FC_BY_ALLOCATED DBCDB5 9,750,586 MB
db01celadm03: DB_FC_BY_ALLOCATED _OTHER_DATABASE_ 315,181 MB
前の例では、DBCDB1
は各セルで約1.6 TBのキャッシュ領域を消費しています。各セルのDBCDB1
割当てを2 TBに増やす最小のIROMプランを作成するには、次のコマンドを使用します。
$ dcli -g cell_group cellcli -e alter iormplan dbplan=\(\(name=DBCDB1, flashCacheMin=2T\)\)
Exadataスマート・フラッシュ・キャッシュが統合環境に完全に移入されている場合は、IORM flashCacheMin
を使用して、1つのデータベースの割当てを増やすことで、他のすべてのデータベースの領域を効果的に奪います。このような場合、キャッシュ領域はすぐに転送されず、必要なデータをキャッシュに入れるためにスキャンが複数回実行される可能性があります。
CELL_FLASH_CACHE KEEP
の使用
他のアプローチに加えて、CELL_FLASH_CACHE
セグメント・ストレージ・オプションをKEEP
に設定して、セグメントの優先度を高め、セグメント・データをExadataスマート・フラッシュ・キャッシュに保持できます。
この設定のみを使用してもキャッシュは移入されません。このことは、セグメントが読み取られるときにも当てはまります。ただし、キャッシュ内にデータが残る可能性が高くなります。また、このアプローチでは、データが使用されていない場合でもキャッシュ領域を占有します。
手動で移入するオブジェクトの識別
AWRレポートの「Segments by UnOptimized Read」セクションを使用して、キャッシュされていないオブジェクトを識別できます。
この情報は、physical reads
をV$SEGMENT_STATISTICS
およびV$SEGSTAT
のoptimized physical reads
と比較することによっても使用可能です。
その他の考慮事項
-
手動移入が実行されると、小さいセグメントがダイレクト・パス読取りの対象ではなくなり、最終的にデータベース・バッファ・キャッシュに移入される可能性があります。これを回避するには、パラレル問合せを使用してスキャンを実行します。
-
表およびそれらに関連付けられた索引のデータをキャッシュに移入するには、スキャンを複数回実行する必要があります。キャッシュに索引ブロックを移入するには、
INDEX FAST FULL SCAN
を使用します。
親トピック: Exadataスマート・フラッシュ・キャッシュの管理
3.3 Exadataハイブリッド列圧縮の管理
次の手順を使用して、Exadataハイブリッド列圧縮を使用するOracle Databaseオブジェクトを管理します。
- 表が圧縮されているかどうかの確認
表またはパーティションが圧縮されているかどうかを確認するには、*_TABLES
または*_TAB_PARTITIONS
データ・ディクショナリ・ビューを問い合せます。 - 圧縮されている行の確認
Exadataハイブリッド列圧縮表が更新されると、行はより低いレベルの圧縮に変更されます。 - 圧縮レベルの変更
パーティション、表または表領域の圧縮レベルは変更できます。 - Exadataハイブリッド列圧縮表のインポートおよびエクスポート
impdp
およびexpdp
コマンドを使用して、Exadataハイブリッド列圧縮表をインポートおよびエクスポートできます。 - Exadataハイブリッド列圧縮表のリストア
圧縮表バックアップはExadataハイブリッド列圧縮をサポートしているシステム、またはExadataハイブリッド列圧縮をサポートしていないシステムにリストアできます。
親トピック: ExadataでのOracle Databaseの管理
3.3.1 表が圧縮されているかどうかの確認
表またはパーティションが圧縮されているかどうかを確認するには、*_TABLES
または*_TAB_PARTITIONS
データ・ディクショナリ・ビューを問い合せます。
親トピック: Exadataハイブリッド列圧縮の管理
3.3.2 圧縮されている行の確認
Exadataハイブリッド列圧縮表が更新されると、行は下位レベルの圧縮に変更されます。
たとえば、圧縮レベルがCOMP_FOR_QUERY_HIGH
からCOMP_FOR_OLTP
またはCOMP_NOCOMPRESS
に変更される場合があります。
表の行をサンプリングすることで、高レベルの圧縮ではなくなった行の割合を確認できます。
ALTER TABLE
またはMOVE PARTITION
を使用すると、行をより高い圧縮レベルに設定できます。たとえば、行の10%が最高の圧縮レベルでなくなった場合、それらの行をより高い圧縮レベルに変更または移行できます。
親トピック: Exadataハイブリッド列圧縮の管理
3.3.3 圧縮レベルの変更
パーティション、表または表領域の圧縮レベルは変更できます。
次の例では、圧縮レベルを変更する場合のシナリオについて説明します。
ある企業では、その売上データにウェアハウス圧縮を使用していますが、6か月より古い売上データにはめったにアクセスしません。売上データがその経過時間に基づいてパーティション化された表に格納されている場合、古いデータの圧縮レベルをアーカイブ圧縮に変更して、ディスク領域を解放できます。
-
パーティション表の圧縮レベルを変更するには、
DBMS_REDEFINITION
パッケージを使用します。このパッケージでは、表の再定義をオンラインで実行するために、再定義中に表のデータを保持する一時コピーを作成します。再定義される表は、再定義中でも引き続き問合せやDML文に対応できます。オンラインでの表の再定義に使用される空き領域の容量は、既存の表と新しい表の相対的な圧縮レベルに応じて変化します。
DBMS_REDEFINITION
パッケージを使用する前に、システム上に十分なハード・ディスク領域が存在することを確認してください。 -
パーティション表の単一パーティションの圧縮レベルを変更するには、
ALTER TABLE ... MODIFY PARTITION
コマンドを使用します。 -
非パーティション表の圧縮レベルを変更するには、
COMPRESS FOR
句を指定してALTER TABLE ... MOVE
コマンドを使用します。ALTER TABLE ... MOVE
コマンドの実行中に表に対してDML文を実行するには、ONLINE
句も追加する必要があります。 -
表領域の圧縮レベルを変更するには、
ALTER TABLESPACE
コマンドを使用します。これにより、表領域に作成される新規オブジェクトのデフォルトが定義されます。既存のオブジェクトは変更も移動も行われません。
-
自動データ最適化(ADO)を使用して、圧縮レベルを自動的に調整するポリシーを作成できます。
3.3.4 Exadataハイブリッド列圧縮表のインポートおよびエクスポート
impdp
およびexpdp
コマンドを使用して、Exadataハイブリッド列圧縮表をインポートおよびエクスポートできます。
Exadataハイブリッド列圧縮表は、データ・ポンプのインポート・ユーティリティのimpdp
コマンドを使用してインポートできます。デフォルトでは、impdp
コマンドは表プロパティを保存し、インポートされた表はExadataハイブリッド列圧縮表となります。表はexpdp
コマンドでエクスポートすることもできます。
Exadataハイブリッド列圧縮をサポートしていない表領域では、impdp
コマンドは失敗し、次のエラーが表示されます。
ORA-64307: Exadata Hybrid Columnar Compression is not supported for tablespaces on this storage type
Exadataハイブリッド列圧縮表は、impdp
コマンドのTRANSFORM:SEGMENT_ATTRIBUTES=n
オプション句を使用して、非圧縮表としてインポートできます。
非圧縮表またはOLTP圧縮表は、インポート中にExadataハイブリッド列圧縮形式に変換できます。Exadata以外のハイブリッド列圧縮表をExadataハイブリッド列圧縮表に変換するには、次のようにします。
ALTER TABLESPACE ... SET DEFAULT COMPRESS
コマンドを使用して、表領域のデフォルト圧縮を指定します。- インポート中にインポートされた表の
SEGMENT_ATTRIBUTES
オプションを上書きします。
親トピック: Exadataハイブリッド列圧縮の管理
3.3.5 Exadataハイブリッド列圧縮表のリストア
圧縮表バックアップはExadataハイブリッド列圧縮をサポートしているシステム、またはExadataハイブリッド列圧縮をサポートしていないシステムにリストアできます。
-
Exadataハイブリッド列圧縮が含まれる表をExadataハイブリッド列圧縮をサポートしているシステムにリストアする場合は、通常どおり、Oracle Recovery Manager (RMAN)を使用してファイルをリストアします。
-
Exadataハイブリッド列圧縮表がExadataハイブリッド列圧縮をサポートしていないシステムにリストアされる場合は、表をExadataハイブリッド列圧縮から非圧縮形式に変換する必要があります。
次のステップを使用して、Exadataハイブリッド列圧縮表を非圧縮形式に変換します。
表を非圧縮形式に変換した後、OLTP圧縮やOracle Database In-Memory圧縮などの別の形式の圧縮をオプションで使用できます。
3.4 ExadataでのOracle Database機能の管理
Oracle Exadataと組み合せて次のOracle Database機能を使用および管理するには、これらのガイドラインを使用します。
- Exadataでの索引の使用
以前は、適切なパフォーマンスを得るにはデータベースに索引が必要でした。しかし、Oracle Exadataでは、索引を使用せずに優れたスキャン率を実現できます。 - ExadataでのSQLチューニング・アドバイザの使用
SQLチューニング・アドバイザでは、1つ以上のSQL文を入力として使用し、自動チューニング・オプティマイザを使用してSQL文のチューニングを実行します。 - ExadataでのSQL計画管理の使用
SQL計画管理は、長期間にわたってSQL文の実行計画を記録し評価することで、SQL文の実行計画の突然の変更によってパフォーマンスが低下するのを防止します。 - Exadataシステム統計の使用
システム統計によってCPUとストレージのパフォーマンスが測定され、Oracle DatabaseオプティマイザでSQL実行プランを評価する際にこれらの入力を使用できます。 - 複数のデータベース・インスタンスでの同じDB_UNIQUE_NAMEの使用
データベースがそれぞれ別のOracle ASMクラスタに関連付けられている場合、同じDB_UNIQUE_NAME
値を使用するデータベース・インスタンスを複数作成できます。
親トピック: ExadataでのOracle Databaseの管理
3.4.1 Exadataでの索引の使用
以前は、適切なパフォーマンスを得るにはデータベースに索引が必要でした。しかし、Oracle Exadataでは、索引を使用せずに優れたスキャン率を実現できます。
Exadataスマート・スキャンのオフロードを使用して実行計画が高速になるかどうかを判断するには、索引を使用するアプリケーションの実行計画を確認します。索引がなくてもスキャンが高速になるかどうかを判断するには、オプティマイザで索引を認識できないようにします。認識されない索引はDML操作によって管理されますが、オプティマイザでは使用されません。
索引が認識されないようにするには、次のコマンドを使用し、index_nameのかわりに索引名を使用します。
SQL> ALTER INDEX index_name INVISIBLE;
3.4.2 ExadataでのSQLチューニング・アドバイザの使用
SQLチューニング・アドバイザでは、1つ以上のSQL文を入力として使用し、自動チューニング・オプティマイザを使用してSQL文のチューニングを実行します。
SQLチューニング・アドバイザの実行結果は、アドバイスまたは推奨事項の形式で出力され、推奨事項ごとに論理的根拠および予想される利点が示されます。SQLチューニング・アドバイザでは、次の情報が提供されます。
-
データ不足の統計や古い統計
-
最適な実行計画
-
最適なアクセス・パスおよびオブジェクト
-
最適なSQL文
3.4.3 ExadataでのSQL計画管理の使用
SQL計画管理は、長期間にわたってSQL文の実行計画を記録し評価することで、SQL文の実行計画の突然の変更によってパフォーマンスが低下するのを防止します。
SQL計画管理を使用して、効果的であることが判明している既存の計画セットで構成されるSQL計画ベースラインを作成します。次にSQL計画ベースラインを使用して、システムで発生する変更(ソフトウェアのアップグレードや新しいアプリケーション・モジュールのデプロイなど)とは無関係に、対応するSQL文のパフォーマンスを保持します。
SQL計画管理を使用して、新しいオプティマイザ統計や索引などの変更に適切に適応させることもできます。パフォーマンスを向上させる計画変更のみを検証して受け入れることができます。SQL計画の展開は、オプティマイザが新しい計画を検証して既存のSQL計画ベースラインに追加するためのプロセスです。
SQLプロファイルとSQL計画ベースラインのどちらも、オプティマイザで最適な計画のみが使用されるようにすることによりSQL文のパフォーマンスを向上させます。通常、SQL計画ベースラインは重大なパフォーマンスの問題が発生する前に作成します。SQL計画ベースラインは、オプティマイザが最適ではない計画を将来的に使用することを防ぎます。SQLプロファイルは、SQLチューニング・アドバイザを起動するとデータベースにより作成されます。通常、チューニング・アドバイザは、SQL文により高負荷の兆候が示された後にのみ起動します。SQLプロファイルは主に、最適ではない計画につながったオプティマイザのミスを継続的に解決するために使用できます。
DBMS_SPM
パッケージは、様々なSQL文に対して保持される、計画履歴およびSQL計画ベースラインに対する制御された操作を実行するためのインタフェースをユーザーに提供することによって、SQL計画管理機能をサポートします。DBMS_SPM
パッケージは、計画の展開で使用できるプロシージャとファンクションを提供します。
Oracle Exadata System Softwareリリース19.1以降では、DBMS_SPM.CONFIGURE
に新しいパラメータAUTO_SPM_EVOLVE_TASK
が用意されており、これはExadata Database MachineオンプレミスおよびOracle Cloudデプロイメントのみで使用できます。AUTO_SPM_EVOLVE_TASK
パラメータには、次の3つの値のいずれかを指定できます。
ON
: この機能が有効になります。SPM展開アドバイザにより、SQL計画履歴を定期的に管理するタスクが作成されます。このタスクでは、代替の有無を確認し、SQL実行計画を展開して受け入れる必要があるかどうかを判断します。このタスクは、高頻度統計収集と同様の方法で、通常のメンテナンス・ウィンドウの外部で実行されます。OFF
: この機能は無効になります。これはデフォルト値です。AUTO
: Oracle Databaseがこの機能を使用するタイミングを決定します。
関連項目
3.4.4 Exadataシステム統計の使用
システム統計によってCPUとストレージのパフォーマンスが測定され、Oracle DatabaseオプティマイザでSQL実行プランを評価する際にこれらの入力を使用できます。
最初のインスタンスの起動時に、Oracle Databaseはデフォルトのシステム統計を自動的に収集します。この統計は、noworkload統計とも呼ばれます。ただし、Exadata固有のシステム統計を収集することもできます。Exadataシステム統計により、Oracle Exadata Database Machineのパフォーマンス特性が考慮されることがSQLオプティマイザで保証されます。
Exadata固有の統計が使用されているかどうかを確認するには、次のSQLコマンドを使用します。
SQL> SELECT pname, PVAL1 FROM aux_stats$ WHERE pname='MBRC';
PVAL1
がNULLの場合、デフォルトのシステム統計が使用されます。
次のコマンドは、データベース・オプティマイザが使用するExadataシステム統計を収集します。
SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS('EXADATA');
必要に応じて、DBMS_STATS.DELETE_SYSTEM_STATS
プロシージャを使用してデータベースを再起動することで、デフォルトのシステム統計に戻すことができます。
新しいアプリケーションまたはデプロイメントの場合、本番前システム・テストを実行して、デフォルトのシステム・パフォーマンスをExadataシステム統計を使用したパフォーマンスと比較する必要があります。
既存のアプリケーションまたはデプロイメントの場合、Exadataシステム統計は、本番システムで初めて使用する前に、同等のテスト・システムで生成およびテストする必要があります。このアプローチにより、本番システムでの予期しないパフォーマンス低下のリスクが軽減されます。
同等のテスト・システムが使用できない場合、本番のExadataシステム統計をテスト・システムにコピーすることで、より現実的なテストを実行できます。手順は次のとおりです。
-
本番システムで統計表を作成します。
たとえば:
SQL> exec DBMS_STATS.CREATE_STAT_TABLE(stattab => 'exadata_stats');
-
本番システムで、新しく作成した表にExadataシステム統計を収集します。
たとえば:
SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS(gathering_mode => 'EXADATA', stattab => 'exadata_stats');
ユーザー定義統計表に格納されている統計は、システムでは使用されません。そのため、これらの統計を収集しても、本番システムのパフォーマンスには影響しません。
-
本番システムからテスト・システムに統計表をコピーします。
データ・ポンプのエクスポートやインポートなど、様々な方法で表をコピーできます。
-
テスト・システムで、統計表をOracleデータ・ディクショナリにインポートします。
たとえば:
SQL> exec DBMS_STATS.IMPORT_SYSTEM_STATS(stattab => 'exadata_stats');
関連項目
3.4.5 複数のデータベース・インスタンスでの同じDB_UNIQUE_NAMEの使用
データベースがそれぞれ別のOracle ASMクラスタに関連付けられている場合、同じDB_UNIQUE_NAME
値を使用するデータベース・インスタンスを複数作成できます。
Oracle Exadata System Softwareリリース19.1.0以降では、同じOracle ASMストレージを共有する複数のOracleデータベースで、同じDB_UNIQUE_NAME
を使用できます。
警告:
同じDB_UNIQUE_NAME
を使用するようデータベースを構成した場合、それらのデータベースはOracle Zero Data Loss Recovery Applianceにバックアップできません。
複数のOracleデータベースで同じDB_UNIQUE_NAME
を使用するには、次のようにする必要があります:
-
同じ
DB_UNIQUE_NAME
値を使用する複数のデータベース用に別個のOracle ASMクラスタを使用します。I/Oリソース管理(IORM)、Exadataスマート・フラッシュ・キャッシュおよびExadataスマート・スキャン・オフロードなどの操作では、Oracle ASMクラスタの名前がDB_UNIQUE_NAME
の修飾子として使用されます。 -
同じ
DB_UNIQUE_NAME
値を使用する複数のデータベースを含むOracle ASMクラスタごとに、ASMを有効範囲にしたセキュリティを実装します。