4 ExadataでのOracle Databaseの管理
4.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の管理
4.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は、サイズの大きい問合せを高速に処理できるように最適化されています。セル内にコントローラまたはその他のレベルのボトルネックが発生することはありません。Exadata Database Machineでは、最新のスケールアウト・アーキテクチャと、従来型のストレージ・ネットワークよりも非常に高いスループットを可能にする最先端のRDMAネットワーク・ファブリックを使用しています。Exadata Database MachineはOracle Databaseと密接に統合されており、設定、実行、監視、診断、リソース管理および破損防止のための独自の機能が用意されています。
親トピック: SQL処理のオフロードの管理
4.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処理のオフロードの管理
4.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処理のオフロードの管理
4.2 Exadataスマート・フラッシュ・キャッシュの管理
Exadataスマート・フラッシュ・キャッシュは、頻繁に使用されるデータを高パフォーマンスのフラッシュ・メモリーに自動的にキャッシュします。
親トピック: ExadataでのOracle Databaseの管理
4.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ソフトウェアが必要です。
例4-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));例4-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);
例4-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));
例4-4 ビューを使用したCELL_FLASH_CACHE STORAGE句の問合せ
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スマート・フラッシュ・キャッシュの管理
4.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 |
現時点では実装されていません。 |
例4-5 同じ表でのCELLMEMORYおよびINMEMORYオプションの使用
INMEMORYとCELLMEMORYの両方を同じ表で使用できます。たとえば:
CREATE TABLE t (c1 NUMBER) INMEMORY CELLMEMORY MEMCOMPRESS FOR QUERY;メモリーにロードされそうにない、優先順位の低い表がある場合に、これら2つのオプションを指定すると便利です。また、CELLMEMORYを指定することでも、列指向の性能を得られます。
親トピック: Exadataスマート・フラッシュ・キャッシュの管理
4.2.3 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スマート・フラッシュ・キャッシュの管理
4.3 Exadataハイブリッド列圧縮の管理
次の手順を使用して、Exadataハイブリッド列圧縮を使用するOracle Databaseオブジェクトを管理します。
- 表が圧縮されているかどうかの確認
表またはパーティションが圧縮されているかどうかを確認するには、*_TABLESまたは*_TAB_PARTITIONSデータ・ディクショナリ・ビューを問い合せます。 - 圧縮されている行の確認
Exadataハイブリッド列圧縮表が更新されると、行はより低いレベルの圧縮に変更されます。 - 圧縮レベルの変更
パーティション、表または表領域の圧縮レベルは変更できます。 - Exadataハイブリッド列圧縮表のインポートおよびエクスポート
impdpおよびexpdpコマンドを使用して、Exadataハイブリッド列圧縮表をインポートおよびエクスポートできます。 - Exadataハイブリッド列圧縮表のリストア
圧縮表バックアップはExadataハイブリッド列圧縮をサポートしているシステム、またはExadataハイブリッド列圧縮をサポートしていないシステムにリストアできます。
親トピック: ExadataでのOracle Databaseの管理
4.3.1 表が圧縮されているかどうかの確認
表またはパーティションが圧縮されているかどうかを確認するには、*_TABLESまたは*_TAB_PARTITIONSデータ・ディクショナリ・ビューを問い合せます。
親トピック: Exadataハイブリッド列圧縮の管理
4.3.2 圧縮されている行の確認
Exadataハイブリッド列圧縮表が更新されると、行は下位レベルの圧縮に変更されます。
たとえば、圧縮レベルがCOMP_FOR_QUERY_HIGHからCOMP_FOR_OLTPまたはCOMP_NOCOMPRESSに変更される場合があります。
表の行をサンプリングすることで、高レベルの圧縮ではなくなった行の割合を確認できます。
ALTER TABLEまたはMOVE PARTITIONを使用すると、行をより高い圧縮レベルに設定できます。たとえば、行の10%が最高の圧縮レベルでなくなった場合、それらの行をより高い圧縮レベルに変更または移行できます。
親トピック: Exadataハイブリッド列圧縮の管理
4.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)を使用して、圧縮レベルを自動的に調整するポリシーを作成できます。
4.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 typeExadataハイブリッド列圧縮表は、impdpコマンドのTRANSFORM:SEGMENT_ATTRIBUTES=nオプション句を使用して、非圧縮表としてインポートできます。
非圧縮表またはOLTP圧縮表は、インポート中にExadataハイブリッド列圧縮形式に変換できます。Exadata以外のハイブリッド列圧縮表をExadataハイブリッド列圧縮表に変換するには、次のようにします。
ALTER TABLESPACE ... SET DEFAULT COMPRESSコマンドを使用して、表領域のデフォルト圧縮を指定します。- インポート中にインポートされた表の
SEGMENT_ATTRIBUTESオプションを上書きします。
親トピック: Exadataハイブリッド列圧縮の管理
4.3.5 Exadataハイブリッド列圧縮表のリストア
圧縮表バックアップはExadataハイブリッド列圧縮をサポートしているシステム、またはExadataハイブリッド列圧縮をサポートしていないシステムにリストアできます。
-
Exadataハイブリッド列圧縮が含まれる表をExadataハイブリッド列圧縮をサポートしているシステムにリストアする場合は、通常どおり、Oracle Recovery Manager (RMAN)を使用してファイルをリストアします。
-
Exadataハイブリッド列圧縮表がExadataハイブリッド列圧縮をサポートしていないシステムにリストアされる場合は、表をExadataハイブリッド列圧縮から非圧縮形式に変換する必要があります。
次のステップを使用して、Exadataハイブリッド列圧縮表を非圧縮形式に変換します。
表を非圧縮形式に変換した後、OLTP圧縮やOracle Database In-Memory圧縮などの別の形式の圧縮をオプションで使用できます。
4.4 ExadataでのOracle Database機能の管理
Exadata Database Machineと組み合せて次のOracle Database機能を使用および管理するには、これらのガイドラインを使用します。
- Exadataでの索引の使用
以前は、適切なパフォーマンスを得るにはデータベースに索引が必要でした。しかし、Exadata Database Machineでは、索引を使用せずに優れたスキャン率を実現できます。 - ExadataでのSQLチューニング・アドバイザの使用
SQLチューニング・アドバイザでは、1つ以上のSQL文を入力として使用し、自動チューニング・オプティマイザを使用してSQL文のチューニングを実行します。 - ExadataでのSQL計画管理の使用
SQL計画管理は、長期間にわたってSQL文の実行計画を記録し評価することで、SQL文の実行計画の突然の変更によってパフォーマンスが低下するのを防止します。 - Exadataシステム統計の使用
システム統計によってCPUとストレージのパフォーマンスが測定され、Oracle DatabaseオプティマイザでSQL実行プランを評価する際にこれらの入力を使用できます。
親トピック: ExadataでのOracle Databaseの管理
4.4.1 Exadataでの索引の使用
以前は、適切なパフォーマンスを得るにはデータベースに索引が必要でした。しかし、Exadata Database Machineでは、索引を使用せずに優れたスキャン率を実現できます。
Exadataスマート・スキャンのオフロードを使用して実行計画が高速になるかどうかを判断するには、索引を使用するアプリケーションの実行計画を確認します。索引がなくてもスキャンが高速になるかどうかを判断するには、オプティマイザで索引を認識できないようにします。認識されない索引はDML操作によって管理されますが、オプティマイザでは使用されません。
索引が認識されないようにするには、次のコマンドを使用し、index_nameのかわりに索引名を使用します。
SQL> ALTER INDEX index_name INVISIBLE;4.4.2 ExadataでのSQLチューニング・アドバイザの使用
SQLチューニング・アドバイザでは、1つ以上のSQL文を入力として使用し、自動チューニング・オプティマイザを使用してSQL文のチューニングを実行します。
SQLチューニング・アドバイザの実行結果は、アドバイスまたは推奨事項の形式で出力され、推奨事項ごとに論理的根拠および予想される利点が示されます。SQLチューニング・アドバイザでは、次の情報が提供されます。
-
データ不足の統計や古い統計
-
最適な実行計画
-
最適なアクセス・パスおよびオブジェクト
-
最適なSQL文
4.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がこの機能を使用するタイミングを決定します。
関連項目
4.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');
関連項目