Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Exadata X11M 技術概要とアーキテクチャ 後編

Avatar for oracle4engineer oracle4engineer PRO
April 20, 2026
9

Exadata X11M 技術概要とアーキテクチャ 後編

Avatar for oracle4engineer

oracle4engineer PRO

April 20, 2026

More Decks by oracle4engineer

Transcript

  1. 概要 Oracle Exadata Database Machine のハードウェア・コンポーネントに搭載される、各種ファームウェア、仮想化、OS、 Exadata 固有のソフトウェア機能を可能にするソフトウェア・バンドル • Exadata

    18c (18.1.0) 以降、Exadata Storage Server Software という名称から変更 • Database Server および Storage Server から imageinfo や imagehistory コマンドにてソフト ウェアのリリースとステータスの概要や履歴を確認可能 Exadata System Software [root@geminidb01 ~]# imageinfo Kernel version: 5.4.17-2136.330.7.5.el8uek.x86_64 #3 SMP Mon May 27 12:51:19 PDT 2024 x86_64 Uptrack kernel version: 5.4.17-2136.335.4.el8uek.x86_64 #3 SMP Thu Aug 22 12:18:30 PDT 2024 x86_64 Image kernel version: 5.4.17-2136.330.7.5.el8uek Image version: 24.1.5.0.0.241016 Image activated: 2024-11-27 11:34:04 +0900 Image status: success Exadata software version: 24.1.5.0.0.241016 Node type: KVMHOST System partition on device: /dev/mapper/VGExaDb-LVDbSys1 [root@geminidb01 ~]# Copyright © 2026, Oracle and/or its affiliates 5
  2. バージョン・フォーマット (Exadata System Software 18c (18.1.0) 以降) • 年: ソフトウェアの年次リリース表示

    • サポートする Oracle Database 年次リリース番号にも対応 • アップデート: 新機能を含む最新のソフトウェア・アップデート • 年次リリースに新機能や新しいハードウェアをサポートする場合にリリース • リビジョン: セキュリティ及びソフトウェア修正を含む最新のソフトウェア・リビジョン • 原則毎月リリース Exadata System Software リリース番号 25 . 2 . 1 年 アップデート リビジョン Copyright © 2026, Oracle and/or its affiliates 6
  3. Smart Analytics • Smart Scan • クエリ処理の一部をStorage Server で実施し、I/O 量を削減、

    DB Server の CPU 負荷軽減 • Storage Index • クエリ対象外ブロックの読み飛ば し • 不要な物理 I/O の削減 • HCC (Hybrid Columnar Compression) • 高圧縮率を実現し、データスキャ ン時の論理帯域幅の向上 • Columnar Caching • Storage Server の Flash Cache の 領域に Columnar フォーマットで キャッシュし、高速化 Smart OLTP • Exadata RDMA Memory Cache (旧Persistent Memory Data Accelerator) および Exadata Smart Flash Cache • ランダムI/O 処理の高速化 • データ・スキャン帯域幅の向上 • Persistent Memory Commit Accelerator (X8M、X9M) および Exadata Smart Flash Log • Redo ログ書き込みの高速化 Smart Consolidation • Exadata I/O Resource Manager (IORM) • ワークロードごとのDB I/O 処理の 優先付け • MIX ワークロード時のOLTP 処理 の低レイテンシーを担保 • Exadata Network Resource Manager • 重要なデータベースのメッセージに ついて優先的に処理 Exadata System Software の代表的な機能 Copyright © 2026, Oracle and/or its affiliates 8
  4. Smart Scan を実現する Smart I/O • Block I/O • 一つまたは、複数のデータベース

    Block に対する I/O • Smart I/O • Filtering(行フィルタリング)や Predicate evaluation(列フィルタリング)が Storage Serverで実施される • Storage Server でのデータ処理結果が DB Server へ返され、残りの処理が実施される Exadata の I/O の種類 Copyright © 2026, Oracle and/or its affiliates 9
  5. Smart I/O の動作 RDBMS/ASM instance Data Data Data Database Server

    SGA IO Client IO Layer ASM Layer Exadata Storage Server libcell CELLSRV RoCE Fabric RDBMSとCELLSRVによってSmart I/Oを実行 1)データベースサーバ側で Smart Scan の I/O 命令を発 行。CELLSRV にコマンドを送 信 2)CELLSRVはそのコマンドに合ったデータ をディスクから特定し、必要な行と列だ けを含む仮想的なブロック(結果セッ ト)を作成する。 仮想的なブロック 3)DB Server に仮想的なブロックが返 され、結果を生成する。 Copyright © 2026, Oracle and/or its affiliates 10
  6. 【参考】 Exadata 固有のプロセス(全体像) RoCE Fabric Data Data Data Exadata Storage

    Server CELLSRV RS MS CellCLI CELLOFLSRV 12.1 CELLOFLSRV 11.2 Exadata Storage Server には、下記のような目的のプロセスが存在する • Database Server との通信を担うプロセス • H/W の監視を行うためのプロセス • Storage Server 側で SQL を処理するためのプロセス Database Server diskmon RDBMS/ASM instance IO Client IO Layer ASM Layer dskm Local IP /etc/oracle/cell/network-config Cells cellip.ora cellinit.ora SGA RS MS DBMCLI libcell CELLOFLSRV 19.1 Copyright © 2026, Oracle and/or its affiliates 11
  7. 【参考】プロセス、設定ファイル等一覧(Storage Server 側) 12 Copyright © 2026, Oracle and/or its

    affiliates • Cell Server (CELLSRV) • CELLSRVは、DB Server との通信を担う。1つのStorage Server に1プロセス(マルチスレッド)。 スレッドはディスクやネットワークに対して、非同期IOを発 行 • CELLOFLSRV • 複数のメジャーバージョン DB でのオフロードを実現 • Management Server (MS) • Grid ディスクの作成/削除、H/W 変更、SNMP トラップ、 アラート、メトリックなどを表示、管理 • Restart Server (RS) • CELLSRV と MS を監視。RS はプロセス生存や、 • メモリー使用率などを監視。 Backup RS はCore RS を監視 • CellCLI • ユーザ操作と構成を実施するコマンドラインツール Data Data Data Exadata Storage Server CELLSRV RS MS CellCLI ADR ADRCI CELLOFLSRV 11.2 CELLOFLSRV 12.1 CELLOFLSRV 24.1
  8. 【参考】Exadata での DB マルチバージョンサポート(Exadata 12.1~) • 各メジャーリリースごとに、データベースのライブラリに合う ように異なるオフロードサーバー(celloflsrv)を実装し、こ れにより各バージョンでのオフロード(Smart Scan等の

    機能の総称)を実現している。 • Database 11.2 から発行されたリクエストは 11.2用の celloflsrv によって処理され、Database 12.1 から発行 されたリクエストは12.1 用のcelloflsrv によって処理され る。 • オフロードサーバーは自動的に起動や停止 • オフロードサーバーは cellsrv のみと通信 Database Server Storage Server I/Os Smart Scans DB1 (11.2) DB2 (12.1) Database Server DB3 (19.x) CELLOFLSRV (11.2) CELLSRV CELLOFLSRV (12.1) CELLOFLSRV (24.1) Copyright © 2026, Oracle and/or its affiliates 13 Exadata 12.1.1.1.0 ~
  9. [root@geminicel01 ~]# cellcli -e list cell detail name: geminicel01 accessLevelPerm:

    remoteLoginEnabled bbuStatus: normal bootDeviceStatus: normal cellVersion: OSS_24.1.5.0.0_LINUX.X64_241016 cpuCount: 64/64 diagHistoryDays: 7 doNotServiceLEDStatus: off fanCount: 8/8 fanStatus: normal flashCacheMode: WriteBack httpsAccess: ALL id: 1940XLA045 ilomIpAddress: 10.122.5.100 interconnectCount: 2 interconnect1: re0 interconnect2: re1 iormBoost: 0.0 ipaddress1: 192.168.21.168/22 ipaddress2: 192.168.21.169/22 kernelVersion: 5.4.17-2136.330.7.5.el8uek.x86_64 listeningInterface: ALL locatorLEDStatus: off makeModel: Oracle Corporation ORACLE SERVER X8-2L High Capacity managementIpAddress: 10.122.5.90 memoryGB: 188 metricFGCollIntvlInSec: 0 続く list cell detail でプロセスを確認 Copyright © 2026, Oracle and/or its affiliates 14
  10. 続き metricHistoryDays: 7 metricStreamEndPoint: metricStreamIntvlInSec: 60 notificationMethod: snmp notificationPolicy: critical,warning,clear

    offloadGroupEvents: powerCount: 1/2 powerStatus: critical releaseImageStatus: success releaseVersion: 24.1.5.0.0.241016 rpmVersion: cell-24.1.5.0.0_LINUX.X64_241016-1.x86_64 releaseTrackingBug: 37148144 snmpSubscriber: host=exadbvm08.jp.osc.oracle.com,port=3872,snmpUser=cellsnmp,type=v3 host=exadbvm07.jp.osc.oracle.com,port=3872,snmpUser=cellsnmp,type=v3 host=asrmgr.jp.osc.oracle.com,port=162,community=public,type=ASR,asrmPort=16161 snmpUser: name=cellsnmp, authProtocol=SHA, privProtocol=AES status: online temperatureReading: 27.0 temperatureStatus: normal upTime: 28 days, 6:17 cellsrvStatus: running msStatus: running rsStatus: running egsStatus: running ersStatus: running sysEdsStatus: running usrEdsStatus: running bsmStatus: running bswStatus: running ifdStatus: running 【参考】 list cell detail でプロセスを確認 Copyright © 2026, Oracle and/or its affiliates 15
  11. ESS 22.1.x [root@jojocel01 ~]# ps -ef | grep cellsrv |

    grep -v grep | grep -v celloflsrv root 8087 1 0 Jun06 ? 00:24:56 /opt/oracle/cell/cellsrv/bin/cellrssrm root 8100 8087 0 Jun06 ? 00:05:57 /opt/oracle/cell/cellsrv/bin/cellrsbmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora - ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 root 8102 8100 0 Jun06 ? 00:00:59 /opt/oracle/cell/cellsrv/bin/cellrsbkm -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora - ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 root 8106 8102 0 Jun06 ? 00:06:04 /opt/oracle/cell/cellsrv/bin/cellrssmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora - ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 root 8202 8087 0 Jun06 ? 00:25:46 /opt/oracle/cell/cellsrv/bin/cellrsmmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora - ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 root 8210 8202 0 Jun06 ? 00:00:00 /bin/bash /opt/oracle/cell/cellsrv/deploy/scripts/ms_server.sh start root 8225 8210 2 Jun06 ? 2-13:15:31 /usr/java/default//bin/java -Xms512m -Xmx512m -XX:-UseLargePages -XX:ParallelGCThreads=8 -verbose:gc - Xloggc:/opt/oracle/cell22.1.0.0.0_LINUX.X64_220518/cellsrv/deploy/log/msserver_gc8225.trc -XX:NumberOfGCLogFiles=5 -XX:+UseGCLogFileRotation - XX:GCLogFileSize=100k -XX:+PrintGCDateStamps -Djava.security.egd=file:/dev/./urandom -DUseSunHttpHandler=true - Djava.library.path=/opt/oracle/cell22.1.0.0.0_LINUX.X64_220518/cellsrv/lib:/opt/oracle/cell22.1.0.0.0_LINUX.X64_220518/cellsrv/lib - Djetty.home=/opt/oracle/cell/cellsrv/deploy/jetty/jetty_home -Djetty.base=/opt/oracle/cell22.1.0.0.0_LINUX.X64_220518/cellsrv/deploy/jetty/ms_server - Djava.io.tmpdir=/tmp -jar /opt/oracle/cell/cellsrv/deploy/jetty/jetty_home/start.jar jetty.state=/opt/oracle/cell22.1.0.0.0_LINUX.X64_220518/cellsrv/deploy/jetty/ms_server/jetty.state jetty-started.xml root 18615 26118 0 12:11 ? 00:00:00 sh -c /opt/oracle/cell/cellsrv/bin/cellsrvstat -interval=5 -count=360 2>/dev/null >> /opt/oracle.ExaWatcher/archive/CellSrvStat.ExaWatcher/2022_10_07_12_11_54_CellSrvStatExaWatcher_jojocel01.jp.osc.oracle.com.dat root 18616 18615 0 12:11 ? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellsrvstat -interval=5 -count=360 root 18673 8087 0 Jun06 ? 00:36:48 /opt/oracle/cell/cellsrv/bin/cellrsomt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora - ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 - disallow_startup 0 root 19016 18673 99 Jun06 ? 270-11:23:32 /opt/oracle/cell/cellsrv/bin/cellsrv 100 5000 9 5042 root 22507 8225 0 12:31 ? 00:00:00 /bin/python /opt/oracle/cell/cellsrv/deploy/scripts/unix/exwmetrics/exwmetrics.py --exawtype rdsinfo -- collect --rds_type all [root@jojocel01 ~]# 【参考】 cellsrv プロセス Copyright © 2026, Oracle and/or its affiliates 16
  12. ESS 24.1.x [root@geminicel01 ~]# ps -ef | grep cellsrv |

    grep -v grep | grep -v celloflsrv root 331508 1 0 Nov27 ? 00:00:00 xargs /opt/oracle/cell/cellsrv/java/bin/java root 331512 331508 1 Nov27 ? 11:58:57 /opt/oracle/cell/cellsrv/java/bin/java -Djava.io.tmpdir=/tmp - Djetty.home=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home -Djetty.base=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server -Xms512m - Xmx512m -XX:-UseLargePages -XX:ParallelGCThreads=8 -verbose:gc -Xlog:gc:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/log/msserver_gc331127.trc - Djava.library.path=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/lib:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/lib -DUseSunHttpHandler=true - Djava.security.egd=file:/dev/./urandom --class-path /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/resources:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/logging/slf4j-api- 2.0.9.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/logging/jetty-slf4j-impl- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/angus-activation- 2.0.1.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/angus-mail- 2.0.2.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/atp.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/cr yptoj.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/images.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext /jakarta.activation-api-2.1.3.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/jakarta.mail-api- 2.1.3.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/javax.json- 1.0.4.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/jline- 3.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/msloginservice.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib /ext/ojdl.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/ojdl2.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ ext/oraclepki.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/lib/ext/snmp4j.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server /lib/ext/xmlparserv2.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-jakarta-servlet-api- 5.0.2.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-http- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-server- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-xml- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-util- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-io- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-security- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-servlet- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-webapp- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-deploy- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-jaas- 11.0.22.jar:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/jetty-rewrite-11.0.22.jar org.eclipse.jetty.xml.XmlConfiguration 続く 【参考】 cellsrv プロセス Copyright © 2026, Oracle and/or its affiliates 17
  13. ESS 24.1.x java.library.path=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/lib:/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/lib java.security.egd=file:/dev/./urandom java.version=11.0.25 jetty.base=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server jetty.base.uri=file:///opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server jetty.console-capture.append=true jetty.console- capture.dir=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/log

    jetty.console-capture.retainDays=30 jetty.deploy.scanInterval=0 jetty.home=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home jetty.home.uri=file:///opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home jetty.httpConfig.sendServerVersion=false jetty.jaas.login.conf=etc/login.conf jetty.pid=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/jetty.pid jetty.session.file.storeDir=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/config/security/sessions jetty.ssl.port=443 jetty.ssl.sniHostCheck=false jetty.sslContext.keyManagerPassword=OBF:1lte1e291mt31jzd1l8r1njd1qa71i271nqy1cw71cvr1nr81hzj1qcv1nkl1l4j1k0l1mpz1e311lqk jetty.sslContext.keyStorePassword=OBF:1lte1e291mt31jzd1l8r1njd1qa71i271nqy1cw71cvr1nr81hzj1qcv1nkl1l4j1k0l1mpz1e311lqk jetty.sslContext.keyStorePath=etc/keystore jetty.sslContext.reload.scanInterval=60 jetty.sslContext.trustStorePassword=OBF:1lte1e291mt31jzd1l8r1njd1qa71i271nqy1cw71cvr1nr81hzj1qcv1nkl1l4j1k0l1mpz1e311lqk jetty.sslContext.trustStorePath=etc/keystore jetty.sslContext.wantClientAuth=true jetty.state=/opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/jetty.state jetty.webapp.addServerClasses=-org.eclipse.jetty.util.,- org.eclipse.jetty.security.,org.eclipse.jetty.logging.,file:///opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/lib/logging/,org.slf4j. runtime.feature.alpn=true slf4j.version=2.0.9 UseSunHttpHandler=true /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-bytebufferpool.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/console-capture.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty- pid.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-threadpool.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-state.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-webapp.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty- deploy.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-ssl.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-ssl-context.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-https.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/etc/jetty- inetaccess.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-jaas.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-rewrite.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/etc/rewrite- rules.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/sessions/id-manager.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/sessions/session-cache-hash.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/sessions/file/session-store.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/jetty_home/etc/jetty-ssl-context-reload.xml /opt/oracle/cell24.1.5.0.0_LINUX.X64_241016/cellsrv/deploy/jetty/ms_server/etc/tweak-ssl.xml root 425755 1 10 Nov27 ? 3-02:10:16 /opt/oracle/cell/cellsrv/bin/egssrv 5045 root 433060 1 0 Nov27 ? 00:07:41 /opt/oracle/cell/cellsrv/bin/cellrssrm root 433131 433060 0 Nov27 ? 00:04:21 /opt/oracle/cell/cellsrv/bin/cellrsmmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 続く 【参考】 cellsrv プロセス Copyright © 2026, Oracle and/or its affiliates 18
  14. ESS 24.1.x root 433132 433060 1 Nov27 ? 11:30:38 /opt/oracle/cell/cellsrv/bin/cellegsrsmt

    -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 433133 433060 0 Nov27 ? 00:01:16 /opt/oracle/cell/cellsrv/bin/cellrsbmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 433140 433133 0 Nov27 ? 00:00:36 /opt/oracle/cell/cellsrv/bin/cellrsbkm -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 433145 433140 0 Nov27 ? 00:01:11 /opt/oracle/cell/cellsrv/bin/cellrssmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 434482 433060 0 Nov27 ? 00:08:35 /opt/oracle/cell/cellsrv/bin/cellrsomt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 -disallow_startup 0 root 434534 434482 99 Nov27 ? 77-15:46:34 /opt/oracle/cell/cellsrv/bin/cellsrv 100 5000 9 5042 root 448788 433060 0 Nov27 ? 01:42:11 /opt/oracle/cell/cellsrv/bin/cellifdrsmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 448792 448788 2 Nov27 ? 19:20:54 /opt/oracle/cell/cellsrv/bin/ifdsrv 5056 root 476369 433060 0 Nov27 ? 03:27:39 /opt/oracle/cell/cellsrv/bin/cellsysedsrsmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 476374 476369 4 Nov27 ? 1-08:36:39 /opt/oracle/cell/cellsrv/bin/syseds 5046 root 476720 433060 0 Nov27 ? 03:03:34 /opt/oracle/cell/cellsrv/bin/cellusredsrsmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 476723 476720 4 Nov27 ? 1-08:40:08 /opt/oracle/cell/cellsrv/bin/usreds 5050 root 477301 433060 0 Nov27 ? 03:32:51 /opt/oracle/cell/cellsrv/bin/cellbsmrsmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 477303 477301 4 Nov27 ? 1-06:25:24 /opt/oracle/cell/cellsrv/bin/bsmsrv 5047 root 477675 433060 0 Nov27 ? 03:48:38 /opt/oracle/cell/cellsrv/bin/cellbswrsmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 477711 477675 3 Nov27 ? 21:11:37 /opt/oracle/cell/cellsrv/bin/bswsrv 5048 root 532463 736233 0 17:41 ? 00:00:00 sh -c /opt/oracle/cell/cellsrv/bin/cellsrvstat -skip_zero_delta -interval=5 -count=360 2>/dev/null >> /opt/oracle.ExaWatcher/archive/CellSrvStat.ExaWatcher/2024_12_25_17_41_27_CellSrvStatExaWatcher_geminicel01.jp.osc.oracle.com.dat root 532466 532463 0 17:41 ? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellsrvstat -skip_zero_delta -interval=5 -count=360 root 538474 736233 0 17:43 ? 00:00:00 sh -c /opt/oracle/cell/cellsrv/bin/ecstat -s --interval=5 --count=360 2>/dev/null >> /opt/oracle.ExaWatcher/archive/ECStat.ExaWatcher/2024_12_25_17_43_05_ECStatExaWatcher_geminicel01.jp.osc.oracle.com.dat root 538475 538474 0 17:43 ? 00:00:01 /bin/python3 /opt/oracle/cell/cellsrv/bin/ecstat -s --interval=5 --count=360 root 563004 563000 99 17:48 ? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellsrvstat -usreds root 2744963 433060 1 Dec06 ? 05:28:45 /opt/oracle/cell/cellsrv/bin/cellersrsmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsms.state -cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/rs/cellrsos.state -debug 0 root 2744965 2744963 3 Dec06 ? 14:13:45 /opt/oracle/cell/cellsrv/bin/erssrv 5049 [root@geminicel01 ~]# 【参考】 cellsrv プロセス Copyright © 2026, Oracle and/or its affiliates 19
  15. [root@geminicel01 ~]# ps -ef | grep celloflsrv | grep -v

    grep cellofl 436785 433060 0 Nov27 ? 06:13:21 /opt/oracle/cell/cellofl-11.2.3.3.1_LINUX.X64_240415/cellsrv/bin/celloflsrv -startup 1 0 1 5042 0 SYS_112331_240415 cell cellofl 436790 433060 0 Nov27 ? 00:00:00 /bin/sh /opt/oracle/cell/cellofl-12.1.2.4.0_LINUX.X64_240125/cellsrv/bin/celloflsrv_start.sh -startup /opt/oracle/cell/cellofl- 12.1.2.4.0_LINUX.X64_240125 2 0 1 5042 0 /opt/oracle/cell/cellsrv/deploy/config/SYS_121240_240125 SYS_121240_240125 cell cellofl 436791 436790 0 Nov27 ? 06:20:03 /opt/oracle/cell/cellofl-12.1.2.4.0_LINUX.X64_240125/cellsrv/bin/celloflsrv -startup 2 0 1 5042 0 SYS_121240_240125 cell cellofl 436796 433060 0 Nov27 ? 00:00:00 /bin/sh /opt/oracle/cell/cellofl-24.1.5.0.0_LINUX.X64_241016/cellsrv/bin/celloflsrv_start.sh -startup /opt/oracle/cell/cellofl- 24.1.5.0.0_LINUX.X64_241016 3 0 1 5042 0 /opt/oracle/cell/cellsrv/deploy/config/SYS_241500_241016 SYS_241500_241016 cell cellofl 436797 436796 5 Nov27 ? 1-13:38:15 /opt/oracle/cell/cellofl-24.1.5.0.0_LINUX.X64_241016/cellsrv/bin/celloflsrv -startup 3 0 1 5042 0 SYS_241500_241016 cell [root@geminicel01 ~]# 【参考】 celloflsrv プロセス Copyright © 2026, Oracle and/or its affiliates 20
  16. 【参考】プロセス、設定ファイル等一覧(Database Server 側) • diskmon、dskm • マスターdiskmon (diskmon) は CSS

    とともに起動し、CELLSRV と通信。 • スレーブdiskmon (dskm) は各インスタンスの一部で、マスター diskmon と通信。 • Storage Server 障害や I/O フェンシング、I/O リソースマネージメントプランの伝播、などを実施 • cellip.ora :DB Server が利用する Storage Server の IP リスト • cellinit.ora :DB Server が Storage Server との通信に利用するローカル IP Exadata 12.1.2.1.0 ~ • Storage Server に実装されていた MS、RS プロセスが Database Server 側にも実装された。 • MS: H/W の監視 • RS: MS を監視。RS はプロセス生存や、メモリー使用率な どを監視。 Backup RS はCore RS を監視 • DBMCLI • ユーザ操作と構成を実施するコマンドラインツール Database Server diskmon RDBMS/ASM instance IO Client IO Layer ASM Layer dskm Local IP /etc/oracle/cell/network-config Cells cellip.ora cellinit.ora SGA RS MS DBMCLI libcell Copyright © 2026, Oracle and/or its affiliates 21 Exadata 12.1.2.1.0 ~
  17. crsctl stat res -t に -init オプションでデーモンリソースを確認 [root@jojodb01 ~]# /u01/app/21.0.0.0/grid/bin/crsctl

    stat res -t -init -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.asm 1 ONLINE ONLINE jojodb01 STABLE ora.crf 1 ONLINE ONLINE jojodb01 STABLE ora.crsd 1 ONLINE ONLINE jojodb01 STABLE ora.cssd 1 ONLINE ONLINE jojodb01 STABLE ora.cssdmonitor 1 ONLINE ONLINE jojodb01 STABLE ora.ctssd 1 ONLINE ONLINE jojodb01 OBSERVER,STABLE ora.diskmon 1 ONLINE ONLINE jojodb01 STABLE ora.drivers.acfs 1 ONLINE ONLINE jojodb01 STABLE ora.drivers.oka 1 OFFLINE OFFLINE STABLE ora.evmd 1 ONLINE ONLINE jojodb01 STABLE ora.gipcd 1 ONLINE ONLINE jojodb01 STABLE ora.gpnpd 1 ONLINE ONLINE jojodb01 STABLE ora.mdnsd 1 ONLINE ONLINE jojodb01 STABLE 【参考】 DB server の diskmon プロセス Copyright © 2026, Oracle and/or its affiliates 22
  18. dskmはインスタンス毎に起動 DB サーバーの diskmon プロセス [root@wasabi-isfff1 ~]# ps -ef |

    grep diskmon | grep -v grep grid 40571 1 0 10:08 ? 00:00:34 /u01/app/19.0.0.0/grid/bin/diskmon -d -f DB サーバーの dskm プロセスはインスタンス毎に起動 [root@wasabi-isfff1 ~]# ps -ef | grep dskm | grep -v grep grid 49024 1 0 10:08 ? 00:00:00 asm_dskm_+ASM1 grid 55463 1 0 10:09 ? 00:00:00 apx_dskm_+APX1 oracle 60942 1 0 10:09 ? 00:00:00 ora_dskm_DB09301 oracle 61098 1 0 10:09 ? 00:00:00 ora_dskm_DB11 oracle 61256 1 0 10:09 ? 00:00:00 ora_dskm_DB09281 [root@wasabi-isfff1 ~]# 【参考】 DB server の diskmon, dskm プロセス Copyright © 2026, Oracle and/or its affiliates 23
  19. [root@jojodb01 network-config]# pwd /etc/oracle/cell/network-config [root@jojodb01 network-config]# ls -la total 20

    drwxrwxr-x 2 grid dbmusers 4096 Oct 7 03:06 . drwxr-xr-x 3 root root 4096 Feb 28 2022 .. -rw-rw-r-x 1 grid dbmusers 56 Jun 6 11:41 cellinit.ora -rw-r--r-- 1 grid oinstall 105 Mar 1 2022 cellip.ora -rw-r--r-- 1 root root 345 Oct 7 03:06 cellroute.ora [root@jojodb01 network-config]# cat cellip.ora >> 通信対象のStorage Server のプライベートネットワークの IP アドレス cell="192.168.20.37;192.168.20.38" cell="192.168.20.39;192.168.20.40" cell="192.168.20.41;192.168.20.42" [root@jojodb01 network-config]# cat cellinit.ora >> 自ノードのプライベートネットワークのIP アドレス ipaddress2=192.168.20.22/22 ipaddress1=192.168.20.21/22 [root@jojodb01 network-config]# [root@jojodb01 network-config]# ip addr show dev ib0 >> 自ノードのプライベートネットワークのIP アドレス 8: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UP group default qlen 256 link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:10:e0:00:01:33:f2:59 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff inet 192.168.20.21/22 brd 192.168.23.255 scope global ib0 valid_lft forever preferred_lft forever inet6 fe80::210:e000:133:f259/64 scope link valid_lft forever preferred_lft forever [root@jojodb01 network-config]# ip addr show dev ib1 >> 自ノードのプライベートネットワークのIP アドレス 9: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast state UP group default qlen 256 link/infiniband 80:00:02:09:fe:80:00:00:00:00:00:00:00:10:e0:00:01:33:f2:5a brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff inet 192.168.20.22/22 brd 192.168.23.255 scope global ib1 valid_lft forever preferred_lft forever inet6 fe80::210:e000:133:f25a/64 scope link valid_lft forever preferred_lft forever [root@jojodb01 network-config]# 【参考】 DB server の cellip.ora, cellinit.ora Copyright © 2026, Oracle and/or its affiliates 24
  20. KVM Guest [root@exadbvm07 ~]# dbmcli -e list dbserver detail name:

    exadbvm07 cpuCount: 4 diagHistoryDays: 7 httpsAccess: ALL id: 6f367e9f-ddf8-4b76-824a-3f4abf350aa3 interconnect1: re0 interconnect2: re1 ipaddress1: 192.168.21.76/22 ipaddress2: 192.168.21.77/22 kernelVersion: 5.4.17-2136.330.7.5.el8uek.x86_64 listeningInterface: ALL makeModel: KVM managementIpAddress: 10.122.6.7 metricFGCollIntvlInSec: 0 metricHistoryDays: 7 metricStreamEndPoint: metricStreamIntvlInSec: 60 msVersion: OSS_24.1.5.0.0_LINUX.X64_241016 releaseImageStatus: success releaseTrackingBug: 37148144 releaseVersion: 24.1.5.0.0.241016 rpmVersion: 24.1.5.0.0.241016 status: online upTime: 28 days, 4:04 msStatus: running rsStatus: running edvStatus: running esnpStatus: running [root@exadbvm07 ~]# DB server の ms, rs Copyright © 2026, Oracle and/or its affiliates 25
  21. KVM Host [root@geminidb01 ~]# dbmcli -e list dbserver detail name:

    geminidb01 bbuStatus: normal coreCount: 48/48 cpuCount: 96/96 diagHistoryDays: 7 fanCount: 16/16 fanStatus: normal httpsAccess: ALL id: 1939XLB022 ilomIpAddress: 10.122.5.96 interconnectCount: 2 interconnect1: re0 interconnect2: re1 ipaddress1: 192.168.21.160/22 ipaddress2: 192.168.21.161/22 kernelVersion: 5.4.17-2136.330.7.5.el8uek.x86_64 listeningInterface: ALL locatorLEDStatus: off makeModel: Oracle Corporation ORACLE SERVER X8-2 managementIpAddress: 10.122.5.86 metricFGCollIntvlInSec: 0 metricHistoryDays: 7 metricStreamEndPoint: metricStreamIntvlInSec: 60 msVersion: OSS_24.1.5.0.0_LINUX.X64_241016 notificationMethod: snmp notificationPolicy: critical,warning,clear powerCount: 1/2 powerStatus: critical releaseImageStatus: success DB server の ms, rs Copyright © 2026, Oracle and/or its affiliates 26
  22. ソフトウェア機能 • Smart Analytics: Smart Scan • Smart Analytics: AI

    Smart Scan • Smart Analytics: Storage Index • Smart Analytics: Hybrid Columnar Compression (HCC) • Smart OLTP: Exadata RDMA Memoryおよび Smart Flash テクノロジー概要 • Smart OLTP : Exadata Smart Flash Log XRMEMLOG(旧Persistent Memory Commit Accelerator (PMEM Log)) • Smart OLTP: Smart Flash Cache – Block Cache • XRMEM Cache(旧Persistent Memory Data Accelerator (PMEM Cache)) • Smart Analytics: Smart Flash Cache – Columnar Cache • Smart Consolidation: Exadata I/O Resource Manager • Smart Consolidation: Exadata Network Resource Manager • その他の機能
  23. • Exadata Smart Scan とは • Smart Scan の動作例 •

    Smart Scan の種類 • Smart Scan が選択される条件 • Smart Scan が適用されないケース • Smart Scanの機能拡張 • 暗号化データに対する Smart Scan復号のオフロー ド • TDE表領域暗号化時の AES-XTS暗号化への対 応 • Reverse Offload (Optimized Smart Scan) • LOB, JSON, XML の Smart Scan 対応 • LOB、XML の Smart Scan 対応のさらなる拡張 圧縮されたインデックスへのSmart Scan対応 • インメモリー集計(IMA)のためのSmart Scanオフロー ド機能拡張 • 高速暗号化表スマート・スキャン • Smart Scan におけるメタデータの共有 • スマート・スキャンの高速復号化 • オンライン暗号化時のスマート・スキャン • Smart Scan – さらなる機能追加 - Wide Tables - Time Zone Upgrade - Smart Scan オフロード対象になった関数、演算子 • 索引構成表でのスマート・スキャン • TDE表領域暗号化時の AES-XTS暗号化への対 応 Smart Analytics: Smart Scan Copyright © 2026, Oracle and/or its affiliates 30
  24. データベース処理の一部を Storage Server にオフロード • Exadata Storage Server では、データベース処理の一 部を

    Smart Scan として実行することが可能 • SQL 処理の一部を Storage Server で実施し、結 果と関連する行や列のみを Database Server に 送る • 完全に透過的 • 既存アプリの修正は不要 • クエリ実施中にストレージ障害が発生しても継続 可能 Exadata Smart Scan とは Database Server Storage Server S Q L Smart Scan ストレージ側で、実際に必要な データのみを抽出 DB Sever のCPU 負荷をストレージに分散 DB Server への転 送量を大幅に削 減 Copyright © 2026, Oracle and/or its affiliates 31
  25. Smart Scan の動作例 ボトルネック ④I/O実行 1 TB のデータがスキャンさ れ、データベース・サーバ ーに返答

    ⑤集計・フィルタ処理 1 TB のデータから1000件の 顧客名を取得。 アプリケーションに返す ⑥結果取得 対象の行を取得 ①問い合わせ発生 SELECT customer_name FROM calls WHERE amount > 200; ②検索処理 表データの格納場所 (エクステント)を認識 ③ ストレージ処理 ディスク I/O 発生 データベース・サーバー アプリケーション 従来のデータベース処理 Smart Scan ④データ処理 2 MB のデータを DB Server に返答 ⑥結果取得 対象の行を取得 ②検索処理 Exadata Storage Server に Smart Scan による検 索を指示 ③Smart Scan 1 TB ある表データの中か ら、検索対象の行と列を 特定 ⑤集計処理 各 Storage Server からの 結果を集計 ①問い合わせ発生 SELECT customer_name FROM calls WHERE amount > 200; アプリケーション Exadata Database Server Oracle Exadata ボトルネック Exadata Storage Server ストレージ Copyright © 2026, Oracle and/or its affiliates 32
  26. • 行のフィルタリング • 必要な行だけが DB サーバに返される - SELECT * FROM

    employee_table WHERE hire_date > ‘1-Jan-2003’; • 列のフィルタリング • 必要な列だけが DB サーバに返される - SELECT employee_name, employee_number FROM employee_table; • ジョイン・フィルタリング • 結合をHash join で実行する際に、ブルームフィルターを使用して、結合前にセル側でフィルタリングが実行 • 暗号化された表領域 • HCC圧縮 • その他のSmart Scan対象処理 • Smart Incremental Backup (増分バックアップ) - Exadataでは、複数のブロックから成る大規模グループ単位ではなく、個々のOracleブロック単位で変更が追跡され、バックアップで消費されるI/O 帯域幅が減少 • RMANリストア、表領域、データファイルの作成 - 表領域ブロッ クの作成とフォーマットに関連づけられているI/OがStorage Server へオフロード Smart Scan の種類 Copyright © 2026, Oracle and/or its affiliates 33
  27. • 1. オブジェクトへのフルスキャン • FULL TABLE SCAN, INDEX FAST FULL

    SCAN, BITMAP INDEX FAST FULL SCAN • 2. ダイレクト・パス・リード • ダイレクト・パス・リードでは SGA (バッファ・キャッシュ) を経由せずに、PGA に直接読み込まれる • ダイレクト・パス・リードが採用されるケース(11g) - パラレル実行の場合 - シリアル実行のフル・テーブル・スキャンで表のサイズが大きい場合 • 3. Exadata Storage Server 上の diskgroup にセグメントが存在していること。下記のパラメーターがDisk Group に設定 されていること • 'compatible.rdbms' = 11.2.0.0.0' (これ以降) • 'compatible.asm' = 11.2.0.0.0' (これ以降) • 'cell.smart_scan_capable' = TRUE • 4. CELL_OFFLOAD_PROCESSING パラメーターが TRUE Smart Scan が選択される条件 Copyright © 2026, Oracle and/or its affiliates 34
  28. スマートI/Oが期待どおりに実行されない • セグメントのサイズが小さく、オプティマイザーがdirect read を選択せずに、バッファ・キャッシュに読み込む場合 • cell multiblock physical read待機イベントが発生

    • 共有サーバー接続の場合 • 仕様としてSmart Scan は実行されない • direct read は実行されているがdirect path read の待機イベントが発生して、Storage Server へオフロードされない場合 • Storage Server 側のリソースが不足している場合など - ExaWatcherから確認 - cellsrvstat の統計 • Number of low memory threshold failures • Number of no memory threhsold failures • commitされていないデータがある場合 • 長時間のバッチ処理など • Storage Server の CPU利用率が高い場合(リバース・オフロード) • AWR の Reverse Offload列 • cell physical IO bytes sent directly to DB node to balance CPU usage • ストレージ・サーバーのCPU使用率が高いのは、オフロードされる条件のタイプが原因である可能性 - 大/小文字を区別しない検索やREGEXP_LIKEの使用では、単純な条件よりも多くのCPUが使用される 【参考】Smart Scan が適用されないケース (1/4) Copyright © 2026, Oracle and/or its affiliates 35
  29. スマートI/Oが期待どおりに実行されない • Storage Server が Predicate evaluation(条件評価)が出来ない場合(Passthruが発生) • 事象 -

    対象となるバイトと比較して、AWRレポートのSmart IOセクションのPassthru列の値が大きい - cell physical IO bytes eligible for smart IOと比較して、データベース統計cell num bytes in passthru during predicate offloadの値が大きい - Eligible bytes for Smart IO値と比較して、SQLモニターの行ソース統計Cell passthru IO bytesの値が大きい • 理由 - sql quarantine が実行される場合 • cell num bytes in passthru due to quarantine • cell passthru IO bytes due to quarantine - データベースのタイムゾーンのアップグレードが実行中の場合(「impdp実行時にDST Upgradeが実行される場合」)(ESS 24&DB23aiで対応) • cell num smart IO sessions using passthru mode due to timezone • cell smart table scan: db timezone upgrade • cell smart index scan: db timezone upgrade - ユーザー設定:CELL_OFFLOAD_PROCESSING = FALSE に設定されている場合 • cell num smart IO sessions using passthru mode due to user • cell smart table scan: disabled by user • cell smart index scan: disabled user - ストレージサーバーが操作をオフロード出来ない • cell num smart IO sessions using passthru mode due to cellsrv • cell smart table scan: passthrough • cell smart index scan: passthrough 【参考】Smart Scan が適用されないケース (2/4) Copyright © 2026, Oracle and/or its affiliates 36
  30. スマートI/Oが期待どおりに実行されない • スマートI/Oを使用して通常実行される操作のOracle DatabaseがブロックI/Oモードに戻る場合 • cell num smart IO sessions

    in rdbms block IO due to • cell num smart IO sessions in rdbms block IO due to online encr - オンラインの暗号化操作(ESS 24 & DB23ai から対応) 【参考】Smart Scan が適用されないケース (2/4) Copyright © 2026, Oracle and/or its affiliates 37
  31. 操作がオフロードされない理由 • クラスタ表でスキャンが実行される場合 • 索引構成表でスキャンが実行される場合(ESS24&DB23ai で対応) • 圧縮型索引で高速全スキャンが実行される場合 • 逆キー索引で高速全スキャンが実行される場合

    • 表で行の依存性が有効になっている場合や、rowscn がフェッチされている場合. • オプティマイザでスキャンを実行してROWID の順で行を返す場合 • CREATE INDEXコマンドが nosort を使用するである場合 • LONG 列をselectまたは問合せ中の場合 • クエリに、圧縮された LOB またはアウトライン LOB が含まれている場合。 アウトライン LOB は、他の行データとは別に LOB データを格納 し、通常はサイズが 4 KB を超えています。 (インラインLOBはExadata Storage 12.1.1.1.1 / Database 12.1.0.2から可能) • 表で SELECT ... VERSIONS 問合せを実行する場合 • 255 を超える列が参照される問合せで、ヒープ表が圧縮されていないか、基本圧縮または OLTP圧縮である場合。ただし、Exadata ハ イブリッド列圧縮で圧縮された表に対するこのような問合せは、オフロードされる。 (ESS24&DB23ai で対応) 【参考】Smart Scan が適用されないケース (3/4) Copyright © 2026, Oracle and/or its affiliates 38
  32. 操作がオフロードされない理由 (続き) • 表領域が暗号化されており、CELL_OFFLOAD_DECRYPTION パラメータが FALSE に設定されている場合 • Oracle Exadata

    System Softwareで復号化を実行するには、Oracle Database からOracle Exadata Storage Server に復号化 キーを送信する必要がある • ネットワークを介してOracle Exadata Storage Server にキーを送信することに関してセキュリティ上の懸念がある場合は、復号化 機能を無効にしてください。 • 表領域がOracle Exadata Storage Server に完全に格納されなてい場合 • 条件評価が仮想列にある場合 • ほとんどのSQL演算子および関数でオフロードはサポートされているが、 Oracle Exadata System Softwareでは一部のSQL演算子および関数のオフロードがサポートされない • 動的パフォーマンス・ビューV$SQLFN_METADATAには、オフロードがSQL演算子または関数でサポートされているかどうかに関する 情報が含まれる • OFFLOADABLE列にYESが含まれる場合、対応する演算子または関数でオフロードがサポートされている • OFFLOADABLE列がNOは、対応する演算子または関数でオフロードがサポートされていない 【参考】Smart Scan が適用されないケース (4/4) Copyright © 2026, Oracle and/or its affiliates 39
  33. • 機能 • TDE 表領域暗号化、TDE 列暗号化に対しても Smart Scan が可能 •

    Intel Xeon の AES-NI 機能も活用可能 • AES-NI(Advanced Encryption Standard New Instructions) - Xeon プロセッサーに搭載された命令セット - X2-2 以降の Database および Storage Server が対象 • メリット • 復号処理のオーバーヘッドをストレージ側にオフロードすること により、DB Server の CPU 効率を劇的に向上させる • 暗号化データもフィルタリングすることで、DB Server に送られるデータ量を削減 • AES-NI 機能を用いることで、暗号化/復号処理が高速化 暗号化データに対する Smart Scan復号のオフロード Database Server Storage Server 暗号化 復号 WRITE READ AES-NI AES-NI Exadata 11.2.1.2.0 ~ Copyright © 2026, Oracle and/or its affiliates 40
  34. AES-XTS Encryption mode for TDE Tablespace Encryption Database 23ai の

    TDE暗号化でサポートされた AES-XTSで暗号化された表領域で Smart Scan がサポート 新しいAES-XTSモードは、既存のAES-CFBを補完し、格納データのより強力な暗号化を提供 • Database 23aiでは、デフォルトで新しいデータベースにはAES-XTSモード暗号化を使用 TDE表領域暗号化時の AES-XTS暗号化への対応 Copyright © 2026, Oracle and/or its affiliates 41 --デフォルトのAES256アルゴリズムおよびXTSモードで暗号化された表領域を作成 CREATE TABLESPACE encts1 DATAFILE ‘encts1.f’ SIZE 1G ENCRYPTION MODE ‘XTS’ ENCRYPT; --暗号化されていない表領域をXTSモードおよびデフォルト・アルゴリズムAES256に変換 ALTER TABLESPACE encts4 ENCRYPTION MODE ‘XTS’ ENCRYPT; --暗号化された表領域をXTSモードに変換 ALTER TABLESPACE encts1 ENCRYPTION using ‘AES256’ MODE ‘XTS’ REKEY; データベースの init.ora に compatible=23.0.0が必要 Exadata 24.1 ~
  35. Smart Scan 時にCell のCPU ボトルネックを特定/排除 • Reverse Offload(Optimized Smart Scan)

    とは? • Storage Server の CPU 使用率をモニタリングし、CPU 使用率が閾値 を超えると Storage Server で行う処理の一部を Database Server 側で実施(プッシュ・バック) • Smart Scan 時に、Storage Server の CPU がボトルネックとなる可能 性を排除 • ユーザーや管理者の設定は必要なく、透過的かつ自動的に実行さ れる機能 • Exadata 11.2.2.3 からの新機能 • Exadata 12.1.2.2.0 より、Database Server へプッシュ・バックする閾値が 改善された • Exadata のモデルや、Database Server および Storage Server の台 数などを考慮し、閾値が決定される • 最大で 15% 性能が改善される • Oracle Database 12.1.0.2 BP11 以降が必要 Reverse Offload (Optimized Smart Scan) Exadata 11.2.2.3.0 ~ Exadata 12.1.2.2.0 ~ 解凍処理 復号処理 暗号データ 圧縮データ 解凍処理 復号処理 11.2.2.3以降 Smart IO 要求 BUSY 復号処理・解凍処理の一部を DB Server へ戻す Copyright © 2026, Oracle and/or its affiliates 42
  36. LOB、JSON、XML の Smart Scan 対応 Additional SQL Operators and Conditions

    for LOB and CLOB SQL Operators for JSON and XML • LOB / CLOB 対応 • LOB データや CLOB データに対しての LIKE 検索や REGEXP_LIKE 検索のオフロード対応 - インラインLOB (表の行に格納されている場合)に限る • Smart Scan は、Secure File Compression にも対応 • 最低ソフトウェア・バージョン: Exadata 12.1.1.1.1 /Oracle DB 12.1.0.2 • JSON / XML 対応 • 以下のSQL演算子のオフロードに対応 - JSON: JSON_EXISTS, JSON_VALUE, JSON_QUERY, "IS JSON“, "IS NOT JSON" - XML: XMLExists, XMLCast(XMLQuery()) • JSON 分析処理が従来の 3 倍高速に select count(*) from pictures where json_value(photo, ‘$.tag’) like ‘%spain%’; • 最低ソフトウェアバージョン:Exadata 12.1.2.1.0 / Oracle DB 12.1.0.2 BP1 43 Copyright © 2026, Oracle and/or its affiliates Exadata 12.1.1.1.1 ~ Exadata 12.1.2.1.0 ~
  37. LOB、XML の Smart Scan 対応のさらなる拡張 圧縮されたインデックスへのSmart Scan対応 Exadata Smart Scan

    Offload Enhancements for XML Exadata Smart Scan Offload Enhancements for LOBs Exadata Smart Scan Offload for Compressed Index Scan • XML データへの Smart Scan の拡張 • 4KB 未満の SecureFiles LOB を使って XML データが保存されている際に、XMLQuery の返り値に適応した XMLExists または XMLCast の WHERE 句の評価が、Exadata Storage Server へオフロードされ得る場合がある • LOB データへの演算子の Smart Scan 対応の拡張 • “LENGTH, SUBSTR, INSTRM CONCAT, LPAD, RPAD, LTRIM, RTRIM, LOWER, UPPER, NLS_LOWER, NLS_UPPER, NVL, REPLACE, REGEXP_INSTR, TO_CHAR” の関数への対応 • 圧縮された index への Smart Scan 対応 • 12.1.2.3.0 まで - 圧縮されていないインデックス、ビットマップインデックスへのSmart Scan 対応 • 12.2.1.1.0 以降 - 圧縮されたインデックスへの Smart Scan 対応 44 Copyright © 2026, Oracle and/or its affiliates Exadata 12.2.1.1.0 ~ NEW IN DB 12.2 Oracle Database 12.2.0.1.0 ~
  38. Exadata Smart Scan Offload Enhancements for In-Memory Aggregation (IMA) •

    In-Memory 集計の技術を Exadata Storage に拡張 (ベクター結合、ベクター集計) • 国ごとの売り上げ額 • SELECT /*+ VECTOR_TRANSFORM */ country_id, sum(amount_sold) amount_sold FROM customers, sales WHERE customers.cust_id = sales.cust_id GROUP BY customers.country_id ORDER BY customers.country_id; • Storage は sales (ファクト表) をスキャンし、 { country_id, sum_amount_sold } の組で結果を返す • ストレージサーバー上のインメモリー列指向形式のデータのスキャン時に、ベク トル変換された問い合わせにより、結合、集計処理を Storage Server にオフ ロード インメモリー集計(IMA)のためのSmart Scanオフロード機能拡張 Copyright © 2026, Oracle and/or its affiliates 45 Exadata 12.2.1.1.0 ~ NEW IN DB 12.2 Oracle Database 12.2.0.1.0 ~
  39. Faster Encrypted Table Smart Scans • インメモリー列形式で格納されている暗号化表のスキャンが、必要時にのみ列を復号することで性能が改善 • SELECTセットまたは述語内の列のみが復号される列になり、フラッシュ・キャッシュのキャッシュ・ライン全体は 復号されない

    • 最初の述語が一致を返さない場合、2番目の述語の列にはアクセスされない • 暗号化された表領域への Smart Scan が最大30%高速化し、ストレージ・サーバーのCPU使用率が削減 • 例 • SELECT ename FROM emp WHERE job LIKE ‘%VP’ AND sal + bonus > 500000 - 予測される列(ename)と1つ以上の予測列のみが復号される - %VPを持たないデータ領域のデータはアクセスされない 高速暗号化表スマート・スキャン Copyright © 2026, Oracle and/or its affiliates 46 Exadata 19.3 ~ Oracle Database In-Memory オプションが必要
  40. Smart Scan Metadata Sharing • 同じパラレル・クエリーに属するスマート・スキャン・セッション間で共通の 問合せメタデータを共有することで、パラレル・クエリーのパフォーマンスと ストレージのスケーラビリティが向上 • すべてのサポートされたOracle

    Databaseバージョンで対応 • 従来型のワークロードと、モダンなワークロードに最適(通常より大きな メタデータを必要とするため) • JSON 、 XML ドキュメントへのクエリ • マシンラーニング・モデル • 外部表 • データマイニングモデル • 大規模なブルームフィルターが利用される場合 • Exadata 21.2で 自動化 かつ 透過的 に実装 Smart Scan におけるメタデータの共有 Query Metadata Cache Parallel Queries Database Instance 1 Database Instance 2 Exadata 21.2 ~ Copyright © 2026, Oracle and/or its affiliates 47
  41. マニュアルより • スマート・スキャン実行時、Oracle Database はクエリー・メタデータを Storage Server に送信 • クエリー・メタデータには、クエリーを

    Storage Server にオフロードするために必要な情報(Predicated カラム、 プロジェクション(抽出・指定された列の抽出)された列、条件、データベース・セッション情報、ブルーム・フィルタ など)が含まれる • 従来、パラレル・クエリの実行時、各 Oracle Database パラレル・クエリー・サーバー・プロセスは、シリアライズ処理され、 圧縮されたクエリ・メタデータをストレージ・サーバーに送信し、そこで使用前に解凍処理およびデシリアライズ処理を 実施 • 各パラレル・クエリで、メタデータの大部分はすべてのパラレル・クエリー・サーバー・プロセスに共通 • Exadata 21.2.0 以降、Exadata System Software は、同じパラレル・クエリに属するスマート・スキャン・セッション間で共 通のクエリー・メタデータを共有 • この機能により、Exadata Storage Server でのパラレル・クエリーのメモリーおよび処理フットプリントが削減 • 節約されたリソースで他の作業をサポートできるため、システム全体のスループットが向上 • ブルーム・フィルタ、データ・マイニング・モデル、外部表、JSON/XML型の表を使用した結合問合せなど、通常より多 くのメタデータを必要とする高度な操作に最適 Smart Scan Metadata Sharing Exadata 21.2 ~ Copyright © 2026, Oracle and/or its affiliates 48
  42. 一時的なバッファ Smart Scan Fast Decryption • 暗号化されたデータのスマートスキャンでは、一時的なステージングバッファーを 使用して、IOバッファーからデータを復号した後、 フィルタリングとプロジェクションを行う必要があった •

    従来はフィルタリング処理とプロジェクション処理のために IOバッファーへテンポラリーバッファーからコピーバックしていた • Smart Scan Fast Decryption • プロセッサーのキャッシュフレンドリーなアルゴリズムを実装することでテンポ ラリーバッファーをフィルタリングやプロジェクションの際に ダイレクトに利用が可能になった • X9M の Smart Scan で2.4倍 の高速な復号 • サポートされているすべての Oracle Database のバージョンで機能 • X9M以降での対応 • VAES, AVX512 などの Ice Lake CPU での新しい命令セットを サポート スマート・スキャンの高速復号化 Copyright © 2026, Oracle and/or its affiliates 49 今後 従来 暗号化されたデータ 復号されたデータ IOバッファーへの転送 復号 Filter / projection IOバッファーへのコピーバック 暗号化されたデータ Filter / projection IOバッファーへの転送 復号 disk disk data data 一時的なバッファ Exadata 21.2 ~
  43. Smart Scan during Online Encryption 領域のオンラインでのTransparent Data Encryption 暗号化およびRekeyを実行中も、 Smart

    Scan が自動的かつ透過的に機能するようになった オンプレミスからOracle Cloud Infrastructureへのデータベースの移行を容易に • オンプレミス・データベースは暗号化されていない • OCI上のデータベースはデフォルトで暗号化 データベースをクラウドに移行するとすぐにオンライン暗号化が開始 • 暗号化はIO集中型でCPU負荷が高い処理 • 暗号化の時間はデータベースのサイズに比例 オンライン暗号化時のスマート・スキャン Copyright © 2026, Oracle and/or its affiliates 50 最大 4倍 クエリースループットが高速化 Exadata 24.1 ~
  44. Wide Tables Smart Scan は透過的に ワイド表をサポート データベース23aiでは、 表あたり4096列がサポート COMPATIBLE=23.0.0 MAX_COLUMNS=STANDARD

    (default) or EXTENDED (4096) Time Zone Upgrade タイムゾーンのアップグレード中の TIMESTAMP WITH TIMEZONE列のない 表に対する問合せに対して、 Smart Scan が有効になりました タイムゾーンのアップグレードは、 時間計算と夏時間の遷移を 正しく処理するため必要になる • TIMESTAMP WITH TIMEZONE列に格 納されているデータが変更される可能 性があります。 Smart Scan オフロード 対象になった関数、演算子 スマート・スキャンは、日付、間隔および ブール・データ型の新しいSQL演算子およ び関数をオフロード Date CEIL 関数、 FLOOR 関数 Interval CEIL関数, FLOOR関数, ROUND関数 、TRUNC 関数 Boolean TO_BOOLEAN 関数 IS FALSE, IS NOT FALSE, IS TRUE, IS NOT TRUE 述語記述子 Smart Scan – さらなる機能追加 Copyright © 2026, Oracle and/or its affiliates 51 Exadata 24.1 ~
  45. Smart Scan on Wide Tables • Oracle Database 23aiでは、最大4096列を含むワイド表のサポートが導入 •

    ワイド表を使用すると、SQL結合を回避するために非正規化(フラット)スキーマを使用するアプリケーションが容易になる。 • ユースケース:最新のアナリティクス、機械学習、Internet of Things (IoT)アプリケーションなど • Oracle Exadata System Softwareリリース24.1.0では、Oracle Database 23aiとともに、ワイド表でのExadata Smart Scan のサポートが 導入 • ワイド表のサポートは、データベース・パラメータ・ファイル(init.ora)でMAX_COLUMNS=EXTENDEDを設定して、データベースで構成する 必要がある。データベースで有効にすると、Exadata Smart Scan のフルパワーが自動的に、透過的にワイド表に適用される • 従来のバージョンのマニュアル記載 • 操作がオフロードされない例(Operation Not Being Offloaded) - 次の場合、スマートI/O操作はExadataストレージ・サーバーにオフロードできません。( A smart I/O operation cannot be offloaded to the Exadata storage servers in the following cases:) • 255を超える列が参照される問合せで、ヒープ表が圧縮されていないか、基本圧縮またはOLTP圧縮である場合。ただし、Exadataハイブリッド列圧縮を使用して圧縮さ れた表に対するこのような問合せはオフロードされます。(A query that has more than 255 columns referenced, and the heap table is uncompressed, or Basic or OLTP compressed. However, such queries on tables compressed using Exadata Hybrid Columnar Compression are offloaded.) [参考] ワイド表でのスマート・スキャン Copyright © 2026, Oracle and/or its affiliates 52 Exadata 24.1 ~
  46. Smart Scan during Timezone Upgrades • Oracle Databaseでは、タイムゾーン定義を使用して、時間計算と夏時間の遷移を処理 • タイムゾーンの変更によって、TIMESTAMP

    WITH TIMEZONEデータ型を使用して列に格納されているデータが変更される可能性がある • 従来は、タイムゾーン定義のアップグレード中は、データベース全体でExadata Smart Scan が無効化されていた • Oracle Exadata System Softwareリリース 24.1.0 は、Oracle Database 23ai と連携して、 タイムゾーン・アップグレードの影響を軽減する。 • 新しい配置では、TIMESTAMP WITH TIMEZONE列がないすべての表に対する問合せに対して、 Exadata Smart Scan が有効なままになる。 • タイムゾーン変更の影響がプラガブル・データベース(PDB)に含まれているようになった。 タイムゾーンの変更が1つのPDBに影響を与える場合、Exadata Smart Scan は他のすべてのPDBに対しては 有効なままになる • 過去の失敗した impdp コマンド(インポート処理)が残っていたりした場合に発生したことがあった • impdp 中にタイムゾーン・アップグレードが含まれる • 従来のバージョンのマニュアル記載 • データベース・タイムゾーンのアップグレード — データベース・タイムゾーンのアップグレードが進行中の場合、スマート・スキャンは無効になります。 AWRレポートのグローバル・ア クティビティ統計セクションまたはインスタンス・アクティビティ統計セクションのデータベース統計 cell num smart IO sessions using passthru mode due to timezone を確認す るか、スマートIOセクションのパススルー理由を確認します。データベース・リリースに応じて、cell smart table scan: db timezone upgrade または cell smart index scan: db timezone upgrade 待機イベントが観測されることもあります。 • cell smart table scan: db timezone upgrade - この待機イベントは、データベース・タイムゾーンのアップグレードが進行中のためにセルがオフロードできないときに表示されます。 [参考]タイムゾーンのアップグレード時のスマート・スキャン Copyright © 2026, Oracle and/or its affiliates 53 Exadata 24.1 ~
  47. Smart Scan on Index-Organized Tables 索引構成表(IOT)では、データがBツリー索引構造に格納される • キー列と非キー列の両方がリーフ・ブロックに格納される Smart Scan

    は、索引構成表(IOT)の格納に使用されるすべての圧 縮形式でサポートされるようになった すべての Smart Scan 機能が透過的に機能 • Storage Index, In-Memory Columnar Cache, 等. 実行計画では Smart Scan の実行は STORAGE句で表示 • INDEX STORAGE FAST FULL SCAN • INDEX STORAGE FULL SCAN 索引構成表でのスマート・スキャン Copyright © 2026, Oracle and/or its affiliates 54 最大 13倍 クエリーの高速化 Index fast full scan Leaf Block Leaf Block Leaf Block Leaf Block Exadata 24.1 ~
  48. Smart Scan on AES-XTS Encrypted Data Database 23ai の TDE暗号化でサポートされた

    AES-XTSで暗号化された表領域で Smart Scan がサポート 新しいAES-XTSモードは、既存のAES-CFBを補完し、格納データのより強力な暗号化を提供 • Database 23aiでは、デフォルトで新しいデータベースにはAES-XTSモード暗号化を使用 TDE表領域暗号化時の AES-XTS暗号化への対応 Copyright © 2024, Oracle and/or its affiliates 56 --デフォルトのAES256アルゴリズムおよびXTSモードで暗号化された表領域を作成 CREATE TABLESPACE encts1 DATAFILE ‘encts1.f’ SIZE 1G ENCRYPTION MODE ‘XTS’ ENCRYPT; --暗号化されていない表領域をXTSモードおよびデフォルト・アルゴリズムAES256に変換 ALTER TABLESPACE encts4 ENCRYPTION MODE ‘XTS’ ENCRYPT; --暗号化された表領域をXTSモードに変換 ALTER TABLESPACE encts1 ENCRYPTION using ‘AES256’ MODE ‘XTS’ REKEY; データベースの init.ora に compatible=23.0.0が必要 Exadata 24.1 ~
  49. • AI Smart Scan • AI Smart Scan Adaptive Top-K

    Filtering • BINARYおよびINT8ベクトル・ディメンション・フォーマット のAI Smart Scan の対応 • Exadataストレージでのベクトル距離プロジェクション • 近傍パーティション・ベクトル索引によるAIスマートス キャン • 含まれる列(Included Columns)により、近傍パーティ ション・ベクトル索引の検索を 高速化 • SPARSEベクトル・データ型に対する問合せの高速化 Smart Analytics: AI Smart Scan Copyright © 2026, Oracle and/or its affiliates 58
  50. Smart Exadata Storage AI Smart Scan 非構造化データに対する迅速なセマンティック類似性検索 Oracle AI Vector

    Searchを Smart Exadata Storage に透過的にオフロードして、検索を高速化 すべてのストレージ・サーバーで自動的に検索を 並列化 RAC node 1 RAC node 2 RAC node 3 Copyright © 2026, Oracle and/or its affiliates 59 Exadata 24.1 ~
  51. 各ストレージ・サーバーで、Top-k マッチングを 個別に計算 • アダプティブTop-Kフィルターは最大4.7倍のデータをフィ ルタ • データベース・サーバーで結果をマージ AIベクトル・クエリを最大30倍高速化 Smart

    Exadata Storage AI Smart Scan 非構造化データに対する迅速なセマンティック類似性検索 Adaptive top-K Adaptive top-K Adaptive top-K Adaptive top-K RAC node 1 RAC node 2 RAC node 3 Copyright © 2026, Oracle and/or its affiliates 60 Exadata 24.1 ~
  52. RAC node 1 RAC node 2 Smart Exadata Storage AI

    Smart Scan 非構造化データに対する迅速なセマンティック類似性検索 数千もの同時AIベクトル検索をオフロードできる マルチユーザー環境をサポート RAC node 3 Copyright © 2026, Oracle and/or its affiliates 61 Exadata 24.1 ~
  53. Top-K filtering performance and efficiency improve by maintaining a running

    top-K set in each storage server. AI Vectorの類似性検索では、ベクトル距離に基づいてランク付けされたTop-Kベクトルを取得 Adaptive Top-Kでは、最終結果をデータベース・サーバーに送信する前にベクトル・データをフィルタ • データをスキャンする場合、各ストレージ・サーバーは、問合せベクトルへの最短ベクトル距離のローカル実行のTop-Kを 保持 • 実行中のTop-Kよりも距離が大きいベクトルはフィルタで除外され、データベース・サーバーには送信されない • Adaptive Top-Kは、より小さな距離が見つかると継続的に更新される メリット • ストレージ・サーバーでの重要なデータ・フィルタリング AI Smart Scan Adaptive Top-K Filtering Copyright © 2026, Oracle and/or its affiliates 62 AIスマート・スキャンのデータ・フィルタリングを最大4.7倍フィルター Exadata 25.1 ~
  54. スキャンされたデータ Regionで最も近い ベクトル Adaptive Top-K データベース・サー バーに返される値 フィルタされた距離 Region 1

    10, 20, 30 10, 20, 30 10, 20, 30 None Region 2 25, 35, 45 10, 20, 25 25 35, 45 Region 3 125, 135, 145 10, 20, 25 None 125, 135, 145 Top-K filtering performance and efficiency improve by maintaining a running top-K set in each storage server. Adaptive Top-Kフィルタリングは、最も関連性の高い結果(つまり最短距離)のみを追跡および保持 AI Smart Scan Adaptive Top-K Filtering Copyright © 2026, Oracle and/or its affiliates 63 10 20 30 Region 1 SELECT vector_id FROM vector_table ORDER BY vector_distance(data_vec, query_vec)) FETCH APPROXIMATE FIRST 3 ROWS ONLY; 10 20 30 Adaptive Top-K 10 20 25 フィルタされた 距離 25 35 45 Region 2 10 20 25 フィルタされた 距離 125 135 145 Region 3 Exadata 25.1 ~
  55. AI Smart Scan supports vectors with INT8 or BINARY dimensions.

    埋め込みモデルにおいてBINARY Vectorフォーマットは、スペースの効率性と優れた精度(リコール)により、一般的に使用されている • BINARYをサポートする埋込みモデルの例: cohere-embed-v3, jina-embeddings-v2-base-en, 等 Oracle Database 23ai (23.6) Vectorデータ型は、FLOAT64, FLOAT32, INT8, BINARY ディメンション形式をサポート BINARY形式のディメンションとは? • 各ディメンションは単一ビット(0または1)で表示 • ベクトルは、パックされたUINT8配列(8次元から1つのUINT8値)として表示 • 例 [1,1,0,0,1,0,0,1, …] -> [201, …] • ベクトルは、精度が高く、サイズが大幅に削減される BINARYおよびINT8ベクトル・ディメンション・フォーマットのAI Smart Scan の対応 Copyright © 2026, Oracle and/or its affiliates 64 FLOAT32と比較してストレージ・フットプリントを32倍削減 距離計算を最大40倍高速化 FLOAT32の精度の90%以上の精度 Exadata 25.1 ~
  56. AI Smart Scan supports vectors with INT8 or BINARY dimensions.

    Exadata System Software 25.1のAIスマート・スキャンでは、 BINARYおよびINT8ベクトル・ディメンション形式のAIベクトル検索問合せをオフロード BINARYおよびINT8ベクトル・ディメンション形式のAIスマート・スキャン・パフォーマンス Copyright © 2026, Oracle and/or its affiliates 65 CREATE TABLE SUPPORT_INCIDENTS (id NUMBER, incident_text VARCHAR2(1000), incident_vector VECTOR(1024, BINARY)); FLOAT32 • Exadataでの AIスマート・スキャンにより 最大30倍の高速化 • 96%以上の精度 INT8 • FLOAT32と比較して AIスマート・スキャンで 最大8倍高速化 • 96%以上の精度 BINARY • FLOAT32と比較して AIスマート・スキャンで 最大32倍高速化 • 92%以上の精度 Exadata 25.1 ~
  57. AI Smart Scan projects vector distances AIスマート・スキャンでは、Exadataストレージ・サーバー上でベクトル距離が自動的に計算される • 計算集中型処理のベクトル距離計算をストレージサーバーへオフロードすることで、 データベース・サーバーのCPUを解放

    • ベクトル距離が必要な問合せの場合、計算された距離は仮想列としてデータベース・サーバーにプロジェクションされる これにより、ストレージ・サーバーからデータベース・サーバーへの大きなベクトルの送信が不要になり、 データベース・サーバーとストレージ・サーバー間のネットワーク・トラフィックが減少し、 データベース・サーバー内でのベクトル距離の再計算が回避される Exadataストレージでのベクトル距離プロジェクション Copyright © 2026, Oracle and/or its affiliates 66 SELECT vector_id, vector_distance (data_vec, query_vec) dist FROM vector_table ORDER BY dist FETCH APPROXIMATE FIRST 3 ROWS ONLY; 問合せが最大で4.6倍高速化 データベースに返されるデータが24倍削減 Exadata 25.1 ~
  58. 近傍パーティション・ベクトル索引によるAIスマートスキャン Optimized support for neighbor partition vector indexes with included

    columns ミッションクリティカルな分析クエリは、リレーショナル・ビジネス・データとAIベクトル類似検索の組み合わせ 価格列(price)および郵便番号列(zipcode)の述語を評価するには、実表(houses)からの参照が必要 description_vectorでの近似検索の評価には、近傍パーティション・ベクトル索引のスキャンが必要 67 Copyright © 2026, Oracle and/or its affiliates zipcode列、price列、description_vector 列を含む houses表を作成 ベクトル索引house_idxを作成、価格 (price)、郵便番号列(zipcode)はベクトル 索引に含まれない 価格(price)と郵便番号(zipcode)でフィルタ リングする上位10の類似住宅のクエリーを 実行 CREATE TABLE houses (id NUMBER, zipcode NUMBER, price NUMBER, description CLOB, description_vector VECTOR(1024, FLOAT32)); CREATE VECTOR INDEX house_idx ON houses (description_vector) ORGANIZATION NEIGHBOR PARTITIONS; SELECT price FROM houses t WHERE price < 2000000 AND zipcode = 94065 ORDER BY VECTOR_DISTANCE(description_vector, :query_vector) FETCH APPROX FIRST 10 ROWS ONLY; Exadata 25.2 ~
  59. 含まれる列(Included Columns)により、近傍パーティション・ベクトル索引の検索を 高速化 Optimized support for neighbor partition vector indexes

    with included columns. 含まれる列(Included Columns)を使用することで、Smart Scanはベクトル検索とともに属性フィルタを直接評価が可能に インデックスにIncluded Columnsとしてクエリーに必要なすべてのカラムが含まれている場合、 インデックスから直接データを取得できるため、クエリーのパフォーマンスが向上 69 Copyright © 2026, Oracle and/or its affiliates CREATE VECTOR INDEX house_idx ON houses(description_vector) INCLUDE (price, zipcode) ORGANIZATION NEIGHBOR PARTITIONS; SELECT price FROM houses t WHERE price < 2000000 and zipcode = 94065 ORDER BY VECTOR_DISTANCE(description_vector, :query_vector) FETCH APPROX FIRST 10 ROWS ONLY; 含まれる列(Included Columns)を使用した問合せにより、最大3倍高速化 データベース RU 23.7以降が必要 価格(price)、郵便番号(zipcode)、が ベクトル索引の列に含まれる priceは、ベクトル索引に含まれている列か ら取得 価格(price)、郵便番号(zipcode)の フィルタは、含まれる列(Included Columns)を使用して直接評価 Exadata 25.2 ~
  60. 含まれる列(Included Columns)を含むネイバー・パーティション・ベクトル索引スキャンの 実行計画 ---------------------------------------------------------------------------------------------------------- | Id | Operation | Name

    | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | VIEW | | | 2 | VIEW | VW_IVPSR_11E7D7DE | |* 3 | COUNT STOPKEY | | | 4 | VIEW | VW_IVPSJ_578B79F1 | |* 5 | SORT ORDER BY STOPKEY | | | 6 | NESTED LOOPS | | | 7 | VIEW | VW_IVCR_B5B87E67 | |* 8 | COUNT STOPKEY | | | 9 | VIEW | VW_IVCN_9A1D2119 | |* 10 | SORT ORDER BY STOPKEY | | | 11 | TABLE ACCESS STORAGE FULL. | VECTOR$VIDX_IVF$32281_32305_0$IVF_FLAT_CENTROIDS | | 12 | PARTITION LIST ITERATOR | | |* 13 | TABLE ACCESS STORAGE FULL | VECTOR$VIDX_IVF$32281_32305_0$IVF_FLAT_CENTROID_PARTITIONS | ---------------------------------------------------------------------------------------------------------- 70 Copyright © 2026, Oracle and/or its affiliates ROWIDベースの表参照を排除 Exadata 25.2 ~
  61. SPARSEベクトル・データ型に対する問合せの高速化 Sparse vectors SPARSEベクトルには多数のディメンションがありますが、ゼロ以外のディメンションはわずか • スパース・エンコーディング・モデル(SPLADE、BM25など)によって生成 • 概念的には、SPARSEベクトルのディメンションが語彙のキーワードにマップされる • 語彙:

    ["the"、 "cat"、 "sat"、 "on"、 "mat"]→5次元 • 文: "cat sat"疎ベクトル: [0、 1、 1、 0、 0] • DENSEベクトルよりもSPARSEベクトルで検索する方が大幅に高速 71 Copyright © 2026, Oracle and/or its affiliates データベース RU 23.7以降が必要 CREATE TABLE support_incidents(id NUMBER, incident_text VARCHAR2(1000), incident_vector VECTOR(30000, FLOAT32, SPARSE)); INSERT INTO support_incidents VALUES (1, ‘Problem with Health Check Agent’, ‘[30000, [15, 78, 1989, 15200, 28022], [0.78, 0.15, 0.98, 0.81, 0.64]]’); Max Dimension Count Non-Zero Dimension Positions Non-Zero Dimension Values Exadata 25.2 ~
  62. Smart Analytics: Storage Index • Exadata Storage Index • Exadata

    Storage Index の動作 • Storage Index セット・メンバーシップ • 永続化 Storage Index • Storage Indexが期待どおりに実行されない
  63. オーバーヘッドなしで透過的に I/O 削減を実現 • Exadata Storage Serverは、Storage Server のメモリ内に、 表データのサマリ情報(Index)を管理

    • ディスク上の1 MB の領域ごとにストレージ・インデックスが 1 エン トリ作成され、列内の最小値、最大値を格納される • 最小値~最大値の中に Where 句の条件がマッチしなければ、 その部分をとばし、物理 I/O を削減できる • パーティション・プルーニングと似た効果が得られる • パーティション設計に変わるものではなく、 パーティション・プルーニングの効果に加えた 物理 I/O 削減効果が得られる • 完全に自動的、透過的に実施される Exadata Storage Index A B C D 1 3 5 6 8 9 Min B = 1 Max B = 5 Table Index Min B = 6 Max B = 9 Select … from Table where B<2 の場合 前半部分のみが検索条件にヒットすることがわかる Copyright © 2026, Oracle and/or its affiliates 74
  64. • Exadata Storage Server によって完全に自動的に、Storage Index が効果的な列を判断して作成される • 管理者が明示的に Index

    を create/drop したりする必要はない。 • Load、Read、Write などの I/O 実行時に Exadata Storage Server 側で Storage Index が自動的に作成、メンテナ ンスされる • Direct Load 時、Full Scan 時に作成され、更新があればメンテナンスされる。 Exadata Storage Index の動作 効果的な列 • 各エントリごとの MIN/MAX 値が異なる列 • 例)データがソートされている列 ※Storage Index によって、データの並び替えが行われる ことはない 対象/非対象の列の例 • NUMBER型、DATE型、VARCHAR型などの一般的な データ型は対象 • 表領域暗号化された列は対象 • 列暗号化は非対称 • Exadata 12.1.2.1.0 ~: MIN関数/MAX 関数にも Storage Index が使用される • Exadata 12.1.2.3.0 ~: Cell-to-Cell のリバランス時においても Storage index の情報を保持 • Exadata 12.2.1.1.0 ~: 従来は 8列の列情報格納が保証、最大24列まで格納可能に拡張 • メタデータ空間は、セットメンバーシップサマリーと最小値/最大値のサマリーにより共有される • ワークロードにより、どちらのサマリー情報が格納されるか決定される Copyright © 2026, Oracle and/or its affiliates 75 Exadata 12.1.2.1.0 ~ Exadata 12.1.2.3.0 ~ Exadata 12.2.1.1.0 ~
  65. Set Membership in Storage Indexes • Exadata Storage Serverは、メモリ内に、表データの サマリ情報(Storage

    Index)を管理 • 1MB ごとにインデックスが1エントリ作成され、列内の最小値、最 大値を格納される。 • 最小値~最大値の中にWhere句の条件がマッチしなけ ればその部分をとばし、物理I/Oを削減できる • 下記のようなクエリーは、Storage Index の効果が見 込める • 右図の state 列のように列のカーディナリティが低い場合 には、下記のクエリーでは Storage Index の効果がの ぞめない Storage Index の従来の課題 76 id name office state 1 Sandra 1336 CA 2 Cecilia 1312 CA 3 Wei 1317 WI 4 Yang 1351 CA 5 Bob 1345 CA 6 Laura 1329 CA 7 Scott 1316 CA …… …… …… …… 999 EMP 表 select count(*) from emp where office < 1300; select count(*) from emp where state = ‘NY’; Column: state Min: CA Max: WI Storage Index は効かない ため、IO を実施する Exadata 12.2.1.1.0 ~ Copyright © 2026, Oracle and/or its affiliates
  66. Set Membership in Storage Indexes • Storage Index では、セット・メンバーシップ機能拡張を実装 •

    セット・メンバーシップは、In-Memory Columnar Cache の使 用時(インメモリー形式の列指向キャッシュを使用してデータ が格納されている場合)に作成される • Database 12.1.0.2.161018, Database 12.2.0.1 よりサポート • 400以下の固有値を持つ場合、Storage Index は内部的に 非常にコンパクトな in memory 表現を作成 • DB は、Storage Server に bloom フィルタを使用するよう リクエスト • Storage Server は、固有値を計算し、bloom フィルタを 作成 • Smart Scan は、bloom フィルタを用いて、等価条件 をチェック、 I/O を削減 • セット・メンバーシップ機能がない、12.2.1.1.0より前のリ リースのOracle Exadata System Softwareでは、通常の ストレージ索引でこれらのディスク・リージョンのフィルタ処 理ができなかった Storage Index セット・メンバーシップ Copyright © 2026, Oracle and/or its affiliates 77 Exadata 12.2.1.1.0 ~ Oracle Database In-Memory オプションが必要 id name office state 1 Sandra 1336 CA 2 Cecilia 1312 CA 3 Wei 1317 WI 4 Yang 1351 CA 5 Bob 1345 CA 6 Laura 1329 CA 7 Scott 1316 CA …… …… …… …… 999
  67. Persistent Storage Index • ストレージインデックスは、ストレージサーバーのメモリに保持されているテーブルデータの サマリを自動的に作成 • ストレージインデックスを永続化すると、計画外および計画済み*のストレージサーバー のダウンタイム後の再構築が回避 •

    Storage Server または Exadata Storage Software の再起動前後の一貫したパフォー マンスを保持 永続化 Storage Index * Exadata X7 以降 & DB 12.2 以降 Storage Server M.2 SSD Exadata 21.2 ~ Copyright © 2026, Oracle and/or its affiliates 78
  68. Persistent Storage Index • Exadata 21.2 以降, Storage Index は以下の場合でも保持される

    • Exadata System Software のアップグレード • cellsrv / celloflsrv の再起動 • cellsrv / celloflsrv のクラッシュ • 通常のシャットダウンの場合、Shared Memory 上の Storage Index はシステムディスクに保存される • 通常のシャットダウン後に cellsrv が起動した際に Storage Index は Shared Memory にロードされる • cellsrv プロセスのクラッシュまたは celloflsrv プロセスのクラッシュが発生した場合、Storage Indexの Shared Memory はOSによって保持され、ソフトウェアサービスが再起動するとすぐに使用可能になる • 以下の場合は保持されない • ハードウエアリセット • 対応 Database バージョン • 12.2, 18.x, 19.x, 21.x 永続化 Storage Index Copyright © 2026, Oracle and/or its affiliates 79 Exadata 21.2 ~
  69. Persistent Storage Index • X7以降の新しいハードウエアの場合、Storage Index は下記の場合で保持される: • Exadata System

    Software のアップグレード- 通常のシャットダウン、OS再起動と OSS スタックの再起動 • 通常のシャットダウンと cellsrv / celloflsrv の起動 • cellsrv / celloflsrv のクラッシュ後の再起動 • X6 以前の古いハードウエアの場合、Storage Index は下記の場合で保持される: • Exadata System Software のアップグレード時には保持されない - Storage Index を保持するだけのディスクスペースが十分に無いため • 通常のシャットダウンと cellsrv / celloflsrv の起動 • cellsrv / celloflsrv のクラッシュ後の再起動 Storage Index の保持される場合、設定方法 Copyright © 2026, Oracle and/or its affiliates 80 Exadata 21.2 ~
  70. Persistent Storage Index • Storage Server の storageIndexPersMode 属性で Persistent

    Storage Index の機能をコントロール • on - Persistent Storage Index 機能有効化 • off - Persistent Storage Index 機能無効化 • auto - Exadata System Software が Storage Index cache 機能を有効か無効化を判断 - storageIndexPersModeが設定されていない場合、auto が適用される - デフォルト設定 storageIndexPersMode =auto • storageIndexPersMode 変更後は変更を反映するため再起動が必要 • Exadata 21.2.0 ~ 21.2.10 では、auto は Persistent Storage Index 機能を無効化(storageIndexPersMode=offと同等) • Exadata 21.2.11 ~ 21.2.14, 22.1.0 ~ 22.1.1 では、auto は Persistent Storage Index 機能を有効化(storageIndexPersMode=onと同等) • Exadata 21.2.15 ~ 21.2.16, 22.1.2 ~ 22.1.3では、auto は Persistent Storage Index 機能を再び無効化(storageIndexPersMode=offと同 等) • Exadata 21.2.17, 22.1.4 では、auto は Persistent Storage Index 機能を有効化(storageIndexPersMode=onと同等) Storage Index の保持される場合、設定方法 Copyright © 2026, Oracle and/or its affiliates 81 Exadata 21.2 ~
  71. • Storage Indexはストレージ・サーバー・メモリーに存在する • 永続Storage Index機能( ESS21.2.0)導入前は、cellsrvを停止するたびにStorage Indexが失われるため、cellsrvの起動後に再構築が必要 - 永続Storage

    Index機能が有効になっていないシステムでは、cellsrvが起動するたびにStorage Indexをすぐに使用できるわけではない • 永続Storage Index機能を有効にしたシステムでは、Storage Indexは共有メモリーに存在し、cellsrvを再起動しても保持される - Storage Indexデータは、サーバーの正常な停止時に永続ストレージに自動的に保存される - サーバーの再起動中、Storage Indexは自動的にリストアされますが、リストア・プロセス中は使用できない - ストレージ・サーバーで異常な停止(停電やカーネル・パニックなど)が発生した場合は、Storage Indexが失われるため、完全に再構築する必要がある • 暗号化されていない表領域のセグメントでは、DMLが発生したときにStorage Indexは保持される • 暗号化された表領域のセグメントでは、DMLにより、変更された各データ・チャンク(1 MB)に関連付けられているStorage Indexの部分が無効化される • 無効化されたチャンクは、セグメントの次回のスキャン中に再構築される • 一部が無効になっているが、Storage Indexの全体的な効率は最適ではない • Storage Indexのパフォーマンス監視 • AWRレポートの Smart IO セクションの Storage Index 列 • データベース統計 cell physical IO bytes saved by storage index • SQLモニター SI saved bytes • Storage Indexがまだ構築(または再構築)されていない場合は、Storage Indexの保存が減少して表示されることがある • Storage Indexの作成中に、データベース統計cell physical IO bytes added to storage indexおよび SQLモニターの行ソース統計Bytes added to storage indexが増加することがわかる Storage Indexが期待どおりに実行されない Copyright © 2026, Oracle and/or its affiliates 82
  72. Smart Analytics: Hybrid Columnar Compression (HCC) • Hybrid Columnar Compression

    (HCC) • HCC 利用時の動作詳細 • HCC表作成、移行、メンテナンス • 圧縮率の検証結果 • 注意点 • Hybrid Columnar Compression の行レベル・ロック • Compression Advisor • MEMSPEED ― ストレージ向け新カラムナー・フォーマッ ト • AWR レポートにおける HCC の情報
  73. データの格納方法の違いによるメリット・デメリット • 従来の格納 (OLTP 表圧縮) • ランダムアクセス (行アクセス) に最適 •

    全表検索に最適 • 2 ~ 5 倍の圧縮 • 列指向の格納 • ランダムアクセスに貧弱 • 全表検索に最適 • 高い圧縮率 • HCC の格納 • ランダムアクセスにも効果的 • 全表検索にも最適 • 高い圧縮率 Hybrid Columnar Compression (HCC) BBB AAA CCC 1,•,▪ 2,▪,▲ 3,▲,• 4,•,• 5,BBB, DDD Column 1 Column 2 Column 3 Column 1 Column 2 Column 3 Compression Unit Compression Unit Copyright © 2026, Oracle and/or its affiliates 85
  74. ハイブリッド・アーキテクチャ • 表は Compression Unit (CU) と呼ばれる単位で 管理される • 1

    CU は複数ブロックで構成される • CU には列単位でデータが格納され、圧縮される - 列単位で格納することで、 似たような値のデータが含まれる可能性が高く、 圧縮率が向上 • 1 行のデータは 1 CU 内に格納される • バルクロード時に HCC 圧縮が行われる • Direct Load、Direct Insert時に圧縮される • 通常のロード時や更新処理時には圧縮は行われ ないため、更新系の処理が少ないテーブルに適する Hybrid Columnar Compression (HCC) CU CU CU Table C1 C2 Compression Unit BLOCK HEADER CU HEADER BLOCK HEADER C3 C4 C5 BLOCK HEADER C6 C7 一行のデータ Copyright © 2026, Oracle and/or its affiliates 86
  75. 業界最高水準の高圧縮機能 • Query Mode • DWH 向け • アクセススピード重視 のモード

    • 約 10 倍の圧縮率 • Archive Mode • 低アクセスデータ、 長期保存データ向け • ストレージ容量、 圧縮重視のモード • 約 15 倍の圧縮 ※データによっては 最大 50 倍の 圧縮率を実現 Hybrid Columnar Compression (HCC) 圧縮レベル Query Low Query High Archive Low Archive High 圧縮率 CPU オーバーヘッド I/O コスト 高 低 高 低 4 つの圧縮レベルから選択 低 高 • クエリのボトルネックが CPU となっている場合=>より低い圧縮形式を検討 • クエリのボトルネックが I/O となっている場合=> より高い圧縮形式を検討 • Exadata は、解凍処理を Storage Server にオフロードできるため、 DB Server の CPU 負荷を軽減可能 Copyright © 2026, Oracle and/or its affiliates 87
  76. 圧縮時の動作 • HCCによる圧縮が行われるタイミング • 圧縮はダイレクトパスロード実行時に行われる - Parallel DML、INSERT /*+ APPEND

    */、Direct Path、SQL*LDR、 Data Pump の direct モードimport • DB 12.2 から配列挿入(非ダイレクト・パス操作)でも HCC表にすることが可能に。 NOAPPENDヒントのINSERT SELECTやAPPENDヒント無しのシリ アルINSERT SELECTでもHCC表にすることが可能に • 通常の insert や update では圧縮率の低い別ブロックに 格納される • データ圧縮時の動作 • データは列ごとに並び替えられ、列単位で圧縮が 行われる • 圧縮後に書き込みが行われるので、 Disk I/O を削減可能 • 圧縮処理はサーバー・プロセス自身が行う HCC 利用時の動作詳細① SQL実行 メモリ上にデータを読み込む 圧縮処理実行 圧縮データの データの書き込み DB Server Storage Server サーバー・ プロセス Copyright © 2026, Oracle and/or its affiliates 88
  77. 圧縮データに対するクエリ実行時の動作 • 非 Smart Scan の場合 • 圧縮された状態でバッファ・キャッシュに読み込まれ、 展開は PGA

    にて行われる • 全表走査の場合、全ての Compression Unit が 読み込まれ、検索に必要な列のみ展開を行う • Smart Scanの場合 • Exadata Storage Server上で展開処理が行われ、 Smart Scan が実施される ※列フィルタリングのみの場合は、 該当の列だけが圧縮された状態で Database Server に送られる • Database Server での展開処理の CPU オーバーヘッド 削減 • 解凍処理後のデータも行フィルタリングすることで、 Database Server に送られるデータ量を削減 HCC 利用時の動作詳細② PGA バッファキャッシュ Smart Scanの場合 非 Smart Scan の場合 展開 DB Server 展開 Smart Scan Storage Server Copyright © 2026, Oracle and/or its affiliates 89
  78. 索引アクセス時の注意点 • 索引アクセスの場合 • 1 行のデータは 1 つの Compression Unit

    に格納 - 複数ブロックに渡って行データが格納される • 索引アクセス時は、複数ブロックにアクセスしなければならない - 非圧縮データへの索引アクセスと比較して、パフォーマンスが低下してしまう可能性がある HCC 利用時の動作詳細③ C1 C2 Compression Unit BLOCK HEADER CU HEADER BLOCK HEADER C3 C4 C5 BLOCK HEADER C6 C7 BLOCK HEADER C8 C9 BBB AAA CCC 1,•,▪ 2,▪,▲ 3,▲,• 4,•,• 5,BBB, DDD 合計 4 ブロック 合計 7 ブロック 1行のデータ 1 2 3 1 2 3 索引 索引 Copyright © 2026, Oracle and/or its affiliates 90
  79. • HCC 表の作成 • 圧縮設定の変更:従来のCompression機能と同様 • 作成済みデータの移行、再圧縮 • Read Only

    での移行 • オンライン再定義を利用すれば移行中にDMLも実施可能 • Partition 単位での圧縮レベルを変更可能なため、ILM 的な利用も可能 HCC表作成、移行、メンテナンス ※11g R2 の場合には赤枠の構文は COMPRESS FOR で実施 12c より COLUMN STORE COMPRESS FOR が利用可能に CREATE TABLE <テーブル名> COLUMN STORE COMPRESS FOR [query | archive] [low | high] ALTER TABLE <テーブル名> COLUMN STORE COMPRESS FOR [query | archive] [low | high] ALTER TABLE <テーブル名> MOVE COLUMN STORE COMPRESS FOR [query | archive] [low | high] TABLE_NAME PARTITION_NAME COMPRESSION COMPRESS_FOR ----------- ---------------- ----------- ------------------ SALES Q4_2004 ENABLED ARCHIVE HIGH ... SALES Q4_2008 ENABLED QUERY HIGH SALES Q1_2009 ENABLED OLTP SALES Q2_2009 ENABLED OLTP Copyright © 2026, Oracle and/or its affiliates 91
  80. E-Business Suiteのデータを利用した圧縮率例 圧縮率の検証結果 ※圧縮率は、アプリケーションやデータの特性によって変わります。 10 10 10 11 16 19

    19 19 20 21 29 43 0 5 10 15 20 25 30 35 40 45 50 Size Reduction Factor by Table OLTP Compression (avg=3.3) Query Compression (avg=14.6) Archive Compression (avg=22.6) 52 約14倍 約22倍 Copyright © 2026, Oracle and/or its affiliates 92
  81. 注意点 • HCC は非 Exadata 環境(ZFS Storage Appliance, ODA 除く)

    では利用できない • スタンバイサイトが非 Exadata の場合、あるいは RMAN のリストアで別 DB に移行する場合には、 移行先で非圧縮または OLTP 圧縮/Basic 圧縮に変換する必要がある • HCC 表への更新を行うと従来までは更新される行を含む Compression Unit 単位でロックがかけられており、 同時実効性が低下する場合がある • HCC 表に対して更新処理 (Insert/Update) が行われた場合は、圧縮率の低いブロックに格納される。 HCC 表への更新を行うとパフォーマンスや同時実行性が落ちるため、ダイレクトパス以外で更新される表に対しては OLTP 圧縮の利用を推奨 • Hybrid Columnar Compression のライセンスは Exadata Storage Server に含まれるが、 OLTP 圧縮を利用する場合には、Oracle Database の Advanced Compression Option の購入も必要 Hybrid Columnar Compression Oracle Database 12.1.0.2 以降、HCC 表の行レベル・ロックも使用可能となった 詳細は次ページ参照。 Copyright © 2026, Oracle and/or its affiliates 93
  82. Hybrid Columnar Compression Row Level Locking • HCC 表への更新を行うと従来までは更新される行を含む Compression

    Unit にロックがかけられており、 同時実効性が低下していた • 12.1.0.2 以降は、HCC 表作成時に ROW LEVEL LOCKING 句を付与することにより、 DML 操作中に行レベル・ロックを使用可能になった • デフォルトで HCC 表を作成した場合は、 NO ROW LEVEL LOCKING となり、 DML 操作時は従来どおり CU 単位でロックを取得する • ROW LEVEL LOCKING をつける場合は Advanced Compression Option ライセンスが必要 Hybrid Columnar Compression の行レベル・ロック create/alter table <テーブル名> column store compress for [query | archive] [low | high] [NO] ROW LEVEL LOCKING Copyright © 2026, Oracle and/or its affiliates 94 Database 12.1.0.2 ~ Oracle Advanced Compression オプションが必要
  83. 使用上の注意点 • HCC表に対して更新処理(Insert/Update)が行われた場合は、圧縮率の低いブロックに格納されるため、圧縮率が 低下する。 • 頻繁に更新される表に対してはOLTP圧縮の利用を推奨。(11g までと同様のガイド) • HCC 圧縮

    に Row level locking をつける場合のメリット • HCC 圧縮表に対して複数セッションからの(近い列への)Update 実施時に従来 dead lock が発生する可能性 がある • Row Level Locking 付きにすることにより dead lock 発生をさせない効果がある Hybrid Columnar Compression の行レベル・ロック Copyright © 2026, Oracle and/or its affiliates 95 Database 12.1.0.2 ~ Oracle Advanced Compression オプションが必要
  84. • Database 11g R2 以降で提供されるアドバイザー • 圧縮タイプ別の圧縮率を予測する • 非 Exadata

    環境でも、 HCC の圧縮率のアドバイスを実行可能 • 参考ドキュメント • Using the Compression Advisor for Implementing Hybrid Columnar Compression (HCC) (Doc ID 1269846.1) • How Does Compression Advisor Work? (Doc ID 1284972.1) • DBMS_COMPRESSION PL/SQL パッケージ サブプログラム • DBMS_COMPRESSION.GET_COMPRESSION_RATIO • DBMS_COMPRESSION.GET_COMPRESSION_TYPE Compression Advisor Copyright © 2026, Oracle and/or its affiliates 96
  85. MEMSPEED ― ストレージ向け新カラムナー・フォーマット Memory Speed Hybrid Columnar Compression CREATE TABLE

    t COMPRESS FOR MEMSPEED [compression level] 97 Copyright © 2025, Oracle and/or its affiliates • 新しいmemspeedカラムフォーマットを活用し、高速な分析処理を実現 • フラッシュおよびXRMEMからネイティブフォーマットでデータを直接処理し、ランタイム変換を不要化 • より大きな圧縮ユニットおよび最適な効率のための透過的なストレージ階層化に対応 • 複数の圧縮レベル(query low、query、archive)を提供 • 圧縮率はDBMS_COMPRESSIONで推定可能 • すべてのExadataシステムで利用可能 Database 26ai ~
  86. HCC 関連の 統計 Cell Statistics RDBMS Statistics 統計名 詳細 統計名

    詳細 HCC scan cell bytes compressed 解凍前に圧縮単位に格納されていた圧縮 済データの長さ。これは、アクセスされた列の みでなく、すべての列の長さです。 HCC scan rdbms bytes compressed 解凍前に圧縮単位に格納されていた圧縮 済データの長さ。これは、アクセスされた列の みでなく、すべての列の長さです。 HCC scan cell bytes decompressed 圧縮単位に格納されていたデータの解凍後 の長さ。これは、アクセスされた列のみでなく、 すべての列の長さです。 HCC scan rdbms bytes decompressed 圧縮単位に格納されていたデータの解凍後 の長さ。これは、アクセスされた列のみでなく、 すべての列の長さです。 HCC scan cell CUs archive high ARCHIVE HIGHで圧縮されていた、スキャンさ れた圧縮単位の数 HCC scan rdbms CUs archive high ARCHIVE HIGHで圧縮されていた、RDBMS 表スキャンによって解凍されたHCC圧縮単位 の数 HCC scan cell CUs archive low ARCHIVE LOWで圧縮されていた、スキャンさ れた圧縮単位の数 HCC scan rdbms CUs archive low ARCHIVE LOWで圧縮されていた、RDBMS表 スキャンによって解凍されたHCC圧縮単位の 数 HCC scan cell CUs columns accessed 圧縮単位を処理するためにストレージ・サー バー上で解凍する必要があった列の数 HCC scan rdbms CUs columns accessed 解凍された列の数 [参考]AWR レポートにおける HCC の情報(1) Copyright © 2026, Oracle and/or its affiliates 98
  87. HCC 関連の 統計 Cell Statistics RDBMS Statistics 統計名 詳細 統計名

    詳細 HCC scan cell CUs decompressed ストレージ・サーバー上で解凍する必要があ る圧縮単位の数 HCC scan rdbms CUs decompressed RDBMSサーバー上で解凍された圧縮単位の 数 HCC scan cell CUs decompression time ストレージ・サーバーで列の解凍に要した合 計時間 HCC scan rdbms CUs decompression time RDBMSサーバーで列の解凍に要した合計時 間 HCC scan cell CUs optimized read 格納されている最小値と最大値の範囲内に すべての行があった圧縮単位の数。これらの 述語の評価が最適化されました。 HCC scan rdbms CUs normal RDBMS標準表スキャン(つまり、問合せプラン でのTable Access Full)によって解凍された HCC圧縮単位の数。これは通常、行バージョ ンや行SCNの使用、またはLONG RAWデータ 型の使用など、特殊なスキャンで使用されま す。 HCC scan rdbms CUs turbo RDBMS高速表スキャン(TurboScan)によって 解凍されたHCC圧縮単位の数。これは、 Exadataセルで発生する解凍とは別です。 [参考]AWR レポートにおける HCC の情報(2) Copyright © 2026, Oracle and/or its affiliates 99
  88. HCC 関連の 統計 Cell Statistics RDBMS Statistics 統計名 詳細 統計名

    詳細 HCC scan cell CUs pruned 最小/最大値チェックに基づいてプルーニング された圧縮単位の数 HCC scan rdbms CUs pruned 述語を圧縮単位について格納されている最 小値および最大値と比較することで削除され た、その圧縮単位の数 HCC scan cell CUs query high QUERY HIGHで圧縮されていた、スキャンされ た圧縮単位の数 HCC scan rdbms CUs query high QUERY HIGH (デフォルト)で圧縮されていた、 RDBMS表スキャンによって解凍されたHCC圧 縮単位の数 HCC scan cell CUs query low QUERY LOWで圧縮されていた、スキャンされ た圧縮単位の数 HCC scan rdbms CUs query low QUERY LOWで圧縮されていた、RDBMS表ス キャンによって解凍されたHCC圧縮単位の数 HCC scan cell CUs sent compressed 述語評価の実行後に圧縮状態のままスト レージ・サーバーからRDBMSに返された圧縮 単位の数 HCC scan cell CUs sent head piece ストレージ・サーバーで処理できなかった、処 理対象のRDBMSにブロック・ヘッダーが返され た圧縮単位の数 HCC scan cell CUs sent uncompressed ストレージ・サーバーからRDBMSに非圧縮列 形式で返された圧縮単位の数 [参考]AWR レポートにおける HCC の情報(3) Copyright © 2026, Oracle and/or its affiliates 100
  89. HCC 関連の 統計 Cell Statistics RDBMS Statistics 統計名 詳細 統計名

    詳細 HCC scan cell rows ストレージ・サーバーからRDBMSに返された、 列形式のデータからの行数 HCC scan rdbms rows HCCブロックから返された行の数、またはその 表の述語に合格した、Exadataセルから列形 式で返された行の数 HCC scan CUs pcode aggregation pushdown ポータブルバイト・コードを使用してセルに対し て集計された圧縮単位の数 HCC scan CUs pcode pred evaled ポータブルバイト・コードを使用して評価され た述語の数 HCC scan CUs pcode pred evaled using rowsets ベクトル化データを使用しポータブルバイト・ コードを使用して評価された述語の数 HCC scan CUs predicates applied 少なくとも一部の値が最小/最大チェックに合 格した述語の数 HCC scan CUs predicates optimized 列データに対して直接評価できる述語の数 HCC scan CUs predicates received 解凍後にHCC形式データに対して直接評価 できる、ストレージ・サーバーに送信された述 語の数 HCC scan rows pcode aggregated 問合せコンパイルのポータブルコード・スタイル を使用して集計できる、HCCブロックからの行、 またはExadataセルによって返された列形式ブ ロックからの行の数 [参考]AWR レポートにおける HCC の情報(4) Copyright © 2026, Oracle and/or its affiliates 101
  90. Storage Server モデルによる RDMA Memory と Flash デバイスの効率的な利用 • Exadata

    Storage Server には、モデルによって Persistent Memory と Flash デバイスが搭載 • Exadata Storage Server High Capacity モデル • RDMA Memory (X11Mの場合) Storage Server あたり 1.25 TB • Flash デバイス (X11M の場合) Storage Server あたり 6.8 TB PCIe Flash device x 4 枚 • Exadata Storage Server Extreme Flash モデル • RDMA Memory (X11Mの場合) Storage Server あたり 1.25 TB • パフォーマンス最適化Flash デバイス (X11M の場合) Storage Server あたり 6.8 TB PCIe Flash Card x 4 枚 • 容量最適化Flash デバイス (X11M-2 の場合) Storage Server あたり 30.72 TB PCIe Flash Card x 4 枚 • Exadata Storage Server Extended (XT) モデル • RDMA Memory は搭載していない • パフォーマンス最適化Flash デバイス (X11M の場合) Storage Server あたり 6.8 TB PCIe Flash Card x 2 枚 Exadata RDMA Memory および Smart Flash テクノロジー概要 Copyright © 2026, Oracle and/or its affiliates 104
  91. • XRMEMCACHE(旧Persistent Memory Data Acclerator (PMEM Cache)) • Exadata X10M

    以降では XRMEMCACHE は DRAM を使用 • Exadata Storage Server X8M、X9Mの HC/EF モデル • Block Cache • ランダム I/O の高速化により OLTP ワークロード処理性能の向上に寄与 • PMEM Log を除く、残りの PMEM 領域が割り当て • XRMEMLOG(旧Persistent Memory Commit Accelerator (PMEM Log)) • Exadata X10M 以降では XRMEMLOG は実装されない • Exadata Storage Server X8M、X9Mの HC/EF モデル • Redo 書き込み高速化 • Storage Server あたりデフォルト 10176 MB(Exadata 20.1 以降。Exadata 19.3 では960 MB) Exadata RDMA Memory (XRMEM)(旧Persistent Memory) および Smart Flash テクノロジー概要 Copyright © 2026, Oracle and/or its affiliates 105 Exadata 19.3.0 ~ Exadata 23.1.0 ~
  92. Smart Flash テクノロジー (1/3) Exadata Storage Server の Flash デバイスの利用用途

    • Smart Flash Log • Redo 書き込み高速化 • Smart Flash Cache • Block Cache (いわゆる Flash Cache とも呼ばれる) - ランダム I/O の高速化により OLTP ワークロード処理性能の向上に寄与 • Columnar Cache - Smart Scan のさらなる高速化により DWH/Analytics ワークロードの処理性能の向上に寄与 Persistent Memory および Smart Flash テクノロジー概要 Copyright © 2026, Oracle and/or its affiliates 106
  93. Smart Flash テクノロジー (2/3) Exadata Storage Server HC モデルの Flash

    デバイスの利用用途・サイズ • Smart Flash Log • Storage Server あたりデフォルト 512 MB、Flash デバイスあたり 128 MB が割り当て • Smart Flash Cache • Flash Log を除く、残りの Flash 領域が割り当て Persistent Memory および Smart Flash テクノロジー概要 Copyright © 2026, Oracle and/or its affiliates 107
  94. Smart Flash テクノロジー (3/3) Exadata Storage Server EF モデルの Flash

    デバイスの利用用途 • Smart Flash Log • Storage Server あたりデフォルト 512 MB、Flash デバイスあたり 64 MB が割り当て • Smart Flash Cache • Storage Server あたりデフォルトすべての Flash デバイスサイズの 5% を割り当て • ただし、HC モデルとは異なり、Block I/O および Smart I/O はキャッシュされず、Columnar Cache、 I/O Latency Capping for Write Operation、Fast Data File Creation の用途として使用される • OS 領域 (X5 および X6 のみ) • 2 つの Flash デバイスに対して、それぞれ約 33 GB の領域が割り当て • ASM ディスク (griddisk) • 上記 Flash 領域を除く、残りの Flash 領域 Persistent Memory および Smart Flash テクノロジー概要 Copyright © 2026, Oracle and/or its affiliates 108
  95. Smart OLTP : Exadata Smart Flash Log • Redo 書き込み待機の問題点

    • Exadata Smart Flash Log • Exadata Smart Flash Log を利用した高速な REDO 転 送 • Exadata Smart Flash Log の動作 • Smart Flash Log Write-Back • Pipelined Log Writes • Exadata Smart Flash Log の構成 • Exadata Smart Flash Log の効果確認 • 待機イベントを使用したExadataスマート・フラッシュ・ロ グの監視 • Exadataメトリックを使用したExadataスマート・フラッ シュ・ログの監視 • Exadataスマート・フラッシュ・ログを監視する際の注意 事項 111 Copyright © 2026, Oracle and/or its affiliates
  96. • Redo ログ書き込みのレイテンシーは重要 • トランザクションのコミット性能には、 Redo ログ 書き込みのレイテンシーが影響 • 領域管理や

    Index のスプリットなどの動作性能 にも影響 • Log Writer の IO で遅い IO があると、 全てのクライアントの遅延につながる • ひとつでもミラーへの書き込みが遅いと、 レスポンスタイムに影響が出る • 通常のストレージでは、Redo IO かそれ以外の IO か の区別をつけることができない Redo 書き込み待機の問題点 Log Buffer client foreground client foreground client foreground Log Writer log file sync log file parallel write 全ての Redo IO は例外なく、 高速処理される必要がある Copyright © 2026, Oracle and/or its affiliates 112
  97. 2 つの領域に同時書き込み、どちらかに書き込めれば処理完了 • Redo ログの書き込みを冗長化することで、 レスポンスタイムを安定させ、 データベース全体のスループットの向上を実現 • Flash 領域の一部を

    Smart Flash Log 領域として確 保 • Redo ログの書き込みを、ASM Disk 領域と Smart Flash Log 領域に同時に行い、どちらかに書き込みが 完了した時点で、Redo ログの書き込み処理が完了 する。 • 待機イベント log file sync, log file parallel write の 改善 • 完全に自動化され、透過的に実行される • Flash のわずかな領域の利用により、Flash Cache など他の機能にはほとんど影響なし Exadata Smart Flash Log Spikeが存在 待機が削減され、 レイテンシーが一定 Smart Logging - Off Smart Logging - On Log Writer 1 デバイスへの書き込み Spike が発生しやすい 2 デバイスへの書き込み どちらかが速ければ、 Spike は発生しない Log Writer Copyright © 2026, Oracle and/or its affiliates 113 Exadata 11.2.2.4.0 ~
  98. Exadata Smart Flash Log を利用した高速な REDO 転送 【参考】 Data GuardでのSmart

    Flash Logの効果 DBWR LGWR NSS/NSA RFS Smart Flash Log Smart Flash Log MRP スタンバイ Redo ログの書き込みもSmart Flash Log を利用可能。 Archive Log Standby Redo Log Online Redo Log Database File プライマリー スタンバイ (スタンバイもExadata) Copyright © 2026, Oracle and/or its affiliates 114
  99. Redo 書き込み時の動作 リカバリ時の動作 Exadata Smart Flash Log の動作 (HC モデルの例)

    (~Exadata 19.3.0) Exadata Storage Server Database Server Redo Log Buffer LGWR ASM Disk と Flash の両方に書き込み。 どちらか早いほうが返ってきたら IO 完了 とする。 それぞれへの書き込みは、IO 処理の 完了とは別に 最後まで実施される Smart Flash Log Disk Controller Cache Hard Disk Cellsrv Database Server Smart Flash Log Redo Log Buffer リカバリ プロセス Disk Controller Cache Cellsrv ASM Disk 上の Redo ログファイルを読み込んで リカバリ実施 Hard Disk Exadata Storage Server Copyright © 2026, Oracle and/or its affiliates 115 ~ Exadata 19.3.0 Smart Flash Log Disk Controller Cache Hard Disk Cellsrv Smart Flash Log Disk Controller Cache Hard Disk Cellsrv
  100. Redo ログの書き込みスループットの向上 • Redo ログの書き込みレイテンシーは OLTP データベースのパフォーマンスにとって重大な課題 • Redo ログの書き込みのレイテンシーは従来は

    Smart Flash Log と Persistent Memory Commit Accelerator の機能で対処 • Smart Flash Log Write-Back は Redo log の書き込みスループットを向上させる新機能 • Redo ログを Exadata Smart Flash Cache 領域に Write-Back モード で書き込み • Exadata X7 以降の Storage Server High Capacity モデルで、 ARCHIVELOG モードで利用されているOracle Database で自動で透過的に設定される • ログの書き込みスループットで最大2.5倍の性能向上 • Data Guard のプライマリ・データベースのオンライン Redo ログと スタンバイ・データベースのスタンバイ Redo ログのスループットを向上させる • 複数の同時ワークロードでハードディスクの IO バンド幅が必要なケースで利点がある (例 RMAN バックアップ・リストア) Smart Flash Log Write-Back Exadata 20.1.0 ~ 20.1以降 FLASH#1 FLASH#2 Flash Cache Smart Flash Log 従来 FLASH Smart Flash Log Exadata X7 以降の HC モデルが必要 Write Back Flash Cache 構成時のみ有効 Copyright © 2026, Oracle and/or its affiliates 116
  101. REDOログ書き込みのパイプライン処理対応 REDOログ書込みを低レイテンシで実行できることは、OLTPデータベースのパフォーマンスに不可欠 • トランザクション処理はREDOログがコミットされて永続化するまで待つ • REDOログが永続化された後、RACインスタンス間のブロック転送が許可される Oracle Database 23aiおよび19c*でExadata X10M以降では、ログ・ライター(LGRW)がオーバーラッピング・ライトを発行して、

    トランザクション処理を高速化するためのREDOパイプラインを作成 • 超高速RoCEネットワークとExadataストレージ上の Smart Flash Log を活用 Pipelined Log Writes Copyright © 2026, Oracle and/or its affiliates 117 最大 1.45倍 トランザクション処理を高速化 パイプライン処理していない ログ書き込み Redo #1 Redo #2 Redo #3 Persist Issue Ack Persist Issue Ack Persist Issue Ack パイプライン処理に対応した ログ書き込み Redo #1 Redo #2 Redo #3 Persist Issue Ack Persist Issue Ack Persist Issue Ack Exadata 24.1.0 ~
  102. Exadata X9M-2 HC • デフォルトでは 512 MB のサイズで Flash Log

    領域が作成される。 【参考】 Exadata Smart Flash Log の構成 Copyright © 2026, Oracle and/or its affiliates 118 • サイズを指定して作成することも可能 [root@cancercel01 ~]# cellcli -e list flashlog detail name: cancercel01_FLASHLOG cellDisk: FD_00_cancercel01,FD_01_cancercel01,FD_02_cancercel01,FD_03_cancercel01 creationTime: 2022-10-05T13:03:05+09:00 degradedCelldisks: effectiveSize: 512M efficiency: 100.0 id: 5c143587-544a-4a04-a9bc-616adb853aaf size: 512M status: normal [root@cancercel01 ~]# CellCLI> CREATE FLASHLOG ALL SIZE=1g
  103. Exadata X9M-2 EF • デフォルトでは 512 MB のサイズで Flash Log

    領域が作成される。 【参考】 Exadata Smart Flash Log の構成 Copyright © 2026, Oracle and/or its affiliates 119 • サイズを指定して作成することも可能 [root@cancercel04 ~]# cellcli -e list flashlog detail name: cancercel04_FLASHLOG cellDisk: FD_00_cancercel04,FD_01_cancercel04,FD_02_cancercel04,FD_03_cancercel04,FD_04_cancer cel04,FD_05_cancercel04,FD_06_cancercel04,FD_07_cancercel04 creationTime: 2022-10-06T16:18:34+09:00 degradedCelldisks: effectiveSize: 512M efficiency: 100.0 id: ce7b36c4-da62-4ae9-8b22-0376feb5fdc0 size: 512M status: normal [root@cancercel04 ~]# CellCLI> CREATE FLASHLOG ALL SIZE=1g
  104. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Log Statistics 【参考】 Exadata Smart Flash Log の効果確認 Copyright © 2026, Oracle and/or its affiliates 120 Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ Exadata 12.2.1.1.0 ~
  105. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Log Statistics > Flash Log 【参考】 Exadata Smart Flash Log の効果確認 Copyright © 2026, Oracle and/or its affiliates 121 First Writes:Exadataスマート・フラッシュ・ログへの書込みの数 Outliers/Prevented: Exadataスマート・フラッ シュ・ログによって回避された外れ値の数 Exadataスマート・フラッシュ・ログがスキップされ た回数 Exadataスマート・フラッシュ・ログが最適に動作する 場合の例 I/Oはすべてのセルに均等に分散され、Skip が無い Skip Count がゼロより大きい場合、Flash Log Skip Details セクションには、Exadataスマート・フラッシュ・ ログをスキップする理由が記載 Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~
  106. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Log Statistics > Redo Write Histogram 【参考】 Exadata Smart Flash Log の効果確認 Copyright © 2026, Oracle and/or its affiliates 122 データベースからのlog file parallel writeのレイテンシ ストレージ・サーバーからのredo write request completionのレイテンシ データベースとStorage Server のレイテンシ・ヒストグラムを比較することで、 高いレイテンシの外れ値がストレージ・サーバーの処理ボトルネックに関連しているかどうかを判断する Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~
  107. REDO書込みおよびExadataスマート・フラッシュ・ログのパフォーマンスの監視に役立つ様々なデータベース統計 • REDO書込みおよびExadataスマート・フラッシュ・ログのパフォーマンスの監視に役立つデータベース待機イベント • 待機イベントの表示 • V$SESSION • V$SYSTEM_EVENT •

    V$SESSION_EVENT • log file parallel write • Oracle Databaseログ・ライター(LGWR)プロセスは、REDOログ・ファイルへの書込みの完了を待機しているときに、 このイベントを待機 • Exadataスマート・フラッシュ・ログが効率的に使用されていることは、このイベントの待機時間が比較的短いことが表示 • log file sync待機イベントのレイテンシが長い場合、それに対応して、LGWR プロセスでの log file parallel write待機イベントのレ イテンシが長くなる • REDOログ書込みのパフォーマンス・クリティカルな性質のため、log file parallel writeの平均待機時間が許容される場合でも、log file parallel writeに不定期の長いレイテンシがあることで、データベース・パフォーマンスが変動することがある • いずれかが発生している場合は、Exadataスマート・フラッシュ・ログのパフォーマンスに問題があることを示している可能性がある 【参考】待機イベントを使用したExadataスマート・フラッシュ・ログの監視 Copyright © 2026, Oracle and/or its affiliates 123
  108. • objectType=FLASHLOGであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • 関連メトリック(抜粋) 【参考】 Exadataメトリックを使用したExadataスマート・フラッシュ・ログの監視 Copyright © 2026, Oracle

    and/or its affiliates 124 FL_IO_TM_W 累積の redo log 書き込み遅延。Oracle Exadata Smart Flash Logにて制御不可な遅延を含む FL_RQ_TM_W 累積の redo log 書き込み遅延。ネットワークやその他の遅延も含む ネットワークおよび処理などの要因によるレイテンシ・オーバーヘッドを取得するには、“FL_RQ_TM_W” - “FL_IO_TM_W”を使用 FL_SKIP_OUTLIERS REDOログ書込みでフラッシュ・ログの使用がスキップされたときの外れ値の数を追跡。外れ値は0.5秒を超えたREDOログ書込み FL_SKIP_OUTLIERS "The number of times redo writes to disk exceeded the outlier threshold when Smart Flash Logging was not used" 以下に関連する理由でFlash Log の使用がスキップされることがある FL_IO_W_SKIP_DISABLED_GD "The number of redo writes that could not be serviced by Smart Flash Logging because it was disabled for the redo log's grid disk" FL_IO_W_SKIP_IORM_LIMIT "The number of redo writes that could not be serviced by Smart Flash Logging because the IORM limit had been reached for the redo log's grid disk" FL_IO_W_SKIP_IORM_PLAN "The number of redo writes that could not be serviced by Smart Flash Logging because it was disabled by the IORM plan" FL_IO_W_SKIP_LOG_ON_FLASH "The number of redo writes that could not be serviced by Smart Flash Logging because the redo log resided on flash" FL_IO_W_SKIP_NO_FL_DISKS "The number of redo writes that could not be serviced by Smart Flash Logging because there were no available Flash Log disks” ディスクとフラッシュ・ストレージに同時に書き込むとき、ディスク・コントローラの書込みキャッシュは、フラッシュよりも高速に一部の書込みを吸収できる。 そのため、ディスクへのREDOログ書込み操作のかなりの部分がフラッシュよりも前に完了するのは正常 CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = FLASHLOG Exadata 12.2.1.1.0 ~
  109. 一般的なパフォーマンス • REDOログに関連するパフォーマンスの問題での典型的な例 • 通常、Oracle Databaseユーザー・フォアグラウンド・プロセスでのlog file sync待機イベントのレイテンシが長い場合、 それに対応して、Oracle Databaseログ・ライター(LGWR)プロセスでのlog

    file parallel writeのレイテンシが長くなる • REDOログ書込みはパフォーマンス・クリティカルな性質のため、log file parallel writeの平均待機時間が許容される 場合でも、log file parallel writeに不定期の長いレイテンシがあることで、データベース・パフォーマンスが変動するこ とがある • これらのいずれかが発生している場合は、Exadataスマート・フラッシュ・ログのパフォーマンスに問題があることを示してい る可能性がある Exadataスマート・フラッシュ・ログを監視する際の注意事項(1) Copyright © 2026, Oracle and/or its affiliates 125
  110. REDO Write Histogram • log file parallel write 待機イベントは、データベースがREDOログ書込みを待機する時間を示す •

    log file parallel write ヒストグラム(Redo Write Histogram内)は、指定された時間範囲内にREDO書込みが完了した回数を示す • Redo log write completions 統計は、ストレージ・サーバーがREDO書込みリクエストの処理に費やした時間を示す • Redo log write completions ヒストグラム(Redo Write Histogram内)は、指定された時間範囲内にREDO書込みリクエストが完了した回数を示す。 • 不定期の長いレイテンシが多数あるヒストグラムは、ロング・テールがあると言われる。 AWRレポートのREDO Write Histogram セクションの両方のヒストグラムにロング・テールがある場合は、 ストレージ・サーバーでの書込みが低速であることを示すため、他のI/Oパフォーマンス統計をさらに調査する必要がある。 セル・ディスクI/Oの監視を参照 • log file parallel write ヒストグラムに、Redo log write completions ヒストグラムに存在しないロング・テールがある場合、 原因は通常、ストレージ・サーバーではなく、ネットワークのボトルネックやコンピュート・ノードCPUの競合など、I/Oパスの別のものである Exadataスマート・フラッシュ・ログを監視する際の注意事項(2) Copyright © 2026, Oracle and/or its affiliates 126
  111. Skipping • REDO書込みレイテンシの増加: • Exadataスマート・フラッシュ・ログがスキップされ、REDO書込みがディスクに対してのみ行われる場合にも発生する可能性 • AWRレポートとストレージ・サーバー・メトリックの両方に、Exadataスマート・フラッシュ・ログをスキップしたREDOログ書込み数が表示 • Exadataスマート・フラッシュ・ログにまだディスクに書き込まれていないデータが大量にある場合、スキップが発生することがある •

    REDO書込みでExadataスマート・フラッシュ・ログがスキップされる可能性のある要因 • 書込みレイテンシが長いフラッシュ・ディスクがある場合 - AWRレポートの Exadata Resource Statistics セクションにある様々な IO Latency 表およびExadataのCELLDISKメトリックで観測可能 FL_FLASH_ONLY_OUTLIERS メトリックをチェックすることによっても識別可能 メトリック値が大きい場合、これはフラッシュ・ディスクのパフォーマンスに問題があることを示す • レイテンシが長い、または使用率の高いハード・ディスクがある場合 - Exadata System Software 20.1より前では、REDOログ書込みはExadataスマート・フラッシュ・ログとハード・ディスクの両方に書き込まれる。ハード・ディスクのレイテンシが長 い場合や使用率が高い場合は、REDOログの書込みパフォーマンスに影響する可能性 • AWRレポートの Exadata Resource Statistics セクションにある様々な IO Latency 表およびExadataのCELLDISKメトリックで観測可能 AWRレポートの Flash Log セクションの Outliers 値列、または FL_PREVENTED_OUTLIERS メトリックをチェックすることによっても識別可能 抑制された外れ値の数が多い場合は、ハード・ディスクの書込みに時間がかかっていることを示している可能性 • Exadataスマート・フラッシュ・ログは外れ値を抑制するが、ディスクに書き込む必要があるREDOログ・データのキューが原因で、全体的なスループットが制限される可能性 - Exadata System Software 20.1では、ディスク・ストレージではなくExadataスマート・フラッシュ・キャッシュをライトバック・モードで使用する、 スマート・フラッシュ・ログ・ライトバックと呼ばれる最適化がさらに追加されているため、潜在的なパフォーマンスのボトルネックとしてハード・ディスクが排除 • システムのワークロードによっては、この機能により、ログ書込みの全体的なスループットが最大250%向上する可能性 Exadataスマート・フラッシュ・ログを監視する際の注意事項(3) Copyright © 2026, Oracle and/or its affiliates 127
  112. Smart OLTP: Smart Flash Cache – Block Cache • Exadata

    Smart Flash Cache (Block Cache) • Exadata Smart Flash Cache (Write-Through モード)の 動作 • 表スキャン・ワークロードの自動 Flash キャッシング • Exadata Flash Cache へのデータベース・オブジェクトの KEEP処理の自動化 • Exadata Smart Flash Cache (Write-Back モード) • Exadata Smart Flash Cache の可用性 • Exadata Smart Flash Cache の構成 • Fast Data File Creation • Flash Cache機能拡張 • Exadata I/O Latency Capping • 大量分析問合せおよび大量ロードのパフォーマン ス高速化 • フラッシュ・キャッシュでのOracle ACFS I/Oキャッシュ • Exadataスマート・フラッシュ・キャッシュでのフラッシュ バック・ログ書込みのキャッシュ • 一時データに対するフラッシュ・キャッシュの即時再 利用 • フラッシュ・キャッシュへの重要な大規模書込みの 優先度付け • Exadataスマート・フラッシュ・キャッシュの監視 • AWRを使用したExadata Smart Flash Cacheの監 視 • データベース統計を使用したExadataスマート・フ ラッシュ・キャッシュの監視 • 待機イベントを使用したExadataスマート・フラッ シュ・キャッシュの監視 • Exadataメトリックを使用したExadataスマート・フラッ シュ・キャッシュの監視 • Exadataスマート・フラッシュ・キャッシュを監視する 際の注意事項 140 Copyright © 2026, Oracle and/or its affiliates
  113. Smart Flash Cache (Block Cache) の 2 つのモード • Write-Through

    Flash Cache • Read I/O のみを Flash 上にキャッシュする機能 • 従来の Exadata System Software で利用できた Flash Cache 機能 • Write-Back Flash Cache • Read だけでなく Write I/O についても Flash 上にキャッシュする機能 • Exadata 11.2.3.2.0 より導入され、現在はこちらがデフォルトのモード(OEDA 2017/Apr以降) Exadata Smart Flash Cache (Block Cache) Copyright © 2026, Oracle and/or its affiliates 141 Exadata 11.2.3.2.0 ~
  114. ランダム Read I/O のボトルネックを解消 • Exadata Storage 内の Flash デバイスに、頻繁にアクセスするデータをキャッシュ

    • Write-Through Flash Cacheでは冗長構成が必要ない • データはディスク上に格納されている • Flash 領域を効率よく利用することができる • テーブルスキャンの際に、自動的に Smart Flash Cache と ASM ディスクに対してスキャンが可能 Exadata Smart Flash Cache (Write-Through モード) • キャッシング方法 • 透過的に実施される。通常の LRU アルゴリズムよりも賢い方法 • オブジェクトのキャッシュをスキップすべきか判断 • キャッシュすべきオブジェクトを手動で指定することも可能 Copyright © 2026, Oracle and/or its affiliates 142
  115. Read I/O を高速化 Exadata Smart Flash Cache (Write-Through モード)の動作① Exadata

    Storage Server Database Server Flash Cache ① ② ③ ① ② ① ② ③ ② ② オブジェクトをキャッシュする場合の Write 動作 ① Disk に書き込み ② 書き込み完了 ACK ③ 非同期で Flash Cache にキャッシュ オブジェクトをキャッシュしない場合の Write 動作 ① Disk に書き込み ② 書き込み完了 ACK すでにキャッシュされているデータの Read 動作 ①② Flash Cache からデータ読み込み キャッシュするデータの Read 動作 ①② Disk からデータ読み込み ③ 非同期で Flash Cache にキャッシュ ここが高速化 ① Copyright © 2026, Oracle and/or its affiliates 143
  116. • データべースの I/O の種類を自動で理解してキャッシュ • 管理者は特定のオブジェクトを Flash Cache にKEEPさせるように指定も可能 •

    Storage 句の変更が許可されるオブジェクトの場合、表レベル、パーティションレベルで alter 文/ create 文も可能 • CELL_DLASH_CACHE KEEP が指定されたオブジェクトへのテーブルスキャンは Flash Cache を介して実施される • 現在は通常はKEEP設定は不要 Exadata Smart Flash Cache (Write-Through モード)の動作② • ASM のミラーコピーの I/O • バックアップ、Data Pump の I/O • 表領域のフォーマット • テーブル・フルスキャン(KEEP 設定されていないオブジェクト) • 制御ファイルの Read/Write I/O • ファイルヘッダーの Read/Write I/O • Data Block と Index Block キャッシュしない IO キャッシュする IO ※テーブル・スキャンに対するキャッシュ・ポリシーは、Exadata 11.2.3.3.0 ~ 改善されてます。(次ページ) ※Temp I/O に対するキャッシュ・ポリシーは、Exadata 12.2.1.1.0 ~改善されています。(次の次ページ) ALTER TABLE <テーブル名> STORAGE (CELL_FLASH_CACHE KEEP) Copyright © 2026, Oracle and/or its affiliates 144
  117. • 大きな表のスキャンに対して、より効率的に Flash へキャッシング • Exadata のソフトウェアは、データベースの表やパーティションへのスキャンを理解し、 キャッシュして効果がある場合に自動的にキャッシュする • 表が大きすぎる、スキャン頻度が低い、管理作業などの場合、

    Flash Cache のスラッシング(内容の入れ替え)は発生しない • スキャンした表が Flash より大きい場合には、表の一部をキャッシュする • スキャンされるのみの表は、手動で “KEEP” する必要がない 【参考】 表スキャン・ワークロードの自動 Flash キャッシング Scan Exadata 11.2.3.3.0 ~ Copyright © 2026, Oracle and/or its affiliates 145
  118. Automatic Loading of KEEP Objects into Exadata Smart Flash Cache

    ALTER TABLE 文を CELL_FLASH_CACHE KEEP 句で実行した場合 • 表データを自動的かつ非同期にフラッシュ・キャッシュにロードし、保持 • 明示的な全表スキャンの実行が不要に • バッファ・キャッシュからのチェックポイント書込みを削減 • DBノードにクエリデータを返さないことで、ネットワーク効率を向上 • 通常は不要で、100%のフラッシュ・キャッシュ・ヒット率を保証したい場合は使用可能 Exadata Flash Cache へのデータベース・オブジェクトのKEEP処理の自動化 Copyright © 2026, Oracle and/or its affiliates 146 SQL> ALTER TABLE LINEITEM STORAGE (CELL_FLASH_CACHE KEEP); Table altered. Elapsed: 00:00:08.59 CellCLI> LIST FLASHCACHECONTENT WHERE OBJECTNUMBER=10000 DETAIL cachedKeepSize: 487711162368 cachedSize: 487711162368 Exadata 24.1.0 ~
  119. Smart Flash Cache を Write 処理でも利用可能となった • Write-Through キャッシュ(読み取り専用)として動作していた Smart

    Flash Cache を、 Write-Back モード(書き込み処理もキャッシュする)で動作させることが可能となった • Database からの Write I/O(DBWR のWrite 処理)を直接 Flash にキャッシュ • 書き込み処理が集中するアプリケーションを高速化 • Write-Back モードでも、Flash Cache の賢いキャッシュポリシーは同様 • 再利用される可能性が低いものはキャッシュされない • 表、Index、パーティションなどに対しては、KEEP 指定をすることが可能 • Write-Back モードでキャッシュされないI/O Exadata Smart Flash Cache (Write-Back モード) Exadata 11.2.3.2.1 ~ • バックアップ、Data Pump I/O • 一時表領域に対する I/O( Exadata 12.2.1.1.0 ~改善) • ダイレクト・パス・インサート(KEEP設定されていないオブジェクト) • テーブル・フルスキャン(KEEP設定されていないオブジェクト) ※テーブル・スキャンに対するキャッシュ・ポリシーは、Exadata 11.2.3.3.0 ~ 改善されてます。 ※Temp I/O に対するキャッシュ・ポリシーは、Exadata 12.2.1.1.0 ~改善されています。 Exadata Storage Server HC モデルではディ スク・グループを高冗長性で構成する場合 Write-Back モードがデフォルト(2017/Apr以 降) Exadata Storage Server EF モデルでは Write-Back モードがデフォルト Copyright © 2026, Oracle and/or its affiliates 147
  120. Write-Through モード時 • Flash Cache は、あくまでもディスクのキャッシュ領域 • 障害発生時など、Flash Cache が利用できない場合には、ディスク上のデータで処理は継続される

    • リブート時には、リブート前に Flash Cache 上にあったデータは使用できなくなるため、再キャッシュ処理が必要 Write-Back モード時 • 永続化された Write キャッシュ(リブート可能)となる • Flash のリカバリが不要なため、クラッシュ・リカバリも高速 • Data Guard の Redo Apply も高速 (Redo Apply は Write I/O に依存するため) • Flash カードの故障は Exadata と ASM により透過的に自動管理 • キャッシュされたコンテンツはミラーされた他の Storage Server のデータを用いてリカバリ • Flash 障害時の、OLTP データのセカンドミラーの Flash デバイスへのプリフェッチや Flash デバイス交換後のプライマリミラーのFlash デバイスへのウォームアップ* Exadata Smart Flash Cache の可用性 * Exadata X6 HC、Exadata 19.1.0 以降 Copyright © 2026, Oracle and/or its affiliates 150
  121. Exadata X9M-2 HC の場合 • CellCLI から create flashcache コマンドにて

    Flash Cache 領域を作成 • 初期セットアップ後には Flash Cache は作成済みの状態になっている。 【参考】 Exadata Smart Flash Cache の構成 Copyright © 2026, Oracle and/or its affiliates 151 CellCLI> create flashcache all Flash cache cell10_FLASHCACHE successfully created [root@cancercel01 ~]# cellcli -e list flashcache detail name: cancercel01_FLASHCACHE cellDisk: FD_00_cancercel01,FD_01_cancercel01,FD_02_cancercel01,FD_03_cancercel01 creationTime: 2022-10-06T10:17:04+09:00 degradedCelldisks: effectiveCacheSize: 23.28692626953125T >> 6.4 TB x 4本分 id: b85c1e2b-02e7-4163-ae65-57831ad70082 size: 23.28692626953125T status: normal [root@cancercel01 ~]#
  122. Exadata X9M-2 EF の場合 • CellCLI から create flashcache コマンドにて

    Flash Cache 領域を作成 • 初期セットアップ後には Flash Cache は作成済みの状態になっている。 【参考】 Exadata Smart Flash Cache の構成 Copyright © 2026, Oracle and/or its affiliates 152 CellCLI> create flashcache all Flash cache cell10_FLASHCACHE successfully created [root@cancercel04 ~]# cellcli -e list flashcache detail name: cancercel04_FLASHCACHE cellDisk: FD_00_cancercel04,FD_01_cancercel04,FD_02_cancercel04,FD_03_cancercel04,FD_04_cancercel 04,FD_05_cancercel04,FD_06_cancercel04,FD_07_cancercel04 creationTime: 2022-10-06T16:18:34+09:00 degradedCelldisks: effectiveCacheSize: 2.3287353515625T >> 6.4 TB x 8本分 x 5% id: 16160053-3dc9-4ccf-9d15-f6ff18c3d165 size: 2.3287353515625T status: normal [root@cancercel04 ~]#
  123. 表領域やデータファイル作成が更に高速化 • 表領域作成やデータファイル追加時の動作変更 • 11.2.3.2 以前 • CELLSRV がディスクに書込み •

    Flash Cache は利用せず • 11.2.3.3 以後 • CELLSRV が Flash Cache に書込み • Write-Back Flash Cache のテクノロジーを利用 (Smart Flash Cache のWrite-Back モード時のみ有効) • 非同期でディスクに書き出される • Storage Server へのオフロードのみならず、Flash Cache を利用す ることにより、高速な書込みを実現 • 機能を利用するための特別なコマンドなどは必要なし 【参考】 Fast Data File Creation Exadata 11.2.3.3.0 ~ ~ 11.2.3.2 11.2.3.3 ~ CELLSRV Database Metadata I/Os in parallel CELLSRV Database Metadata I/O optimized 利用条件 Exadata 11.2.3.3.0 ~ GI / DB: 11.2.0.4 or 12.1.0.1 ~ Copyright © 2026, Oracle and/or its affiliates 153
  124. Exadata I/O レイテンシ制限 (Exadata 11.2.3.3.1~) • 読み込み時に稀に IO レイテンシが大きくなる場合やディスク障害前にまれに IO

    レイテンシが高くなる場合に Storage Server 側で自動的にミラーコピーか ら読み込みをリダイレクトする 書込み操作のための Oracle Exadata System Software の I/O レイテンシ制限 (Exadata 12.1.2.1.0 ~) • 書き込み時に IO レイテンシが高い状態になった場合、同一 Storage Server 内の別の正常な Flash 領域に一時的に Write を実施して ACK を返す。 • Storage Server の Flash Cache の設定が Write-Back モード時のみ有効 • 上記のような一時的な問題で IO レイテンシが一時的に高くなった場合にも Storage Server 側で IO 性能劣化の影響を抑えることが可能になる。 • Grid Infrastructure 11.2.0.4.8, 12.1.0.2 以降 Database Server の I/O レイテンシ制限 (Oracle Database および Grid Infrastructure 12.2.0.1.0 ~) • Database Server と Storage Server との間で I/O レイテンシが高くなる場合、ASM と Exadata System Software は、 読取り I/O のレイテンシが高くなる場合には、読取り I/O 操作を他の Storage Server に自動的にリダイレクトする (これにより Exadata System Software のすべてのリリースでこの機能が利用可能に) 【参考】 Exadata I/O Latency Capping Copyright © 2026, Oracle and/or its affiliates 154 Exadata 11.2.3.3.1 ~ Exadata 12.1.2.1.0 ~ Oracle Database 12.2.0.1.0 ~
  125. • HC モデルでの Write スループットは、 4 枚の Flash カードのスループットのほ うが、12

    本の HDD のスループットより高くなった • DB の Write スループットが HDD のスループットをこえるような時、Smart Flash Cache が書き込みをインテリジェントにキャッシュする • 大量の temp 書き込みを伴うクエリー実施時、Smart Flash Cache は、イン テリジェントに temp IO をキャッシュする • Flash への temp書き込みは実行時間を短縮する • Flash からの temp 読み込みはさらに実行時間を短縮する • Smart Flash Cache が OLTP データのキャッシュを優先度高で実施するのは 変わらず、本機能により OLTP データがキャッシュから追い出されることはな い • Smart Flash Cache は Large Write についても管理するように機能拡張さ れた • Database 11.2.0.4, 12.1.0.2, 12.2.0.1 以降でサポート 【参考】 大量分析問合せおよび大量ロードのパフォーマンス高速化 Flash Cache への 大量の書き込みや、 temp IO をキャッシュ 大容量の Join や Sort データロード処理の高速化 Exadata 12.2.1.1.0 ~ Faster Performance for Large Analytic Queries and Large Loads 非常に書き込みが多い場合や、Temp I/O への Flash Cache 対応 Copyright © 2026, Oracle and/or its affiliates 155
  126. ACFS IO Caching in Flash Cache • ACFSは、IOサイズに関係なく、ハードドライブではなくストレージサーバー・フラッシュ・キャッシュに 書き込むように変更 •

    1MBの書き込みに合体した小さなシーケンシャル書き込み(GoldenGate トレイルファイ ルなど) • ACFS読み取り速度は最大7倍 • Exadata21.2で自動的かつ透過的に実装 • サポートされているすべてのOracleデータベースバージョンで動作 • 既存のIORMプランで動作 フラッシュ・キャッシュでのOracle ACFS I/Oキャッシュ Copyright © 2026, Oracle and/or its affiliates Storage Server Before After 156 ACFS Exadata 21.2 ~
  127. ACFS IO Caching in Flash Cache • I/O効率を最適化するために、Oracle ASM Cluster

    File System(Oracle ACFS)への小さなサイズのシーケンシャル書 き込みは自動的に1MBのチャンクに結合 • Exadata System Software 21.2.0 以降、すべての Oracle ACFS I/O は Exadata Smart Flash Cache でのキャッシュ の対象になる • Exadata System Software 21.2.0 より前は、これらの大きな書き込みはキャッシュをバイパスして直接ディスクに送 信 • Oracle ACFSのパフォーマンスが向上 • 特に、Oracle GoldenGate トレイルファイルなどのアプリケーションのような、小さなシーケンシャル書き込みと、後続の 高速な読み取りが主となるI/Oプロファイルの場合に有効 フラッシュ・キャッシュでのOracle ACFS I/Oキャッシュ Copyright © 2026, Oracle and/or its affiliates 157 Exadata 21.2 ~
  128. Exadataスマート・フラッシュ・キャッシュでのフラッシュバック・ログ書込みのキャッシュ Caching Flashback Log Writes in Exadata Smart Flash Cache

    • 大量分析問合せおよび大量ロードのパフォーマンス高速化(Faster Performance for Large Analytic Queries and Large Loads)を可能にするExadata System Software 12.2.1.1.0で導入された最適化に基づいて、このリリースでは、 フラッシュバック・ログ書込みが自動的にキャッシュされるように • フラッシュバック・データベースのパフォーマンスが大幅に向上 158 Copyright © 2026, Oracle and/or its affiliates Exadata 21.2 ~
  129. 一時データに対するフラッシュ・キャッシュの即時再利用 Immediate Reuse of Flash Cache for Temporary Data 分析クエリーは、一時データ(ソート、結合、集計)を

    ストレージに流出させ、完了後に解放する場合がある Exadataは、クエリの完了後、 このデータをハード・ディスクに保持することなく、 以前のTEMP I/O書込みによって占有されていたフラッシュ領域を独 自に解放 このインスタント・フラッシュ再利用機能により、 ハード・ディスク書込みが不要になり、 多くのRACインスタンスおよびデータベースに問合せワークロードが またがる場合でも、効率的な一時データ・キャッシングが保証される 159 Copyright © 2025, Oracle and/or its affiliates 最大1.6倍の分析問合せの高速化 Database 23ai で 38068007の修正が必要 クエリーが一時データをこぼす 1 一時データは フラッシュ・キャッ シュを使用 2 問合せが完了 一時データはリリースされる ハード・ディスクへの書込みは無し 3 フラッシュ領域の 即時再利用 4 Exadata 25.2 ~
  130. フラッシュ・キャッシュへの重要な大規模書込みの優先度付け Prioritize Critical Large Writes in Flash Cache データベースの最適なパフォーマンスを維持するには、 temp

    I/Oの書込みとflashback logの書込みが重要 Exadataは、フラッシュでのtemp I/O writes、flashback log writes の大規模書き込み(Large Writes)に他の 大規模な書き込みよりも独自に優先順位を付け、ミッ ションクリティカルなワークロードと分析ワークロードを高 速化 リバランスI/Oなどの他の大きな書込みは、 使用可能なフラッシュ容量がある場合にのみキャッシュ される 160 Copyright © 2025, Oracle and/or its affiliates Prioritized for flash caching temp I/O writes flashback log writes other large writes Exadata 25.2 ~
  131. • Exadata Smart Flash Cacheでは、アクセス頻度の高いデータがフラッシュ・ストレージに保持される一方、 ほとんどのデータはコスト効率に優れたディスク・ストレージに保持される • キャッシングは自動的に発生し、ユーザーや管理者による作業は不要 • Exadata

    Smart Flash Cacheでは、データの使用状況、アクセス・パターンおよびアクセスされるデータのタイプを示す データベースからのヒントに基づいて、キャッシュすることが最も有益なデータをインテリジェントに決定 • Exadata Smart Flash Cacheは、ライトスルー・モードまたはライトバック・モード(現在のデフォルト)で動作 • ライトスルー・モードでは、データベース書込みは最初にディスクに対して行われ、その後Flash Cacheに移入される - Exadata Smart Flash Cacheがライトスルー・モードで動作している状態でフラッシュ・デバイスに障害が発生した場合、 データはすでにディスク上にあるため、データが失われることはない • ライトバック・モードでは、データベース書込みは最初にフラッシュ・キャッシュに対して行われ、その後ディスクに対して行われる - ライトバック・フラッシュ・キャッシュの内容は再起動後も保持されるため、キャッシュへの移入に必要なウォームアップ時間が不要になる - 書込み中心のアプリケーションは、フラッシュによって提供される高速レイテンシを利用することで、ライトバック・キャッシュのメリットを得ることが可能 - 同じブロックへの複数の書込みが、ディスクへの書込みの前にキャッシュに吸収された場合にも、ディスクI/Oの量が減少する - ただし、ライトバック・モードの使用中にフラッシュ・デバイスで障害が発生した場合、ディスクにまだ永続化されていないデータは失われるため、 ミラー・コピーからリカバリする必要がありる - このため、データベース・ファイルを保護するために高冗長性(3方向ミラー化)とともにライトバック・モードを使用することを推奨 Exadataスマート・フラッシュ・キャッシュの監視(1) Copyright © 2026, Oracle and/or its affiliates 161
  132. • Exadata Smart Flash Cacheでは、頻繁にアクセスされるデータ・ブロックに高速I/Oを提供することでOLTPパフォーマンスを向上させる 頻繁にスキャンされるデータおよび一時セグメントを自動的にキャッシュし、列キャッシュ・ストレージを提供し、大量分析問合せおよび 大量ロードのパフォーマンスを最適化するその他の機能を有効にすることで、意思決定支援システム(DSS)のパフォーマンスを向上させ る • Extreme

    Flash (EF)ストレージ・サーバーでは、すべてのデータがフラッシュに存在する • 通常のキャッシュにはExadata Smart Flash Cacheは不要 • Exadata Smart Flash Cacheではデータを列形式でキャッシュし、様々な分析問合せを最適化する列キャッシュをホストするために 使用される • Exadata Smart Flash Cacheに関連するパフォーマンスの問題では、通常、データベースでcell single block physical readのレイテンシ が増加する • cell single block physical readに関連して不定期の長いレイテンシがあることは、必ずしもExadata Smart Flash Cacheのパフォー マンスの問題を示すわけではなく、単に読取りリクエストがExadata Smart Flash Cacheを使用して対応されなかったことを示す場 合もある Exadataスマート・フラッシュ・キャッシュの監視(2) Copyright © 2026, Oracle and/or its affiliates 162
  133. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 163 Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ Exadata 12.2.1.1.0 ~
  134. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 164 Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ Exadata 12.2.1.1.0 ~
  135. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics > Flash Cache Configuration / Flash Cache Space Usage 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 165 Smart Flash Cache が各 Storage Server に 24TB Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ 約70%(26+23+21)がOLTPで利用 通常、ブロック・モード読取りを使用 してデータベース・バッファ・キャッシュ に読み込まれるデータ 内26%がCleanな(読み取り後変 更されていない)OLTPデータ 23%が Synced(キャッシュされたOLTPデータが 更新され、更新がプライマリ・ストレージ(通常は ハード・ディスク・ドライブ)に書き込み 22%が Unflashed(キャッシュされたOLTPデータ が更新されても、更新がプライマリ・ストレージに 書き込まれていない) 20%が Large Writes 6%が Scan 2%が 列キャッシュ KEEPは使われてない
  136. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics > Flash Cache User Reads/ Flash Cache User Reads Per Second / Flash Cache User Reads Efficiency 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 166 OLTP - ブロック・リクエスト Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ Scan - スキャン・リクエスト Columnar -列キャッシュ・リクエスト Keep - KEEPプールに対する読取りリクエスト
  137. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics > Flash Cache User Writes 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 167 Write-Backモードでの書き込みリクエスト数(Write Requests) 、スループット(Write Megabytes) Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ First Writes: Flashへの新しいデータ書き込み 追加のフラッシュ・キャッシュ・メタデータの書込みも必要 Overwrites: 上書き Write-BackモードでExadataスマート・フラッシュ・キャッシュを使用することにより回避されたディスク書込みを表す
  138. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics > Flash Cache User Writes - Large Writes / Flash Cache User Writes - Large Writes Rejections 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 168 Write-BackモードでのExadataスマート・フラッシュ・キャッシュによって吸収されたLarge Writes (128KB 以上)リクエストに関する情報が表示 Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ Write-BackモードでのExadataスマート・フラッシュ・キャッシュによって拒否(Rejections) されたLarge Writes (128KB以上)リクエストに関する情報が表示
  139. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics > Flash Cache Internal Reads 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 169 Exadata System Softwareによって実行されるExadataスマート・フラッシュ・キャッシュからの読取り これらの統計は、Exadataスマート・フラッシュ・キャッシュが Write-Back の場合に移入される Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ Disk Writer IO Detail Exadataスマート・フラッシュ・キャッシュからハード・ディスク・デバイスにデータを永続化 するために実行される内部I/O フラッシュからの読取り(Reads from Flash) とハード・ディスクへの様々なカテゴリの書 込み(Writes to Hard Disk) の両方が表示
  140. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache Statistics > Flash Cache Internal Writes 【参考】 AWRを使用したExadata Smart Flash Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 170 Exadata System Softwareによって実行されるExadataスマート・フラッシュ・キャッシュへの書込み Internal Writes は、キャッシュ読取りミスに応じてExadataスマート・フラッシュ・キャッシュに移入(Population)されるI/Oのこと Exadata 12.1.2.1.0 ~ Oracle Database 12.1.0.2 ~ この統計には、Exadataスマート・フラッシュ・キャッシュが Write-Back のときに発生したメ タデータ書込みも含まれる メタデータ書込みは、キャッシュラインを使用して新しいデータをキャッシュするときに発生
  141. Exadataスマート・フラッシュ・キャッシュの監視 【参考】データベース統計を使用したExadataスマート・フラッシュ・キャッシュの監視 Copyright © 2026, Oracle and/or its affiliates 171

    統計 説明 cell flash cache read hits キャッシュで対応された読取りリクエストの数 cell flash cache read hits for smart IO キャッシュで対応されたスマートIOに対する読取りリクエストの数 cell flash cache read hits for temp IO キャッシュで対応された一時IOに対する読取りリクエストの数 cell flash read hits for controlfile reads キャッシュで対応されたデータベース制御ファイルに対する読取りリクエストの数 cell overwrites in flash ディスクに書き込まれていなかったExadataスマート・フラッシュ・キャッシュの既存のキャッシュラインを上書きした書込みリクエストの合計数。 実際には、ライトバック・モードを使用して保存されるディスクI/Oの量。この統計はミラー書込みが1回行われるたびに増分される cell partial writes in flash Exadataスマート・フラッシュ・キャッシュとディスクの両方に書き込まれた書込みリクエストの合計数。 データの一部はフラッシュに書き込まれ、残りはディスクに書き込まれる。この統計はミラー書込みが1回行われるたびに増分される cell writes to flash cache Exadataスマート・フラッシュ・キャッシュに完全に書き込まれた書込みリクエストの合計数。 この統計はミラー書込みが1回行われるたびに増分される cell writes to flash cache for temp IO Exadataスマート・フラッシュ・キャッシュによって吸収された一時セグメントに対する書込みリクエストの数 physical read IO requests データベースによって発行された物理読取りリクエストの数 physical read requests optimized Exadataスマート・フラッシュ・キャッシュを使用して対応された読取りリクエストと、ストレージ索引または列キャッシュを使用することによって 回避された読取りリクエストの合計数 physical read total bytes 読取りがストレージ・サーバーにオフロードされたかどうかに関係なく、データベースによって発行された読取りの合計I/Oバイト数 physical read total bytes optimized Exadataスマート・フラッシュ・キャッシュから読み取られたバイト数と、Storage Indexまたは列キャッシュを使用して回避されたバイト数の合 計 physical read total IO requests すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベースによって発行された 読取りリクエストの合計数 physical write IO requests データベースによって発行された物理書込みリクエストの数 physical write total bytes すべてのアクティビティに対してデータベースによって発行された書込みの合計IOバイト数 physical write total bytes optimized Exadataスマート・フラッシュ・キャッシュに書き込まれた合計バイト数。これらの書込みはレイジー方式でディスクに同期される physical write total IO requests すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベースによって発行された 書込みリクエストの合計数
  142. Exadataスマート・フラッシュ・キャッシュの監視 待機イベント 説明 cell list of blocks physical read この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生。

    これは、リカバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロックを監視 するために使用される V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる • P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる • P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する • P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、セルのdb file parallel readと同等 cell list of blocks read request これはcell list of blocks physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示される。待 機イベントが終了すると、プレースホルダは通常cell list of blocks physical readに変換される cell multiblock physical read (セルの複数ブロックの物理読込み) この待機イベントは、マルチブロック・データベース読取りのすべてのI/Oの実行に要した時間を表す V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる • P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる • P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する • P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、セルのdb file scattered readと同等 cell multiblock read request これはcell multiblock physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示される。待機 イベントが終了すると、プレースホルダは通常cell multiblock physical readに変換される 【参考】待機イベントを使用したExadataスマート・フラッシュ・キャッシュの監視(1) Copyright © 2026, Oracle and/or its affiliates 173
  143. Exadataスマート・フラッシュ・キャッシュの監視 待機イベント 説明 cell single block physical read (セルの単一ブロックの物理読込み) この待機イベントは、単一ブロック・データベースI/Oの実行に要する時間を表す

    V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる • P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる • P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する • P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、セルのdb file sequential readと同等 2022年5月のOracle Databaseリリース更新(バージョン19.15.0.0.220419、21.6.0.0.220419以降)以降では、この待機イベ ントには、Exadata Smart Flash CacheのI/O、PMEM CacheのI/O、またはリモート・ダイレクト・メモリー・アクセス(RDMA)読取 りを使用したデータベースのI/Oが含まれなくなった cell single block physical read: flash cache この待機イベントは、Exadataスマート・フラッシュ・キャッシュから単一ブロック・データベースI/Oの実行に要する時間を表す V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータ(キャッシュの場所ではない)を含むグリッド・ディスクのディスク・ハッシュ番号を識 別する •P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、2022年5月のRUで導入され、Oracle Database 19.15.0.0.220419、21.6.0.0.220419以降に存在する。以前 は、cell single block physical readにこれらの待機が含まれていた。 cell single block read request これはcell single block physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示される。待 機イベントが終了すると、プレースホルダは通常cell single block physical readに変換される cell interconnect retransmit during physical read この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示される。 V$SESSION_WAITビューのP1列のセル・ハッシュ番号は、cell single block physical readおよびcell multiblock physical read で識別されるセルと同じ。P2列には、セルに対するサブネット番号が格納され、P3列には、I/O読取り操作中に処理されたバ イト数が格納される 【参考】待機イベントを使用したExadataスマート・フラッシュ・キャッシュの監視(2) Copyright © 2026, Oracle and/or its affiliates 174
  144. Exadataスマート・フラッシュ・キャッシュの監視 【参考】待機イベントを使用したExadataスマート・フラッシュ・キャッシュの監視 AWRの 例 Copyright © 2026, Oracle and/or its

    affiliates 175 cell single block physical readイベントのレイテンシは、通常、読取りがExadataスマート・フラッシュ・キャッシュで対応されたかどう かを示す レイテンシが長ければ長いほど、リクエストがExadataスマート・フラッシュ・キャッシュで対応されなかった可能性が高くなる Exadataスマート・フラッシュ・キャッシュに関連するパフォーマンスの問題では、通常、データベースで “cell single block physical read”の待機イベントのレイテンシが増加する ただし、”cell single block physical read”に関連して不定期の長いレイテンシがあることは、必ずしもExadataスマート・フラッシュ・ キャッシュのパフォーマンスの問題を示すわけではなく、単に読取りリクエストがExadataスマート・フラッシュ・キャッシュを使用して対 応されなかったことを示す場合がある
  145. LIST FLASHCACHECONTENT を使用したExadataスマート・フラッシュ・キャッシュのキャッシュされたオブジェクトの確認 • LIST FLASHCACHECONTENT • Flash Cache にキャッシュされている

    オブジェクト情報を確認 - cachedKeepSize: このオブジェクトに対してkeepモードでキャッシュされているサイズ (バイト単位) - cachedSize: このオブジェクトに対してキャッシュされているサイズ(バイト単位) - cachedWriteSize: ハード・ディスクにまだ書き込まれていないライトバック・フラッシュ・ キャッシュ内のこのオブジェクトに対してキャッシュされたデータのサイズ(バイト単位) - columnarCacheSize: このオブジェクトに対してハイブリッド列圧縮(HCC)形式でキャッ シュされたサイズ(バイト単位) - columnarKeepSize: このオブジェクトに対してkeepモードのハイブリッド列圧縮(HCC) 形式でキャッシュされたサイズ(バイト単位) - dbID: 一意のデータベース名識別子 - dbUniqueName: データベースの一意の名前 - hitCount: このオブジェクトに対してフラッシュ・キャッシュからデータの読取りを行った I/Oの数。 - hoursToExpiration: このオブジェクトが、再度アクセスされない場合にkeepセクション から降格されるまでの時間 - missCount: このオブジェクトに対してディスクからデータの読取りを行ったI/Oの数 - objectNumber: 通常は、FLASHCACHECONTENTオブジェクトに対応するデータベー ス・セグメントのディクショナリ・オブジェクト番号を指定する。 値4294967293は、対応するFLASHCACHECONTENTオブジェクトにキャッシュ済の REDOログ・データが含まれることを示すために予約されている - tableSpaceNumber: オブジェクト番号の表領域番号。 【参考】 Exadata Smart Flash Cacheの利用状況確認例 Copyright © 2026, Oracle and/or its affiliates 176 CellCLI> list flashcachecontent detail cachedKeepSize: 0 cachedSize: 131072 cachedWriteSize: 131072 columnarCacheSize: 0 columnarKeepSize: 0 dbID: 2977355767 dbUniqueName: CDBM01.PDB01 hitCount: 2 missCount: 0 objectNumber: 4294967295 tableSpaceNumber: 0 <省略> • user_objects 表から DATA_OBJECT_ID を取得、 objectNumber で flashcachecontent を問い合わせ
  146. Exadataスマート・フラッシュ・キャッシュの監視 • objectType=FLASHCACHEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • 関連メトリック(抜粋) 【参考】 Exadataメトリックを使用したExadataスマート・フラッシュ・キャッシュの監視 Copyright © 2026,

    Oracle and/or its affiliates 177 Exadata Smart Flash Cacheの領域は、キャッシュラインと呼ばれるチャンクで内部的に管理 FC_BY_ALLOCATED "Number of megabytes allocated in flash cache" フラッシュ・キャッシュ内のキャッシュラインに割り当てられている領域の量(MB)。値がフラッシュ・キャッシュのサイズに近い場合、フラッシュ・キャッシュが満杯 FC_BY_USED "Number of megabytes used on FlashCache" フラッシュ・キャッシュ内のデータが占有している領域の量(MB) OLTPなどのワークロードについて、OLTP書込みではキャッシュラインのごく一部しか使用されないため、FC_BY_USED値をFC_BY_ALLOCATEDよりもずっと小さい値にすることができる FC_BY_ALLOCATED_OLTP "Number of megabytes allocated for OLTP data in flash cache" OLTPキャッシュラインで使用される合計量 FC_IO_BY_R_DW "Number of megabytes of large reads (DW) from flash cache" FC_IO_BY_R_MISS_DW "Number of megabytes of large reads (DW) from disks because some of the requested data was not in flash cache" FC_IO_RQ_R_DW "Number of large reads (DW) satisfied from the flash cache" FC_IO_RQ_R_MISS_DW "Number of large reads (DW) that did not find all data in flash cache" “_DW” で終わる名前を持つ様々なフラッシュ・キャッシュ・メトリックは、大規模な読取り操作を追跡 これらの操作は通常、データ・ウェアハウス(DW)・ワークロードに関連付けられる これらの各メトリックには、通常OLTP操作に関連付けられている小規模の読取り操作を追跡する対応するメトリックがある 合計数を取得するには、大きい読取りメトリック値を対応する小さい読取りメトリック値に追加 (例:フラッシュ・キャッシュで対応された読取りの合計数を取得するには、FC_IO_RQ_R_DWをFC_IO_RQ_Rに追加 CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE=FLASHCACHE
  147. 読取りレイテンシが増加した場合 • Exadataスマート・フラッシュ・キャッシュに関連して発生する可能性のある問題は、 特にcell single block physical read待機イベントで、データベースの読取りレイテンシの増加として示される傾向がある。 通常、レイテンシが増加するのは、読取りがExadataスマート・フラッシュ・キャッシュで対応されず、ハード・ディスクに対して発行された場合に発生する •

    次の場合は、読取りリクエストがExadataスマート・フラッシュ・キャッシュで対応されないことがある • 必要なデータがExadataスマート・フラッシュ・キャッシュにない場合 - リクエストはフラッシュ・キャッシュ・ミスとして記録され、AWRレポートの” Flash Cache User Reads” セクションにミスの増加(Flash Cache User Reads Efficiency)として示 される。通常、フラッシュへの移入書込みも増加し、AWRレポートの” Flash Cache Internal Writes” セクションで示される データベースでは、physical read IO requestsまたはphysical read total IO requestsと比較して、cell flash cache read hitsの数が減少する場合がある • そのデータがExadataスマート・フラッシュ・キャッシュの対象でない場合 - キャッシュ効率を最大化するため、I/Oリクエストがデータベースからストレージ・サーバーに送信されるとき、データをExadataスマート・フラッシュ・キャッシュに キャッシュする必要があるかどうかを示すヒントが含めることができる。 データがキャッシングの対象でない場合は、AWRレポートの” Flash Cache User Reads - Skips” セクションに、対応するI/Oと、読取りが対象でなかった理由が表示 考えられる理由 • グリッド・ディスクのキャッシング・ポリシーがnoneに設定されている場合 • データベース・セグメントが、CELL_FLASH_CACHE NONEのSTORAGE句を使用して構成されている場合 - 例: ALTER TABLE テーブル名 STORAGE(CELL_FLASH_CACHE NONE); • I/Oタイプおよび状況によって、キャッシュが妨げられている場合。 - 例:I/OがRMANバックアップ操作に関連し、かつ、ハード・ディスクがビジーでないためなど。このことが発生する頻度が高い場合は、AWRレポートの” Top IO Reasons” セクションからわかる • 場合によっては、Exadataスマート・フラッシュ・キャッシュの動作に明らかな違いがなくても、cell single block physical readのレイテンシが増加することがある。 これは、特にハード・ディスクでのI/O負荷の増加が原因である可能性がある • cell single block physical readで不定期の長いレイテンシがある(通常はcell single block physical readヒストグラムにロング・テールとして表示される)こと は、必ずしもExadataスマート・フラッシュ・キャッシュの問題を示すわけではなく、単にデータがハード・ディスクから読み取られたことを示すことがある 【参考】 Exadataスマート・フラッシュ・キャッシュを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 178
  148. Skipped Writes が発生する場合 • Write-Back モードでExadataスマート・フラッシュ・キャッシュを使用している場合、ほとんどのデータベース書込みリクエストはキャッシュによって吸収される。た だし、一部の書込みリクエストではキャッシュへの書き込みをスキップする場合がある • 一時ソートなどのために1回のみ読み取られる大量のデータがリクエストによって書き込まれた場合 •

    バックアップやアーカイブなど、将来予測できる範囲で読取りが発生しないことが想定される場合 • Large Writes をスキップする一般的な理由として、Disk Not Busyもある。これは、通常、ハード・ディスクには書込みリクエストを処理するための十分な容 量があるため、Exadataスマート・フラッシュ・キャッシュを使用するメリットがないことを意味する • Large Writes でExadataスマート・フラッシュ・キャッシュをスキップすることでパフォーマンスの問題が発生する場合は、 通常、データベースの direct path write 待機イベント、または direct path write temp 待機イベントの対応するレイテンシが長くなることから分かる • Large Writes を拒否した理由は、AWRレポートの” Flash Cache User Writes - Large Write Rejections” セクションに表示される 【参考】 Exadataスマート・フラッシュ・キャッシュを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 179
  149. データベース・ワーキング・セット・サイズ • 「データベース・ワーキング・セット」とは、データベース内で最も一般的にアクセスされる情報のサブセットを指す。 ほとんどの場合、データベース・ワーキング・セットはかなり安定している。 なんらかの理由でワーキング・セットがExadataスマート・フラッシュ・キャッシュに収まらない場合、次の症状が示されることがある • キャッシュ・ミスの増加 - データがExadataスマート・フラッシュ・キャッシュにないことを示す -

    AWRレポートの ”Flash Cache User Reads” セクション(Flash Cache User Reads Efficiency)、またはFC_IO_RQ_R_MISS_SECセル・メトリックに示される • Exadataスマート・フラッシュ・キャッシュにないデータを移入する移入アクティビティの増加 - AWRレポートの “Flash Cache Internal Writes” セクション(Population) 、またはFC_IO_[BY|RQ]_W_POPULATE_SECセル・メトリック • Disk Writer アクティビティの増加 - キャッシュラインを再利用して他のデータをキャッシュできるように、ダーティ・キャッシュラインをディスクに書き込む必要があることを示す。 - AWRレポートの” Flash Cache Internal Reads” セクション(Disk Writer IO Detail)、またはFC_IO_[RQ|BY]_[R|W]_DISK_WRITER_SECセル・メトリック • First Writes の増加 - 新しいデータがExadataスマート・フラッシュ・キャッシュに書き込まれていることを示す。 First Writes が多数ありOverwrites がほとんどない場合は、新しいデータがExadataスマート・フラッシュ・キャッシュに書き込まれていることを意味する - AWRレポートの” Flash Cache User Writes” セクション、またはFC_IO_[RQ|BY]_W_FIRST_SECセル・メトリック • 対応 • データベース・アクセス・パターンを確認して、アクセスされるデータの量を減らすチューニングの機会を見つける • Exadataスマート・フラッシュ・キャッシュ用の領域を増やすために、使用可能なストレージ・サーバーの数を増やす • Exadataスマート・フラッシュ・キャッシュのI/Oリソース管理(IORM)割当て制限を確認し、最も必要な場所に領域を割り当てる • Extreme Flashストレージ・サーバーを使用してディスクI/Oを排除することを検討する 【参考】 Exadataスマート・フラッシュ・キャッシュを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 180
  150. その他の問題 • cell single block physical readのレイテンシの増加は、セルのパフォーマンスによるものではなく、 ネットワークの競合やデータベース・サーバーのCPUリソースの競合など、IOパスにおける別のものが原因である場合がある • cell

    single block physical read のヒストグラム、および Small Reads Histogram は、AWRレポートの Exadata Statistics > Performance Summary セクショ ンの 「Single Block Reads」 セクション、 「Small Read Histogram - Detail」 セクションにある。 「cell single block physical read」 ヒストグラムはOracle Databaseによって測定されたレイテンシを示し、 「Small Read Histogram」 はストレージ・サーバーで測定されたレイテンシを示す。 • 不定期の長いレイテンシが多数あるヒストグラムは、ロング・テールがあると言わる。 cell single block physical readおよびSmall Read Histogram にロング・テールがある場合は、ストレージ・サーバーの読取りが低速であることを示すため、 他のI/Oパフォーマンス統計をさらに調査する必要がある。セル・ディスクI/Oの監視を参照 • cell single block physical readヒストグラムに、Small Read Histogram には存在しないロング・テールがある場合は、 通常、ストレージ・サーバーではなく、ネットワークのボトルネックやコンピュート・ノードのCPUの競合など、I/Oパスにおける別のものが原因と考えられる 【参考】 Exadataスマート・フラッシュ・キャッシュを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 181
  151. Smart OLTP:XRMEM Cache • Exadata RDMA Memory (XRMEM) Data Accelerator

    • Exadata XRMEM Cacheの監視 • AWRを使用したXRMEM Cacheの監視 • データベース統計を使用したXRMEM Cacheの監 視 • 待機イベントを使用したXRMEM Cacheの監視 • Exadataメトリックを使用したXRMEM Cacheの監 視 • XRMEMキャッシュを監視する際の注意事項
  152. Exadata RDMA Memory (XRMEM) Data Accelerator Unique: shared memory optimized

    for Oracle Database • Exadata Storage Serversは、フラッシュ・メモリーの前に XRMEM Data Acceleratorを透過的に追加 • Exadata X9Mと比較して1秒当たり21%高いI/O: 2,520万IOPS • データベースは、通常のI/OのかわりにRDMA I/Oを使用して リモートXRMEMを読み取り • ネットワーク、I/Oソフトウェア、割り込み、コンテキスト・スイッチをバイパス • Exadata X7と比較してレイテンシが17倍改善: 8KBデータベースの読取りではレイテンシーが14マイクロ秒まで短縮 • XRMEMはデータベース全体で自動的に階層化および共有 • 最もホットなデータのキャッシュとして使用することで、 有効容量が10倍向上 • キャッシュ・データは、フォルト・トレランスのためにStorage Server間で 自動的にミラー化 Enabled with Oracle Database 19c and newer Database Server Hot XRMEM Cold Disk Warm Flash Cache Storage Server RoCE / RDMA Copyright © 2026, Oracle and/or its affiliates | 185 Exadata 23.1.0 ~ Exadata X10M ~ Oracle Database 19c ~
  153. Exadata X8M-2 HC 【参考】 Exadata XRMEM Cache の構成 Copyright ©

    2026, Oracle and/or its affiliates 188 [root@geminicel01 ~]# cellcli -e list xrmemcache detail name: geminicel01_PMEMCACHE cellDisk: PM_00_geminicel01,PM_01_geminicel01,PM_02_geminicel01,PM_03_geminicel01,PM_04_geminic el01,PM_05_geminicel01,PM_06_geminicel01,PM_07_geminicel01,PM_08_geminicel01,PM_09_ge minicel01,PM_10_geminicel01,PM_11_geminicel01 creationTime: 2024-11-27T11:35:51+09:00 degradedCelldisks: effectiveCacheSize: 1.465576171875T id: fea32d30-0d53-4712-bc25-de7fd8e3e8d9 size: 1.465576171875T status: normal [root@geminicel01 ~]#
  154. • データベース・クライアントがXRMEMキャッシュから読み取ると、クライアント・ソフトウェアはキャッシュされたデータのRDMA読取りを実行。 ストレージ・サーバー・ソフトウェアがバイパスされ、読取りレイテンシが大幅に短縮 • XRMEMキャッシュは、Exadataスマート・フラッシュ・キャッシュと連携 • 使用可能な場合は、XRMEMキャッシュにないデータをExadataスマート・フラッシュ・キャッシュから取得。 • 同様に、XRMEMキャッシュからスマート・フラッシュ・キャッシュにデータが書き出されると、ライトバック・モードの使用時(現在のデ フォルト)にExadataスマート・フラッシュ・キャッシュに書き込む

    • XRMEMキャッシュの統計 • Exadataの他の統計とは異なり、クライアントはRDMA I/OをPMEMキャッシュに直接発行するため、リクエストはcellsrvに送信され ず、ストレージ・サーバーはRDMA I/Oを考慮できない • このため、XRMEMキャッシュのI/Oのセル・メトリックは無い • かわりに、Oracle Databaseの統計ではRDMAを使用して実行されるI/Oが考慮される • XRMEMキャッシュに関連するパフォーマンスの問題により、通常、Oracle Databaseのcell single block physical read待機イベントのレ イテンシが増加する。 • ただし、それでもExadataスマート・フラッシュ・キャッシュを使用してリクエストを処理できること、および Exadataスマート・フラッシュ・キャッシュからのリクエストは一般的にPMEMキャッシュに比べて読取りレイテンシが長くなるものの、 リクエストはフラッシュによって提供される高速I/Oのメリットを得られることに留意すること 【参考】 Exadata XRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 190
  155. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Performance Summary > 続く 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 191
  156. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Performance Summary > Single Block Reads > Database IOs 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 192 ストレージ・サーバーはRDMA I/Oを考慮できないため、XRMEMキャッシュの使用状況 を把握するにはOracle Database統計が重要
  157. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Performance Summary > Single Block Reads > Database IOs 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 193 ②cell RDMA reads(XRMEM Cacheからの読み込み)が ①physical read total IO requests(読み込みIO全体) の 88% ③cell xrmem cache read hits(non-RDMA XRMEM Cacheからの読み込み)(①-②-④) ④cell flash cache read hits が残りの Smart Flash Cache からの読み込(①-②-③) ①physical read total IO requests(読み込みIO全体) ① ② ③ ④
  158. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > XRMEM Cache 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 194 AWRレポートのExadata固有のセクションのXRMEM Cache には、cellsrvによって処理 されるI/O (RDMA I/Oではない)のみが含まれる
  159. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > XRMEM Cache > XRMEM Cache Configuration 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 195 ライトスルー(デフォルト) サイズ 1,255.12 GB
  160. 【参考】 AWRを使用したXRMEM Cacheの監視 AWR Report > Exadata Configuration and Statistics

    > Exadata Statistics > Exadata Smart Statistics > XRMEM Cache > XRMEM Cache Space Usage 196 Copyright © 2026, Oracle and/or its affiliates 2.36 TBが10台にまたがって利用中 90%以上が columnar cache
  161. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > XRMEM Cache > XRMEM Cache User Reads 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 197 ストレージ・サーバーはRDMA I/Oを考慮できないため、統計はcellsrvによって処理される非RDMA読取りにのみ関連 Hits:XRMEMキャッシュを使用して対応されたI/Oに対するもの Misses :データがXRMEMキャッシュになかったこと
  162. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > XRMEM Cache > XRMEM Cache Internal Writes 【参考】 AWRを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 198 Oracle Exadata System Softwareによって実行されるXRMEMキャッシュへの書込みが表示 Internal Writes は XRMEMキャッシュに移入するI/Oのこと
  163. Exadata XRMEM Cacheの監視 統計 説明 cell RDMA reads RDMAを使用して成功したXRMEMキャッシュ読取りリクエスト数 cell

    RDMA reads eligible RDMAの基本的な適格基準を満たすデータベース読取り数 cell RDMA read hash table probes XRMEMキャッシュでのデータの存在を判断するために発行されたRDMAハッシュ表プローブ合計数。通常、適格 な各読取りはハッシュ表プローブに関連付けられる cell RDMA reads issued XRMEMキャッシュからデータを取得するために発行されたRDMA読取り合計数。 通常、RDMA読取りはハッシュ表プローブが成功するたびに発行される cell RDMA probe failures - hash table buffer allocation failed cell RDMA probe failures - IPCDAT metadata allocation failed cell RDMA probe failures - IPCDAT errors 失敗したRDMAハッシュ表プローブ合計数。各統計は、特定の障害理由をカバーする これらの障害合計は、ほとんどがcell RDMA read hash table probesとcell RDMA reads issuedの違い によるもの XRMEMキャッシュ初期化中のいくつかのRDMAハッシュ表プローブの障害は正常。ただし、頻繁に発生する障害 や多数の障害は、さらに調査が必要な問題を示している可能性がある cell RDMA read failures - lease expired cell RDMA read failures - client registration errors 失敗したRDMA読取り合計数。各統計は、特定の障害理由をカバーする これらの障害合計は、ほとんどがcell RDMA reads issuedとcell RDMA readsの違いによるもの 通常、いくつかのRDMA読取り障害が発生することがあります。ただし、頻繁に発生する障害や多数の障害は、さ らに調査が必要な問題を示している可能性がある cell RDMA reads rejected - ineligible RDMAの基本的な適格基準を満たさないデータベース読取り数 cell xrmem cache read hits XRMEMキャッシュ・ヒットが発生するcellsrvによって処理された非RDMA読取りリクエストの数 【参考】データベース統計を使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 199
  164. Exadata XRMEM Cacheの監視 待機イベント 説明 cell list of blocks physical

    read この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生。これは、リ カバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロックを監視するため に使用される V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる • P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる • P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する • P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、セルのdb file parallel readと同等 cell list of blocks read request これはcell list of blocks physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示される。待 機イベントが終了すると、プレースホルダは通常cell list of blocks physical readに変換される。 cell multiblock physical read (セルの複数ブロックの物理読込み) この待機時間は、複数のデータ・ブロックを読み取るときに、すべてのI/Oを実行するのに実際にかかる時間。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる • P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる • P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する • P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、セルのdb file scattered readと同等 cell multiblock read request これはcell multiblock physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示される。待機 イベントが終了すると、プレースホルダは通常cell multiblock physical readに変換される 【参考】待機イベントを使用したXRMEM Cacheの監視(1) Copyright © 2026, Oracle and/or its affiliates 202
  165. Exadata XRMEM Cacheの監視 待機イベント 説明 cell single block physical read

    (Storage Serverの単一ブロックの物理読込み) この待機イベントは、単一ブロック・データベースI/Oの実行に要する時間を表す。 この待機イベントには、Exadataスマート・フラッシュ・キャッシュからのI/O、XRMEMキャッシュからのI/O、またはリモート・ダイレクト・メモ リー・アクセス(RDMA)読取りを使用したデータベースI/Oは含まれない V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれまる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、Storage Serverのdb file sequential readと同等。 cell single block physical read: RDMA この待機イベントは、リモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用して単一ブロック・データベースI/Oの実行 に要する時間を表す V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれまる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する この待機イベントは、2022年5月のOracle Databaseリリース更新で導入され、Oracle Databaseバージョン 19.15.0.0.220419、21.6.0.0.220419以降に存在します。以前は、cell single block physical readにこれらの待機が含ま れていた cell single block physical read: xrmem cache この待機イベントは、PMEMキャッシュから単一ブロック・データベースI/Oの実行に要する時間を表す。 XRMEMキャッシュを効果的に使用すると、この待機イベントのレイテンシが非常に短くなる。これは、RDMAを使用する操作では一般 的 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータ(キャッシュの場所ではない)を含むグリッド・ディスクのディスク・ハッシュ番号を識 別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 【参考】待機イベントを使用したXRMEM Cacheの監視(2) Copyright © 2026, Oracle and/or its affiliates 203
  166. Exadata XRMEM Cacheの監視 待機イベント 説明 cell single block read request

    これはcell single block physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示される。待 機イベントが終了すると、プレースホルダは通常cell single block physical readに変換される cell interconnect retransmit during physical read この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示される。V$SESSION_WAIT ビューのP1列のセル・ハッシュ番号は、cell single block physical readおよびcell multiblock physical readで識別されるセル と同じ。P2列には、セルに対するサブネット番号が格納され、P3列には、I/O読取り操作中に処理されたバイト数が格納され る 【参考】待機イベントを使用したXRMEM Cacheの監視(3) Copyright © 2026, Oracle and/or its affiliates 204
  167. Exadata XRMEM Cacheの監視 • objectType=XRMEMCACHEであるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • XRMEMキャッシュからの読取りは主にOracle DatabaseからのRDMAコールを使用して実行されるため、XRMEMキャッシュI/Oを集計す るExadataメトリックはない •

    XRM_BY_ALLOCATED メトリック • XRMEMキャッシュに割り当てられているMB数を表し、XRMEMキャッシュで使用されているキャッシュラインの数を追跡する • 値がXRMEMキャッシュのサイズに近い場合、XRMEMキャッシュは満杯なことを示す • このメトリックは、データベースごと(DB_XRM_BY_ALLOCATED)およびPDBごと(PDB_XRM_BY_ALLOCATED)に使用することも可能 【参考】 Exadataメトリックを使用したXRMEM Cacheの監視 Copyright © 2026, Oracle and/or its affiliates 205 CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = XRMEMCACHE XRM_BY_ALLOCATED "Number of megabytes allocated in XRMEM cache"
  168. Non-RDMA Reads • XRMEMキャッシュは、RDMAとともに使用すると最も効果的である。 ただし、それでも、様々な状況において、cellsrvへのリクエストがXRMEMキャッシュを使用して対応される場合がある。 このような場合、関連付けられた読取りは、cell RDMA readsではなくcell xrmem cache

    read hitsとして表示される • 非RDMA読取り(Non-RDMA Reads)は、次の理由で発生する • 読み取られるデータのタイプによっては、Oracle DatabaseがRDMA読取りを実行できない場合がある。 - 例として、Direct reads およびOracle Database制御ファイルからの読取りがある。 • 原因を特定するには、他の統計または待機イベントと相互に関連付ける必要がある場合がある • 制御ファイルに対する重要なアクティビティは、通常、control file sequential read待機イベントが伴うか、 ないしは、AWRレポートの IOStat by Filetype summary セクションに示される • Oracle Databaseクライアントで、バッファがRDMAに登録されていない可能性がある。 - これは通常、クライアント・プロセスの開始直後またはPMEMキャッシュへの移入中に発生する • XRMEMキャッシュ内で、RDMAハッシュ・テーブルに必要なメタデータが含まれていない可能性がある (または無効としてマークされている可能性がある)。 - これは通常、XRMEMキャッシュへの移入中に発生する • RDMA読取りは、デフォルトのリース時間(20ミリ秒)を超えるとタイムアウトする • メモリーの制限により、RDMAに必要なメモリー構造を作成できない場合 • RDMA読取りエラーが発生した場合 【参考】 XRMEMキャッシュを監視する際の注意事項(2) Copyright © 2026, Oracle and/or its affiliates 207
  169. Smart Analytics: Smart Flash Cache – Columnar Cache • Columnar

    Cache • Columnar Caching – (CC1) Pure Columnar Format • Columnar Caching – (CC2) In-Memory Columnar Format • Exadata の In-Memory 対応 • CellMemory_LEVEL • In-Memory Columnar Caching を使用するための設 定、条件 • Columnar Cacheの機能拡張 • 列レベルのチェックサムを使用したスマート・スキャン の高速化 • スマート集計 • 高速なインメモリー列指向キャッシュ作成 • 永続列キャッシュ • Exadata RDMAメモリー(XRMEM)の列キャッシュ • インメモリー列指向の高速JSON問合せ • 透過的階層間スキャン • Exadata Columnar Cacheの利用状況確認例 • 列キャッシュが期待どおりに実行されない 209 Copyright © 2026, Oracle and/or its affiliates
  170. 2 つのタイプの Columnar Cache • (CC1) EHCC (Exdata Hybrid Columnar

    Compression) Columnar Format (Pure Columnar Format とも呼ばれる) • Exadata System Software 12.1.2.1 より利用可能 • (CC2) In-Memory Columnar Format • Exadata System Software 12.2.1.1 より HCC テーブルに対して利用可能 • Exadata System Software 18.1.0 より 非圧縮および OLTP 圧縮のテーブルについても利用可能 • Oracle Database In-Memory オプション・ライセンスが必要 • これらはすべて Read I/O 向けのキャッシュ機能 • 対象の表がスキャンされると Pure Columnar Format および In-Memory Columnar Format で Flash Cache にポピュレート Columnar Cache Copyright © 2026, Oracle and/or its affiliates 210 Exadata 12.1.2.1.0 ~ Exadata 12.2.1.1.0 ~ Exadata 18.1.0 ~
  171. • 分析処理、OLTP 処理にバランスのとれた Hybrid Columnar Compression (HCC) • 10倍の圧縮率、分析処理の読み込み高速化、単体のOLTP I/O

    にも対応 • Smart Flash Cache が HCC に最適化され、分析処理が高速化 • 分析処理用の HCC データが、Smart Flash Cache に Pure Columnar 形式でロードされる • 列単位で物理 I/O が可能となり、分析処理の I/O 処理が 最適化 • OLTP 処理時には、従来どおりの HCC 形式でロードされる • 完全に自動的かつ透過的に実施される • Exadata 12.1.2.1.0 / Oracle Database 12.1.0.2 での新機能 • デフォルトで有効 Columnar Caching – (CC1) Pure Columnar Format Exadata 12.1.2.1.0 ~ Hybrid Columnar Data Flash Cache Population Up to 5X Analytic Query Speedup Pure Columnar Data Flash Copyright © 2026, Oracle and/or its affiliates 211 Oracle Database 12.1.0.2~
  172. Exadata は Flash Cache 上で、自動的に表データを In-Memory カラムフォーマットに変換 • 背景 •

    Flashの速度が高速化、Smart Scan の述語評価の際に Storage Server の CPU ボトルネックが発生 • Storage Server の CPU負荷を減らすことが必要 • ソリューション • DBIMのIMC(In-Memory Columnar)フォーマットは述語評価を高速に実施可能 • Storage Server で IMCフォーマットを使えるようにすることでStorage ServerのCPU負荷を下げることが可能 • 実装のメリット • Storage Server のFlash Cache 内のデータのクエリに対して、高速ベクター演算アルゴリズムが利用可能に • Hybrid Columnar Compression よりも高速な圧縮データの解凍速度 • ディクショナリを参照して不要な行の処理を回避 • Smart Scan の結果は In-Memory カラムフォーマットでデータベースへ返される • Database サーバーの CPU 使用率を低減 • HCC 表(Exadata 12.2.1.1.0~)に加えて、OLTP 圧縮および非圧縮の表をサポート (Exadata 18.1.0 ~) • Database 12.1.0.2, Database 12.2.0.1 でサポート • DB初期化パラメータ INMEMORY_SIZE を 0 より大きい値の設定で自動有効化 • DB 19.8 以降で INMEMORY_SIZE = 0 でも利用可能に(次ページ) • ALTER TABLE テーブル名 CELLMEMORY パラメーターでテーブルを明示的にIMCC でFlash Cache にポピュレートすることも可能(明 示的に指定しなくても状況を見てFlashへポピュレートされる) • ADW(Autonomous Data Warehouse) で利用されている Columnar Caching – (CC2) In-Memory Columnar Format In-Memory Columnar scans In-Flash Columnar scans Exadata 12.2.1.1.0 ~ Copyright © 2026, Oracle and/or its affiliates 212 Oracle Database In-Memoryオプションが必要 Exadata 18.1.0 ~ Oracle Database 12.2~
  173. Exadata の In-Memory 対応 Exadata の In-Memory 対応 Exadata Storage

    Server インメモリ・ カラム・ストア インメモリ・ カラム・ストア Flash Cache 表 参照頻度の非常に高いテーブルは、 SGA 内のインメモリ・カラム・ストアに置 く(従来通りのチューニングを実施) 参照頻度は高くないテーブルについて (管理者が明示的に ALTER TABLE INMEMORY 属性を付与していない場 合)でも、 Exadata では自動的に Exadata Storage Server Flash Cache にIn-Memory形式でポピュレート、従 来よりも Smart Scan が高速に! In-Memory 機能のメリット(必要なカ ラムにのみアクセス、SIMD を使った高 速アクセス、Storage Index 等)はサ ポートされる 参照頻度 高 参照頻度 低 参照頻度 高 Database Server Copyright © 2026, Oracle and/or its affiliates 213 Exadata 12.2.1.1.0 ~ Oracle Database In-Memoryオプションが必要 Exadata 18.1.0 ~
  174. Exadata では In-Memory 機能を Database および Storage Server の両方 で使用可能

    Table Access storage Full 全表走査 2. 効果的な圧縮技術により、 圧縮した状態で検索が可能 (ディクショナリ圧縮) 1. 必要なカラムのみアクセス Min 1 Max 3 Min 4 Max 7 Min 8 Max 12 Min 13 Max 15 ベクター・レジスタ 複数の データを ロード 一度の命令で 全ての値を ベクター演算 CPU CA CA CA CA 3. インメモリ・ストレージ索引により、 最小限のIMCUのみスキャン 4. 最新のプロセッサで搭載されている SIMD により高速スキャン (ベクター・スキャン) データ読込み (Smart Scan) フィルタリング Copyright © 2026, Oracle and/or its affiliates 214
  175. CellMemory レベル • CellMemory 機能とは? • Exadataスマート・フラッシュ・キャッシュを使用して、 インメモリー列形式でデータをスマート・フラッシュ・キャッシュ上に移入できるExadata機能 (In-Memory Columnar

    Caching on Storage Servers) • Smart Scan(FULL SCAN)時にFlash Cache上にDBIM形式でポピュレート • メリット • CellMemory 機能の利用に、従来はDB-IM列ストアを利用しない場合でもDB-IM列ストアを有 効化する必要があった。 • DB RU 19.8 からDB-IM列ストアを有効化しなくても CellMemory 機能のみを使用可能に (DB-IM列ストアは有効化されないが、クエリで CellMemory を使用してオブジェクトをスキャン可 能) - DB-IMのオーバーヘッドを避けることが可能に • 機能概要/設定方法 • Oracle Database In-Memoryオプションのライセンスを所有している場合に使用可能 • インメモリ列ストアを有効にすることなく CellMemory 機能を利用可能に (すべてのDBIMデータ型がExadata Flash Cache上で利用可能に) - INMEMORY_FORCE=CELLMEMORY_LEVEL とINMEMORY_SIZE=0 を設定 • 0より大きいとINMEMORY_FORCE=DEFAULT と同じ動作になる - In-Memory Base Level 利用時( INMEMORY_FORCE=BASE_LEVEL )は CELLMEMORY 利用不可 In-Memory Columnar Caching Copyright © 2026, Oracle and/or its affiliates 215 In-Memory Columnar scans In-Flash Columnar scans Up to 25.6 TB Flash per Server Oracle Database In-Memoryオプションが必要 Oracle Database 19.8 ~
  176. • 初期化パラメータ INMEMORY_SIZE を 0 より大きい値に設定 ないしは 初期化パラメータ INMEMORY_FORCE =

    CELLMEMORY_LEVEL • データベース・インスタンスに専用のインメモリ・キャッシュがない場合 (INMEMORY_SIZE = 0) でも、 Flash Cache 上に In-Memory Columnar Caching させることが可能に • Oracle Database 19.8.0.0.200714 より利用可能 • 非圧縮の表、OLTP 圧縮の表 および HCC 表を対象に、ある一定回数のスキャンが実行されると、 自動的に IMCU 形式で Flash Cache へバックグラウンドでポピュレートされる • 圧縮タイプは以下の 2 パターン • MEMCOMPRESS FOR CAPACITY (圧縮率:高、クエリー性能:低(HCCより良好)) デフォルト • MEMCOMPRESS FOR QUERY (圧縮率:低、クエリー性能:高) • 特定の表に対してIn-Memory Columnar Caching (CELLMEMORY)のデフォルトの動作を変更する場合 • 圧縮タイプを QUERY に変更する場合の例 • In-Memory Columnar Caching をさせたくない表がある場合の例 In-Memory Columnar Caching を使用するための設定、条件 SQL> ALTER TABLE table_name CELLMEMORY MEMCOMPRESS FOR QUERY; SQL> ALTER TABLE table_name NO CELLMEMORY Copyright © 2026, Oracle and/or its affiliates 216
  177. Faster Smart Scans Using Column-level Checksum • 従来 • 読取り後にフラッシュ上のブロックでチェックサムを計算

    • このブロックには複数の列が含まれるが、アクセスするのは対象行のみなので、不要な列もチェックサ ム計算が必要 • Exadata 19.1.0~ • Flash 上 IMCU データのチェックサムを カラム圧縮ユニットのヘッダに含む • Storage Server の CPU 使用率を最大 28% 低減 • 選択的なチェックサム計算(Selective checksum computation) - select temperature from weather where city = 'NASHUA' and weather = 'SNOW' and weather_date between '01-JUN-18' and '30-DEC-18'; - チェックサムは、表に多くの他のカラムが含まれていても、 temperature、city、weather、weather_date 列のみを計算 • Just in timeのチェックサム計算(Just in time checksum computation) - select temperature from weather where city = 'REDWOOD CITY' and weather = 'SNOW' and weather_date between '01-JUN-18' and '30-DEC-18'; - city = ‘REDWOOD CITY’ and weather = ‘SNOW’ に結果が返されない場合、 weather_date と temperature に対するチェックサムはスキップされる • 完全に自動で透過的 列レベルのチェックサムを使用したスマート・スキャンの高速化 217 In-Memory Columnar scans In-Flash Columnar scans Exadata 19.1.0 ~ Oracle Database In-Memoryオプションが必要 Copyright © 2026, Oracle and/or its affiliates
  178. Faster Encrypted Table Smart Scans • インメモリー列形式で格納されている暗号化表のスキャンが、 必要となった時点で必要なカラムのみを復号処理 • キャッシュ上に多数のカラムがあっても処理対象となるカラムだけを復号

    (フラッシュキャッシュのキャッシュライン全体は復号されない) • 最初の述語が何も返さなかった場合、二番目以降の述語にはアクセスしな い • select ename from emp where job like ‘%VP’ and sal + bonus > 500000; - 取り出されるカラム (ename) と一つ以上の述語カラムは復号される (キャッシュライン全体の復号ではない) - “VP”を持たない “sal” のデータ区画へのアクセスはしない • 最大 30% 高速な暗号化データの Smart Scan と Storage Server の CPU 利用率の低減 高速暗号化表の Smart Scan Exadata 19.3.0 ~ ename John Joe Jane Mary job Staff Staff Sr. Staff Sr. Staff sal 120k 230k 440k 380k job Staff Staff Sr. Staff Sr. Staff Encrypted Decrypted Scan Copyright © 2026, Oracle and/or its affiliates 218 Oracle Database In-Memoryオプションが必要
  179. Smart Aggregation • SUM関数 と GROUP BY 関数の操作が In-Memory カラムナー・フォーマット

    でSmart Scan が利用可能に • 並列処理度が低いSQL文で効果 • 実行例 - select dept, sum(sal) from emp where country=‘USA’ group by dept; - SUM と GROUP BY 操作は Storage Server で実行される • メリット • Database Server に送られるデータ量を削減 • Database Server の CPU 使用率を改善 • 最大 2 倍高速なクエリ • Oracle Database 18c 以降が必要 スマート集計 Exadata 19.3.0 ~ sum(sal) 380K 560K dept Engr Sales dept Sales Engr Sales Engr country USA UK USA USA sal 120k 230k 440k 380k Scan Copyright © 2026, Oracle and/or its affiliates 219 Oracle Database In-Memoryオプションが必要 Database 18c ~
  180. Fast In-Memory Columnar Cache Creation • インメモリー・データベース形式の列指向キャッシュは、データがハード・ディスク から読み取られたときに作成され、ハイブリッド列形式で格納される • この機能では、フラッシュ・キャッシュから中間形式でデータを読み取るとき

    にインメモリー・データベース形式の列指向キャッシュも作成される • この機能により、列指向キャッシュの作成のパフォーマンスが大幅に向上 • 特に、ハード・ディスクのIO帯域幅が複数のワークロードで同時に使用さ れる場合に効果がある。 - ハード・ディスク帯域幅を使用するバックアップ処理では、 インメモリー列指向キャッシュ作成とこの帯域幅を共有する必要がなくなった。 その結果、バックアップ処理とインメモリー列指向キャッシュ作成はどちらもより高 速に実行されるようになる 高速なインメモリー列指向キャッシュ作成 20.1以降 In-memory Rewrite Engine 従来 FLASH In-memory Rewrite Engine Read On-disk Write In-memory Columnar format Write In-memory Columnar format Read Flash Intermediate format FLASH Exadata 20.1 ~ Copyright © 2026, Oracle and/or its affiliates 220 Oracle Database In-Memoryオプションが必要
  181. Persistent Columnar Cache 概要 • Columnar Cacheは、インメモリ列ストアをストレージサーバー上のフラッシュに拡張する機能 • データベースサーバーのCPU使用率を削減 •

    有効なインメモリ容量を増加 • Exadata 21.2.0 より前 • Storage Server に障害が発生するかシャットダウンすると、 Columnar Cache を管理するためのメタデータは保持されない • Storage Server を再起動すると、Columnar Cache のメタデータの再構築が必要 • Exadata 21.2.0以降 • Columnar Cache はStorage Server の再起動およびアップグレード後も保持 • メタデータの再構築に関連するリソースを節約し、 Storage Serverの再起動直後も一貫したクエリパフォーマンスが可能 永続列キャッシュ Copyright © 2026, Oracle and/or its affiliates 221 Exadata 21.2.0 ~ Oracle Database In-Memoryオプションが必要
  182. Persistent Columnar Cache 設定方法 • 永続的なColumnar Cache を使用するには、Exadata Smart Flash

    Cacheが Write-Back モードである必要がある。 この機能は、columnarCachePersMode セル属性を設定することによって制御される • columnarCachePersMode 属性は、永続的な列キャッシュ機能を制御するセル属性を設定および表示するために使用される。 有効 な属性設定は次のとおり • on-永続的な列キャッシュ機能を有効にする • off-永続的な列キャッシュ機能を無効にする • auto-Oracle Exadata System Softwareは、永続的な列キャッシュ機能を有効にするか無効にするかを決定する。 columnarCachePersMode 属性が設定されていない場合、auto 設定が利用される • columnarCachePersMode 属性を変更した後、変更を反映するためにセルサーバーを再起動する必要がある • Exadata 21.2.0 ~ 21.2.10 auto 設定は永続的な列キャッシュ機能を無効化(columnarCachePersMode = offと同等) • Exadata 21.2.11 ~ 、22.1.0~ auto 設定は永続的な列キャッシュ機能を有効化(columnarCachePersMode = onと同等) 永続列キャッシュ Copyright © 2026, Oracle and/or its affiliates 222 Exadata 21.2.0 ~ Oracle Database In-Memoryオプションが必要
  183. Columnar Cache on Exadata RDMA Memory (XRMEM) • Smart Scan

    は、Exadata X10M ストレージ・サーバーの XRMEMメモリーのカラムナー・データに直接アクセス • 最大6.5倍の高速なクエリー・パフォーマンス • AIベクトル・スキャンにおいて、OLTPのような1秒未満の レイテンシを実現 • Exadata System Software は、 最も頻繁にアクセスされる列データをXRMEMに自動的にポピュレート し、残りの列データをフラッシュに • Exadata System Software は、 OLTPデータと列データをXRMEMに透過的に配置して、 両方のワークロード・タイプを加速 Exadata RDMAメモリー(XRMEM)の列キャッシュ Copyright © 2026, Oracle and/or its affiliates 223 Exadata Database Server SQL Offload 100G RoCE Network XRMEM Columnar Cache Flash Columnar Cache Exadata Storage Server Exadata 24.1.0 ~
  184. インメモリー列指向の高速JSON問合せ In-Memory Columnar Speed JSON Query JSONは、Oracle Databaseのリレーショナル・データと共存するスキーマレスお よびドキュメントベースのアプリケーションで一般的に使用されるデータ型 スマート・スキャン中、ExadataはJSONドキュメントのデータを

    インメモリー列形式に自動的かつ透過的に変換し、 フラッシュ・キャッシュにロード インメモリー列形式により、JSON分析クエリを高速化 • 最大 4.4倍 高スループット • 最大 4.4倍 低レイテンシー • 最大 7倍 ストレージCPU使用率の低下 224 Copyright © 2024, Oracle and/or its affiliates Requires Database In-Memory XRMEM Columnar Cache Flash Columnar Cache Exadata Storage Server Exadata Database Server Smart Scan 100G RoCE Network Exadata 24.1.0 ~
  185. Transparent Cross-Tier Scan • 分析ワークロード表が大きく、データが列形式の コンピュート・ノードとストレージ・ノードに分散している 場合 • 従来の単一の問合せでは、データベース・サー バーでのインメモリー列指向スキャン、またはスト

    レージ・サーバーでのExadataスマート・スキャンお よび列キャッシュのいずれかを使用できたが、両方 は使用できない • 単一のクエリーで、コンピュート、ストレージ上の インメモリー列データをスキャン可能に • シリアル問合せとパラレル問合せで 透過的に階層間スキャンを実行可能 • どちらの層でも、SIMD処理、圧縮、ディクショナリ・エン コーディング、データ・プルーニングのメリットが受けられる • 透過的階層間スキャンは、データがデータベース・サー バーおよびストレージ・サーバーに分散されている大規 模な表に対する分析問合せに最適 透過的階層間スキャン Copyright © 2026, Oracle and/or its affiliates 226 最大 3倍 クエリの高速化 Compute Node In-Memory Columnar scans Storage Node Columnar Smart Scans データのプルーニング ディクショナリ・エンコーディング 圧縮 SIMD処理 Exadata 24.1.0 ~
  186. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache > Flash Cache Space Usage / Flash Cache User Reads / Flash Cache User Reads Efficiency 【参考】 Exadata Columnar Cacheの利用状況確認例 Copyright © 2026, Oracle and/or its affiliates 227 列キャッシュに使用されている領域の量 列キャッシュからの読取りの統計
  187. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Flash Cache > Columnar Cache Efficiency / Flash Cache Internal Writes / Columnar Cache Population / Columnar Cache Population - Current 【参考】 Exadata Columnar Cacheの利用状況確認例 Copyright © 2026, Oracle and/or its affiliates 228 列キャッシュ形式ごとに、列キャッシュからの読取りの統計 列キャッシュへの移入書込みの統計 列キャッシュ形式ごとに、列キャッシュへの移入書込みの統計
  188. Columnar Cache セクションの追加 Columnar Cache セクション • 従来は Flash Cache

    のセク ションに Columnar Cache の 情報が含まれていた • Backported to Oracle Database 19c AWR Report – Exadata sections に新しいセクションの追加 Copyright © 2026, Oracle and/or its affiliates 229
  189. データベース統計を使用したスマートI/Oの監視 統計 説明 cell physical IO bytes eligible for smart

    IOs 条件のオフロードの対象となる実際のバイト数。 たとえば、列キャッシュを使用する場合、これはディスク上のサイズではなく列キャッ シュのサイズ cell physical IO bytes processed for IM capacity 列キャッシュからmemcompress for capacity形式で読み取られたバイト数 cell physical IO bytes processed for IM query 列キャッシュからmemcompress for query形式で読み取られたバイト数 cell physical IO bytes processed for no memcompress 列キャッシュからno memcompress形式で読み取られたバイト数 cell physical IO bytes processed for XrCC Exadata RDMAメモリー(XRMEM)上の列キャッシュから読み取られたバイト数 cell physical IO bytes saved by columnar cache 列キャッシュによって保存されたバイト数。つまり回避された読取りバイト数 【参考】 Exadata Columnar Cacheの利用状況確認例 Copyright © 2026, Oracle and/or its affiliates 230
  190. Exadataメトリックを使用したExadata Columnar フラッシュ・キャッシュの監視 • name like 'FC_COL.*' であるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • 関連メトリック(抜粋)

    【参考】 Exadata Columnar Cacheの利用状況確認例 Copyright © 2026, Oracle and/or its affiliates 231 FC_COL_BYKEEP_USED "Number of megabytes used for keep objects in Columnar FlashCache" FC_COL_BY_USED "Number of megabytes used in Columnar FlashCache" FC_COL_IO_BYKEEP_R "Number of megabytes read from Columnar FlashCache for keep objects" FC_COL_IO_BYKEEP_R_SEC "Number of megabytes read per second from Columnar FlashCache for keep objects" FC_COL_IO_BY_R "Number of megabytes that were read from Columnar FlashCache" FC_COL_IO_BY_R_ELIGIBLE "Number of megabytes eligible to read from Columnar FlashCache" FC_COL_IO_BY_R_ELIGIBLE_SEC "Number of megabytes per second eligible to read from Columnar FlashCache" FC_COL_IO_BY_R_SEC "Number of megabytes per second that were read from Columnar FlashCache" FC_COL_IO_BY_SAVED "Number of megabytes saved by reads from Columnar FlashCache" FC_COL_IO_BY_SAVED_SEC "Number of megabytes saved per second by reads from Columnar FlashCache" FC_COL_IO_BY_W_POPULATE "Number of megabytes that are population writes into Columnar FlashCache due to read miss" FC_COL_IO_BY_W_POPULATE_SEC "Number of megabytes per second that are population writes into Columnar FlashCache due to read miss" FC_COL_IO_RQKEEP_R "Number of requests read for keep objects from Columnar FlashCache" FC_COL_IO_RQKEEP_R_SEC "Number of requests read per second for keep objects from Columnar FlashCache" FC_COL_IO_RQ_R "Number of requests that were read from Columnar FlashCache" FC_COL_IO_RQ_R_ELIGIBLE "Number of reads eligible for Columnar FlashCache" FC_COL_IO_RQ_R_ELIGIBLE_SEC "Number of reads per second eligible for Columnar FlashCache" FC_COL_IO_RQ_R_SEC "Number of requests per second that were read from Columnar FlashCache" FC_COL_IO_RQ_W_POPULATE "Number of requests that are population writes into Columnar FlashCache due to read miss" FC_COL_IO_RQ_W_POPULATE_SEC "Number of requests per second that are population writes into Columnar FlashCache due to read miss" CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE NAME LIKE 'FC_COL.*'
  191. • ストレージ索引と同様に、列キャッシュがまだ構築(または再構築)されていない場合 • 列キャッシュに関連付けられている保存が減少して表示されることがある • 列キャッシュのパフォーマンスを監視 • AWRレポートのColumnar Cache セクション、

    • データベース統計cell physical IO bytes saved by columnar cache • SQLモニターの行ソース統計Columnar cache saved bytesを監視 • ストレージ索引と同様に、列キャッシュはcellsrvが起動するたびに再構築される • 列キャッシュは、cellsrvの起動直後に操作のメリットを得ることはできない • 列キャッシュは、スマート・スキャンの実行時にストレージ・サーバーによって自動的に移入および管理される • 非圧縮セグメント、OLTP圧縮を使用して圧縮されたセグメントおよびExadataハイブリッド列圧縮を使用して圧縮されたセグメントに対するスマート・スキャン操作の場合、 データはスマート・スキャンの一部として列キャッシュ形式(no memcompress)に自動的に変換される • Oracle Database In-Memoryを使用している場合、 • データはバックグラウンド・プロセスを使用してOracle Database In-Memoryの列形式(memcompress for queryまたはmemcompress for capacity)にリライトされる • 対象データに対する操作には、キャッシュが再移入されるまで、Oracle Database In-Memoryの最適化の効果がない • 移入ジョブの詳細 - AWRレポートのColumnar Cache Populationセクション • 列キャッシュからの読取りが少ない場合 • データベース統計の値(cell physical IO bytes processed for IM Query、cell physical IO bytes processed for IM Capacity、cell physical IO bytes processed for no memcompress)が小さくなることわかる • SQLモニターの行ソース統計は、IM Query bytes、IM Capacity bytesおよびNo memcompress bytes 列キャッシュが期待どおりに実行されない Copyright © 2026, Oracle and/or its affiliates 232
  192. Smart Consolidation: Exadata I/O Resource Manager • Exadata のリソース管理テクノロジー •

    IORM のアーキテクチャー • IORMのobjectiveについて • IORM Plan • IORMのリソース割当て方法 • “share” を使用したI/O の優先度の指定 • “allocation”(パーセンテージ) を使用したI/O の優 先度の指定(参考) • Disk I/O 使用率の上限値設定 • IORMプランでのFlash Cache管理 • IORMプランでのXRMEM Cache管理 • IORM Cluster Plan • asmcluster属性の使用 • role属性の使用 • IORM profileの使用 • データベース内のデータベース・リソース管理 • コンシューマ・グループとリソース・プランについて • CDBプランとプラガブル・データベースについて • コンシューマ・グループおよびカテゴリの設定 • コンシューマ・グループへのセッションの割当て • CDBプランの作成 • データベース・プランの作成 • データベース・リソース・プランの有効化 • データベースおよびPDBのためのXRMEMキャッシュ 割当て制限の管理 • データベース間のリソース・プランの管理のヒント • I/Oリソース管理の構成の確認
  193. Smart Consolidation: Exadata I/O Resource Manager • AWRを使用したIORMの監視 • データベース統計を使用したIORMの監視

    • Exadataメトリックを使用したIORMの監視 • データベース・メトリックを使用したIORMの監視 • PDBメトリックを使用したIORMの監視 • IORM使用率の監視 • IORMを監視する際の注意事項 • Enterprise Managerを用いたIORMの管理 235 Copyright © 2026, Oracle and/or its affiliates
  194. ソフトウェアによるハードウェア・リソースの干渉の極小化 Database レイヤー: Database Resource Management • データベース間 • データベース内(PDB毎、コンシューマグループ毎)

    • 制御対象の一例 • CPU • アクティブ・セッション数 • パラレル・クエリの制御 Exadata のリソース管理テクノロジー メモリの制御 • SGA_TARGET • PGA_AGGREGATE_TARGET • PGA_AGGREGATE_LIMIT Storage レイヤー: I/O Resource Management (Exadata Only) • データベース間 • I/O 帯域幅の制御 (Disk 帯域幅/Flash 帯域幅) • Flash 使用量の制御 • XRMEM 使用量制御 Copyright © 2026, Oracle and/or its affiliates 236 Network レイヤー: Network Resource Management (Exadata Only)
  195. IORM のアーキテクチャー DB Server から送られてくる I/O リクエストをグループごとのキューを用いて管理 【定義したプラン】に基づき、優先順位が高い I/O リクエストから優先的にデキューされる

    セールス系 Database Exadata Storage Server H L L L L EBS グループ キュー Batch グループ キュー I/O Resource Manager バックオフィス系 Database H H L L L 人事 グループ キュー 会計 グループ キュー ディスク キュー H L H L H H L H H バックオフィス系 DB セールス系 DB カテゴリ / DB / コンシューマ・グループ ごとにキューがある 優先 優先 Copyright © 2026, Oracle and/or its affiliates 237
  196. ストレージサーバー側で、I/O 処理の最適化モードを設定 - auto: • IORM のプランと、現在のI/O リクエストの状況により、最適化のobjectiveを自動的かつ動的に決定 • auto

    の利用が推奨 • Exadata 21.2.0 以降、auto がデフォルト - high_throughput: • スループット重視(DWH 処理を優先したい場合)、IOレイテンシーは長くなる - low_latency: • レイテンシー重視(OLTP 処理を優先したい場合)、スループットが低下 - balanced: • スループットとレイテンシーのバランスをとる(OLTP 処理とDWH 処理のバランスをとりたい場合) - basic • Exadata 20.1.0 以前のデフォルト • small IO の最大レイテンシーを制限する場合に使用、それ以外の場合はIO優先付けを無効化 - IORMはスマート・スキャンやその他のディスク集中型のI/O操作の前にログの書込み、バッファ・キャッシュの読取り、その他のクリティカルなI/Oを優先順位付けすることで、これらの処 理において極端に長い待機時間が発生しないように監視 - IORMはフラッシュ・キャッシュおよびフラッシュ・ログへのアクセスを管理 - IORMは異なるワークロード間でリソースが共有されるようにスキャンを管理 - IORMはIORMプランの最大使用率制限(maximum utilization limits)を強制されない。プラン割当ては、極端に長い待機時間が発生しないように保護するためだけに使用 され、プランへの適合は考慮されない。プランに厳密に適合させるために、maximum utilization limits を制限する場合は、objectiveオプションをbasic以外の値に設定する必 要がある IORMのobjectiveについて 238 Copyright © 2026, Oracle and/or its affiliates [root@jojocel02 ~]# cellcli -e list iormplan detail name: jojocel02_IORMPLAN catPlan: dbPlan: clusterPlan: objective: auto status: active [root@jojocel02 ~]#
  197. フラッシュへのIORM • High Capacity (HC)ストレージ・サーバーの場合 • OLTPレイテンシを保護 - フラッシュへのIORMは、スマート・スキャンおよび優先度の低いI/Oより先にフラッシュ・デバイスへのクリティカルなI/Oの優先度を設定する -

    objectiveオプションの設定に関係なく、デフォルトで動作する • Extreme Flash (EF)ストレージ・サーバーの場合 • IORM の objective によりフラッシュ IORM をある程度制御 • objectiveオプション別の動作 - basic、auto、balancedに設定されている場合 • フラッシュIORMはHCサーバーと同じように動作 - high_throughput • クリティカルなI/Oレイテンシを犠牲にしてスキャン・スループットを向上 - low_latency • 両方のワークロードが同時に実行される場合に、スキャン・スループットが大幅に低下することを犠牲にして最大のレイテンシ保護を提供 IORMのobjectiveについて Copyright © 2026, Oracle and/or its affiliates 239
  198. IORM Plan IORM プラン全体像 IORM プランの種類 制御対象のリソース 設定方法 補足 カテゴリ・プラン(catPlan)

    複数DB にわたるリソース Storage Server:CellCLI コマンド Exadata 21.2.0 から非推奨、 25.1で非サポート データベース間プラン (dbPlan) DB、または、CDB 単位 Storage Server:CellCLI コマンド 設定されていない場合デフォルトは同じ割合で共有 shareベースでの設定が推奨 allocation ベースは非推奨(not recommend) クラスタ・プラン(clusterPlan) クラスター間(Grid Infrastructure クラ スター間の リソース割当てを管理) Storage Server:CellCLI コマンド Exadata 21.2.0以降 catPlanとは同時に利用不可能 shareベースのみ 設定されていない場合デフォルトは同じ割合で共有 データベース内プラン コンシューマ・グループ(CG)単位 DB サーバー:PL/SQL データベースにアクティブなデータベース・リソース・プラン がない場合は、すべてのユーザーI/Oが同じように処理 CDB プラン PDB 単位 DB サーバー:PL/SQL 240 Copyright © 2026, Oracle and/or its affiliates • データベース間プラン => データベース内プラン の順でIOリソースが割り当てられる • clusterPlanとdbPlanを組み合せて使用できるのは、dbPlanにallocationまたはlevelディレクティブが含まれていない場合のみ。 (この場合、両方のプランのディレクティブが適用され、リソースの共有が決定) Exadata 21.2.0 ~ [root@jojocel02 ~]# cellcli -e list iormplan detail name: jojocel02_IORMPLAN catPlan: dbPlan: clusterPlan: objective: auto status: active [root@jojocel02 ~]#
  199. dbPlan、clusterPlan • cellcliコマンドの share ないしは allocation でリソースを割り当て • DB_UNIQUE_NAME をデータベースの識別子として使用

    • 異なるOracle ASMクラスタにDB_UNIQUE_NAMEが同じデータベースがある場合、Exadata 19.1.0 以降では、asmcluster 属性を使用 すると、データベース間プランの各データベースを一意に識別 • share • 相対的な重要度(1~32)で指定 • share の合計 < 32768 • dbPlan(データベース間プラン)での利用を推奨 • clusterPlan では share のみが利用可(allocation は利用不可) • allocation • パーセンテージで指定 • level も指定可能 - 1~8 - allocation の合計が各 level で100以下 • dbPlan では利用できるが非推奨 IORMのリソース割当て方法 Copyright © 2026, Oracle and/or its affiliates 241
  200. 推奨 • データベース間プラン、クラスタープランに対して使用可能 • 使い方: 各DBごと・クラスター毎に、1 ~ 32 の”share”を割り当てる •

    割り当てられた”share”が大きいほど、I/Oは優先される • shareの合計は32768まで、1024個のdirectiveまで対応 • 最初に、データベース間のプランによって各データベースにI/Oリソースが割り当て • 次に、各データベースのデータベース・リソース・プランによってコンシューマ・グループにI/Oリソースが割り当て • データベースにアクティブなデータベース・リソース・プランがない場合は、すべてのユーザーI/Oが同じように処理 • バックグラウンドのI/Oは、重要度に基づいてユーザーI/Oに対して優先度が付く • ベストプラクティス • ストレージを共有するデータベースごとにディレクティブを作成することを推奨 • DEFAULT:明示的なディレクティブの無いデータベースは、”DEFAULT” ディレクティブの設定が適用される - 注意: “OTHER” データベースの属性は使用できない。 - DEFAULTのshareはデータベース毎に1 “share” を使用したI/O の優先度の指定 データベース Share 内部的な割り当て OLTP 7 70 %(7/10) DWH 2 20 %(2/10) DEFAULT 1 10 %(1/10) CellCLI> ALTER IORMPLAN dbplan = (( name=OLTP, share=7 ), ( name=DWH, share=2 ), ( name=DEFAULT,share=1 )) Copyright © 2026, Oracle and/or its affiliates 242 Exadata 11.2.3.1.0
  201. データベース間プランでは今後は非推奨 • データベース間プラン / データベース内プラン で使用可能 • データベース間プラン の場合 •

    cellcli コマンドで設定 • “level” や “allocation” を指定する • 32個のdirectiveまでサポート • OTHER:明示的なディレクティブの無いデータベースはOTHERディレクティブが利用される - 注意: “DEFAULT” データベースの属性は使用できない。 • 今後は非推奨 • データベース内プランの場合 • DBサーバー側で、dbms_resource_manager PL/SQLパッケージを用いて設定 • ※設定したプランは、DBサーバーのCPU使用率の制御にも適用される “allocation”(パーセンテージ) を使用したI/O の優先度の指定(参考) CellCLI> ALTER IORMPLAN dbplan = (( name=OLTP, level=1, allocation=80), ( name=DWH, level=1, allocation=20), ( name=OTHER,level=2, allocation=100)) データベース Level 1 Level 2 OLTP 80 % DWH 20 % OTHER 100 % Copyright © 2026, Oracle and/or its affiliates 243
  202. IORMのリソース割当て方法 share とallocationの違い allocation HR Database 80 % ERP Database

    20 % allocation HR Database 70 % ERP Database 15 % CRM Database 15 % share 内部的な割り当て HR Database 8 66 % ( 8/12 ) ERP Database 2 16 % ( 2/12 ) CRM Database 2 16 % ( 2/12 ) share 内部的な割り当て HR Database 8 80 % ( 8/10 ) ERP Database 2 20 % ( 2/10 ) CRM Databaseを 追加 Copyright © 2026, Oracle and/or its affiliates 244
  203. IORMのリソース割当て方法 • Utilization(Disk 使用率)の考え方 • Utilization = 計測期間中のディスクの使用率 • 例:直近1分間のI/O

    コスト の平均を10 ms, I/O リクエスト数を3600 とすると • Utilization = { ( I/O コスト平均 * I/O リクエスト数 ) / 時間 } * 100 (%) = { (10 * 3600) / (60*1000) } * 100 (%) = 60 % • Maximum Utilization limit • Disk I/O 使用率(Utilization)の上限値を設定 • データベース内プラン・データベース間プランで有効 • allocation もしくは、shareとの併用も可能 Disk I/O 使用率の上限値設定 Copyright © 2026, Oracle and/or its affiliates 245
  204. IORMのリソース割当て方法 • ワークロードが突然上昇した場合に各データベースを分離可能 • システムを独占できるデータベースがないことが保証される • データベースが割り当てられた制限に達すると、空き容量を利用できなくなる • データベース間プランの場合 •

    Cellサーバー側で、CellCLIコマンドを用いて設定 • データベースごとに“limit” 句を指定、フラッシュI/O使用率の上限を指定 • limit値を低く指定すると、パフォーマンスに深刻な影響を与える可能性があり、通常は非推奨 • データベース内プランの場合 • DBサーバー側で、dbms_resource_manager PL/SQLパッケージを用いて設定 • (MAX_UTILIZATION_LIMIT属性) • ※設定したプランは、DBサーバーのCPU使用率の制御にも適用される Disk I/O 使用率の上限値設定 CellCLI> ALTER IORMPLAN dbplan=((name=prod), (name=test, limit=20), (name=DEFAULT, limit=10)) データベース 上限値 test 20 % DEFAULT 10 % Copyright © 2026, Oracle and/or its affiliates 246
  205. データベース間 IORM Plan(Non-CDB or CDB 単位で設定) Use Flash Log ?

    flashlog=on / off Use Flash Cache? flashcache=on / off Flash Cache の 最小容量 (Hard Limit) flashCacheMin Flash Cache の最大容量 (Soft limit) flashCacheLimit Flash Cache の最大容量 (Hard Limit) flashCacheSize DWH ✓ ✓ 500 GB OLTP1 ✓ ✓ 1 TB OLTP2 ✓ ✓ 500 GB 1 TB IORMプランでのFlash Cache管理 データベースごとに Flash 領域を確保し、必要なパフォーマンスを担保 247 Copyright © 2026, Oracle and/or its affiliates PDB 単位の設定は CDB resource planで可 能 memory_min memory_limit 空き領域があってもそれ以上は使用しない (設定例) 基幹の OLTP1 システムには、最低限 1 TB の割り当て DWH システムは、Flash 利用率が高い場合には、500 GB で制御 空き領域があれば超えて使用する Exadata 12.1.2.2.0 ~ Exadata 19.2.0.0.0 ~
  206. データベースごとに Flash の使用有無、領域を確保し、必要なパフォーマンスを担保 IORMプランでのFlash Cache管理 dbPlan 向けディレクティブ 指定するパラメータ flashCacheMin ブロックがコールド状態であっても指定されたデータベースに対して保証される、Flash

    Cache領域の最小容量。強い制限。 最小4MB。 保証付き予約のため、すべてのディレクティブのflashCacheMinの合計は、各データベースがそれぞれの割当てを取得する ように、フラッシュ・キャッシュのサイズより小さくする必要 flashCacheLimit 弱い最大容量を指定。Flashキャッシュがフルでない場合、データベースはflashCacheLimit値を超過可能。最小4MB flashCacheSize Flashキャッシュ領域の強い最大容量を指定。flashCacheSize値を超えることは不可能。最小4MB。 flashCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、超過分のデータがキャッシュ から事前に消去(Exadata 20.1.0以降) • データベース間 IORMプランにより、特定のデータベース毎に、 Flash Cache の領域制御 が可能に • 強い制限(Hard limit):キャッシュがフルでない場合でも、指定された制限を超過できない • 弱い制限(Soft limit) :使用可能なリソースがある場合に、指定された制限を超過できる • flashcache は flashcachesize, flashcachelimit, flashcachemin が指定されている場合には off の設定は不可 • flashcachesize と flashcachelimit を同時に設定することは不可 • flashCacheLimitが設定されている場合、flashCacheMin < flashCacheLimit が必要(逆は不可) • flashCacheSizeが設定されている場合、flashCacheMin < flashCacheSize が必要(逆は不可) Copyright © 2026, Oracle and/or its affiliates 248 Exadata 12.1.2.2.0 ~ Exadata 19.2.0.0.0 ~
  207. IORMプランでのFlash Cache管理 設定例 データベース名 share limit % Flash Cache の

    最小容量 flashCacheMin Flash Cache の 最大容量 (soft limit) flashCachLimit Flash Cache の 最大容量 (hard limit) flashCacheSize newcdb 8 20G finance 8 2G 10G dev 2 1G 4G test 1 10 1G 249 Copyright © 2026, Oracle and/or its affiliates 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)
  208. データベースごとに XRMEM の使用有無、領域を確保し、必要なパフォーマンスを担保 IORMプランでのXRMEM Cache管理 dbPlan 向けディレクティブ 指定するパラメータ xrmemCacheMin ブロックがコールド状態であっても指定されたデータベースに対して保証される、XRMEMキャッシュ領域の最小容量。強い

    制限。最小4MB 保証付き予約のため、すべてのディレクティブのxrmemCacheMinの合計は、各データベースがそれぞれの割当てを取得す るように、XRMEMキャッシュのサイズより小さくする必要 xrmemCacheLimit 弱い最大容量を指定。XRMEMキャッシュがフルでない場合、データベースはxrmemCacheLimit値を超過可能。最小 4MB xrmemCacheSize XRMEMキャッシュ領域の強い最大容量を指定。xrmemCacheSize値を超えることは不可能。最小4MB xrmemCacheSizeを、データベースが使用している現在の領域よりも小さい値に設定した場合、超過分のデータがキャッ シュから事前に消去 • データベース間 IORMプランにより、特定のデータベース毎に、 XRMEM Cache の領域制御 が可能に • 強い制限(Hard limit):キャッシュがフルでない場合でも、指定された制限を超過できない • 弱い制限(Soft limit) :使用可能なリソースがある場合に、指定された制限を超過できる • xrmemcache は xrmemcachesize, xrmemcachelimit, xrmemcachemin が指定されている場合には off の設定は不可 • xrmemcachesize と xrmemcachelimit を同時に設定することは不可 • xrmemCacheLimitが設定されている場合、xrmemCacheMin < fxrmemCacheLimit が必要(逆は不可) • xrmemCacheSizeが設定されている場合、xrmemCacheMin < xrmemCacheSize が必要(逆は不可) Copyright © 2026, Oracle and/or its affiliates 250 Exadata 19.3.0/20.1.0 ~
  209. XRMEM向け IORM DBプラン 設定例 データベース名 share XRMEM Cache の最 小使用量

    xrmemCacheMin XRMEM Cache の最 大使用量 (soft limit) xrmemCacheLimit XRMEM Cache の最 大使用量 (hard limit) xrmemCacheSize Flash Cache の 最小容量 flashCacheMin Flash Cache の 最大容量 (soft limit) flashCachLimit Flash Cache の 最大容量 (hard limit) flashCacheSize newcdb 8 200G 10G finance 8 100G 200G 10G 2G dev 2 1G 10G 4G 1G test 1 251 Copyright © 2026, Oracle and/or its affiliates ALTER IORMPLAN dbplan= ((name=newcdb, share=8, xrmemCacheSize= 200G, flashCacheSize=10G), (name=finance, share=8, xrmemCacheMin= 100G, xrmemCacheLimit= 200G, flashCacheLimit=10G, flashCacheMin=2G), (name=dev, share=2, xrmemCacheMin= 1G, xrmemCacheLimit= 10G, flashCacheLimit=4G, flashCacheMin=1G), (name=test, share=1)) • newcdb (CDB)と、3つのデータベース(finance、dev、test)で同じストレージ・サーバーを共有 • XRMEMキャッシュ割当て制限は、ディレクティブでxrmemCacheSize、xrmemCacheLimitまたはxrmemCacheMin属性が指定されている場合にのみ適用 • testデータベースにはXRMEMキャッシュのディレクティブが指定されていないため、そのデータベースおよびPDB (ある場合)では、XRMEMキャッシュの割当て制限はされない
  210. Cluster(VM)毎に設定可能なIORMプラン • Exadata Storage Server のリソースを Grid Infrastructure クラスター(VM)に対応した割当てが可能に •

    share, limit のリソース管理ディレクティブで利用 • データベースレベルやコンシューマーグループレベルよりも、クラスターレベルでのリソース統合を可能にする機能 - あるデータベースクラスターの優先付けを他の統合環境より優先度を上げることが可能 - 新しいデータベースインスタンスを追加した際にすでに存在しているクラスター間のIO割当てを遵守させることが可能に • ASM-Scoped Security の設定が必要 IORM Cluster Plan Cluster Plan Sales: 3 Finance: 1 Sales Finance 1 3 RDBMS RDBMS * Exadata 21.2 と ASM-Scoped Security を設定していることが必要 Exadata 21.2.0 ~ Copyright © 2026, Oracle and/or its affiliates 252 ASM-Scoped Security
  211. Intra-DB Plan (データベース内 プラン) Inter-DB Plan (データベース間 プラン) IORM プランの階層

    IORM Cluster Plan Cluster Plan Cluster 1 DB1 PDB1 PDB2 CDB2 PDB1 PDB2 Cluster 2 DB1 PDB1 PDB2 CDB2 PDB1 PDB2 CDB1 CDB1 Exadata 21.2.0 ~ Copyright © 2026, Oracle and/or its affiliates 253 ASM-Scoped Security
  212. IORM Cluster Plan • 2つのお客様が、異なるVMで同じExadataシステム上実行している場合 • VMは同じサイズであるため、CPU、メモリ、およびIOリソースを等しくする必要がある • Cust1は、VMに1つの大きなデータベース •

    Cust2は、VMに3つの中規模データベース • VM間で同等のIORM share を提供するには、以下に示すようにデータベース間プランを作成する必要がある 複数VM でデータベース間プラン(dbplan)を使っている場合 DB追加時の影響 Copyright © 2026, Oracle and/or its affiliates 254 IORM share 結果割合 VM1 Cust1_DB1 3 50% VM2 Cust2_DB1 1 16.66% Cust2_DB2 1 16.66% Cust2_DB3 1 16.66%
  213. IORM share 結果の割合 VM1 Cust1_DB1 3 42% VM2 Cust2_DB1 1

    14% Cust2_DB2 1 14% Cust2_DB3 1 14% Cust2_DB4 1 14% IORM Cluster Plan • 2つのお客様が、異なるVMで同じExadataシステム上実行している場合 • VMは同じサイズであるため、CPU、メモリ、およびIOリソースを等しくする必要がある • Cust1は、VMに1つの大きなデータベース • Cust2は、VMに3つの中規模データベース • VM間で同等のIORM share を提供するには、以下に示すようにデータベース間プランを作成する必要がある • Cust2が別のデータベースを追加した場合、Cust1に劣化が発生 複数VM でデータベース間プラン(dbplan)を使っている場合 DB追加時の影響 Copyright © 2026, Oracle and/or its affiliates 255
  214. • 2つのお客様が、異なるVMで同じExadataシステム上実行している場合 • VMは同じサイズであるため、CPU、メモリ、およびIOリソースを等しくする必要がある • Cust1は、VMに1つの大きなデータベース • Cust2は、VMに3つの中規模データベース • VM間で同等のIORM

    share を提供するには、以下に示すようにデータベース間プランを作成する必要がある • Cust2が別のデータベースを追加する場合、Cust1に劣化が見られないように IORMPLAN を変更する必要がある - clusterplan が利用できると、VM間(cluster間)のIOリソース管理が容易に IORM share 結果の割合 VM1 Cust1_DB1 4 50% VM2 Cust2_DB1 1 12.5% Cust2_DB2 1 12.5% Cust2_DB3 1 12.5% Cust2_DB4 1 12.5% IORM Cluster Plan 複数VM でデータベース間プラン(dbplan)を使っている場合 DB追加時の影響 Copyright © 2026, Oracle and/or its affiliates 256
  215. IORM Cluster Plan cellcli で iormplan clusterPlan を設定 確認 Clusterプラン

    設定方法 CellCLI > alter iormplan clusterPlan = ((name=cl1,share=5,limit=30), (name=cl2,share=2,limit=50)) CellCLI> list iormplan detail … clusterPlan: name=cl1,limit=30,share=5 name=cl2,limit=50,share=2 … Copyright © 2026, Oracle and/or its affiliates 257
  216. IORM Cluster Plan • I/Oリソース管理(IORM)クラスタ・プランでは、複数のクラスタ間でストレージ・サーバー・リソースを割り当てる方法を指定。 クラスタ・プランの各ディレクティブは、個々のデータベースまたはコンシューマ・グループではなく、クラスタへの割当てを指定 • 例:clusterA、clusterBという2つのクラスタをホストするシステム - clusterAに3つのshare、clusterBに1つのshareが設定されたshareベースのリソース割当てを持つクラスタ・プラン

    - 他のIORMプランがない場合、 clusterAで実行されているすべてのデータベースはI/Oリソースの75%をshareし、clusterBのデータベースは残りの25%をshare • 明示的なshareディレクティブが設定されてないclusterは、デフォルトshare=1が設定 - クラスタ・プランで識別されてないクラスタが含まれる - 前述のclusterA(share=3)、clusterB (share=1)に、clusterC(share=未設定)、 clusterD(share=未設定)が追加されると、3:1:1:1 • クラスタ・プランは、データベース間リソース・プラン (dbPlan) と連携できる • データベース間リソース・プランがallocationベースのリソース管理を使用していない場合のみ可能 - この場合、両方のプランのディレクティブが適用され、リソースのshareが決定される - 前述の例 • clusterA内のデータベースがshareベースのリソース割当てを使用したデータベース間リソース・プランにあるとする場合、クラスタ・プランでclusterAに割り当てられたリソー スは、データベース間リソース・プランのディレクティブを使用してデータベース間でさらに分割および共有される • クラスタ・プランは、カテゴリ・プラン (catPlan) と連携して動作不可能 • クラスタ・プランは、CellCLIのALTER IORMPLANコマンドを使用して、各ストレージ・サーバーで構成および有効化される。 • クラスタ・プランを操作するには、ASM-Scoped Securityも構成する必要 クラスタのリソース管理について Copyright © 2026, Oracle and/or its affiliates 258 Exadata 21.2.0 ~ ASM-Scoped Security
  217. DB_UNIQUE_NAMEでExadataストレージを共有する複数クラスタをサポート • asmcluster属性を使用すると、同じ DB_UNIQUE_NAME を持つデータベースを一意に識別可能に • 同じ DB_UNIQUE_NAME を持っているが、異なる Oracle

    ASM クラスタに関連付けられているデータベースがある場合、 Exadata System Software 19.1.0 以降では、asmcluster 属性を使用すると、データベースを一意に識別可能 • データベースは異なる Oracle ASM クラスタのクライアントである必要があり、クラスタの識別を容易にするために ASM- Scoped Security を構成する必要がある • level、 allocation は利用不可 asmcluster属性の使用 Copyright © 2026, Oracle and/or its affiliates 259 CellCLI> ALTER IORMPLAN dbplan=((name=cdb1, share=4, flashcachemin=5G, asmcluster=asm1), (name=cdb1, share=2, limit=80, asmcluster=asm2), (name=cdb2, share=2, flashcachelimit=2G, asmcluster=asm1), (name=default, share=1, flashcachelimit=1G)) Exadata 19.1.0 ~ ASM-Scoped Security
  218. • データベースにOracle Data Guard の primary または standby ロールがあるかどうかに基づいて、異なる割当てを指定 可能

    • デフォルトでは、データベースがいずれかの role の場合に、データベース間プランのディレクティブが適用される • データベースが primary ロールの場合にのみディレクティブを適用する場合は、role=primary を含める • データベースが standby ロールの場合にのみディレクティブを適用する場合は、role=standby を含める role属性の使用 Copyright © 2026, Oracle and/or its affiliates 260 CellCLI> ALTER IORMPLAN dbPlan=((name=prod, share=8, role=primary), (name=prod, share=1, limit=25, role=standby), (name=default, share=2))
  219. • IORM のデータベース間プランでは、数百ものデータベースのデータベース間プランの管理と構成を容易にするため、 profile がサポートされている • profileにより、データベース・グループに対してI/Oリソースを割り当てる方法が導入 • profileは、データベース間プランのディレクティブとして指定され、CellCLIユーティリティを使用して構成される •

    profileディレクティブは、識別子(名前)と一連の属性で構成される • データベース・ディレクティブとprofileディレクティブを区別するために、typeと呼ばれる修飾子属性が使用される • type属性は、databaseまたはprofileに設定可能 IORM profileの使用 (1) Copyright © 2026, Oracle and/or its affiliates 261 Exadata 12.1.2.1.0 CellCLI> ALTER IORMPLAN DBPLAN=((name=gold, share=10, limit=100, type=profile), (name=silver, share=5, limit=60, type=profile), (name=bronze, share=1, limit=20, type=profile)) Oracle Database 12.1.0.2.4
  220. • profileを作成後、新規および既存のデータベースを、データベース間プランに定義されたprofileのいずれかにマップする • 各データベースの db_performance_profile 初期化パラメータを必要な profile の名前に設定 • データベースを再起動する必要がある

    • Oracle Database Resource Managerプランと同様に、IORM profile情報はすべてのストレージ・サーバーに自動的 にプッシュされる • 新しいデータベースを追加する場合、db_performance_profile パラメータを設定し、データベースを再起動する • データベース間プランを変更しなくても、データベースによって profile 属性が自動的に継承される • profile ディレクティブとデータベース・ディレクティブが混在するデータベース間プランを作成することも可能 • LIST IORMPROFILE コマンドで確認可能 IORM profileの使用 (2) Copyright © 2026, Oracle and/or its affiliates 262 SQL> ALTER SYSTEM SET db_performance_profile=gold SCOPE=spfile; SQL> SHUTDOWN IMMEDIATE SQL> STARTUP Exadata 12.1.2.1.0 Oracle Database 12.1.0.2.4
  221. 注意点 • Oracle Database 19c以降、db_performance_profile初期化パラメータは動的であるため、変更は即時有効 • 以前のOracle Databaseバージョンでは、パラメータ設定を有効にするためにデータベース再起動が必要 • type属性を指定しない場合、ディレクティブはdatabaseディレクティブにデフォルト設定される

    • データベース間プランで指定できるのは、8つのprofileディレクティブと1024のデータベース・ディレクティブのみ • profileディレクティブでは、level、allocation、roleを指定することはできない • OTHERとDEFAULTという単語は予約語。profile名をOTHERまたはDEFAULTにすることはできない • type属性は、カテゴリ・プランでは指定できない • profileは、カテゴリ・プランととともに指定することはできない • 複数のデータベースがOTHERディレクティブにマップされる場合、Storage Serverは、それらのデータベースに Database Resource Managerを使用しない。この場合は、すべてのI/Oリクエストが同等に処理される IORM profileの使用 (3) Copyright © 2026, Oracle and/or its affiliates 263 Exadata 12.1.2.1.0 Oracle Database 12.1.0.2.4
  222. データベース内のデータベース・リソース管理(1) • データベースに多くのタイプのワークロードがあり、ワークロードは、パフォーマンス要件および発行されるI/Oの量が異なる場合がある • データベース・リソース管理はデータベース・レベルで構成される • この場合は、Oracle Database Resource Managerを使用してデータベース・リソース・プランを作成

    • 1つのデータベース内に複数のタイプのワークロードがある場合は、この機能を使用 • これらのワークロードでデータベース・リソースの割当てを共有する方法を指定するポリシーを定義可能 • 1つのデータベースでのみOracle Exadata Storage Serverリソースを使用している場合、必要なリソース管理機能はDatabase Resource Managerのみ 264 Copyright © 2026, Oracle and/or its affiliates
  223. データベース内のデータベース・リソース管理(2) Database Resource Managerで各データベース実行可能なタスク • Database Resource Managerで各データベース実行可能なタスク ① リソース・コンシューマ・グループの作成

    ② コンシューマ・グループへのユーザー・セッションのマップ ③ CDBリソース・プランの作成 ④ リソース・プランの作成 ⑤ リソース・プランの有効化 265 Copyright © 2026, Oracle and/or its affiliates
  224. データベース内のデータベース・リソース管理(3) Database Resource Managerで各データベース実行可能なタスク ① リソース・コンシューマ・グループの作成 - 特定のワークロードを構成するセッションをグループ化 • たとえば、データベースで4つの異なるアプリケーションが実行されている場合、4つのコンシューマ・グループを作成して、各アプリケーションに1つず

    つ使用可能 - 例:データ・ウェアハウスにクリティカルな問合せ、通常の問合せ、ETL(抽出、変換およびロード)、の3つのタイプのワークロードがある場合、各 タイプのワークロードにコンシューマ・グループを作成可能 ② コンシューマ・グループへのユーザー・セッションのマップ - コンシューマ・グループを作成したら、コンシューマ・グループにセッションをどのようにマップするかを指定するルールを作成 - Database Resource Managerでは、Oracleユーザー名、データベースとの接続にセッションで使用されたサービス、クライアント・マシン、クライアント のプログラム名、クライアントのユーザー名など、各アプリケーションにコンシューマ・グループを作成しており、各アプリケーションに専用のサービスがあ る場合は、サービス名に基づいてマッピング・ルールを作成 - コンシューマ・グループを特定のユーザー・セットに指定する場合 • ユーザー名に基づいてマッピング・ルールを作成してください。 - コンシューマ・グループに明示的に割り当てられていないセッションは、OTHER_GROUPSコンシューマ・グループに配置 ③ CDBリソース・プランの作成 ④ リソース・プランの作成 ⑤ リソース・プランの有効化 266 Copyright © 2026, Oracle and/or its affiliates
  225. データベース内のデータベース・リソース管理(4) Database Resource Managerで各データベース実行可能なタスク ① リソース・コンシューマ・グループの作成 ② コンシューマ・グループへのユーザー・セッションのマップ ③ CDBリソース・プランの作成

    - 同一のコンテナに関連付けられている様々なPDB間でCPU、I/Oリソースを割り当てる方法を指定 - Database Resource Managerを使用して作成 - CDBプランには、各PDBのディレクティブが含まれる • ディレクティブは、そのPDBに割り当てられているshares数を定義 • shares数は、プランの他のPDBと比較したときの、そのPDBの相対的な優先度を定義 - PDBの最大使用率制限を指定可能 - 各PDB毎にmemory_minおよびmemory_limitも指定可能 • PDBごとに様々なExadataストレージ・キャッシュ(Flash Cache、XRMEM Cache)割当て制限を定義するパラメータ • データベース・インスタンスのメモリー・サイズ設定には影響しない ④ リソース・プランの作成 ⑤ リソース・プランの有効化 267 Copyright © 2026, Oracle and/or its affiliates
  226. データベース内のデータベース・リソース管理(5) Database Resource Managerで各データベース実行可能なタスク ④ リソース・プランの作成 - データベースのリソース・プランはデータベース内リソース・プランとも呼ばれ、データベースのコンシューマ・グループ間でCPUとI/Oリソースをどのように 割り当てるかを指定 -

    リソース・プランはDatabase Resource Managerを使用して作成 • 各コンシューマ・グループに対するリソース割当てディレクティブが含まれており、allocation とlevelで構成 • 最大8つのlevelまで指定可能 - level2のコンシューマ・グループでは、level1で割り当てられなかったリソースや、level1のコンシューマ・グループによって使用されなかったリソース が取得される - level3のコンシューマ・グループには、level1および2の割当てが一部残っている場合にのみリソースが割り当てられる - リソース・プランには、各コンシューマ・グループのリソース割当てのディレクティブが含まれ、allocationおよびlevelで構成される - 複数のlevelで優先度付けできるだけでなく、プライマリおよび残りのすべてのリソースをどのように使用するかを明示的に指定することも可能 • allocation、優先度、またはallocationと優先度を組み合せてコンシューマ・グループ間でリソースを割り当てるリソース・プランを構成可能 - コンシューマ・グループの最大使用率制限を指定することも可能 • データベースの最大使用率制限と同じように動作し、コンシューマ・グループのI/O使用率を指定した値に制限 - CDBプラン以外にも、PDBごとにリソース・プランを作成することにより、PDB内で実行されているワークロードを管理することも可能 • PDBでサポートされるのは、最大8つのコンシューマ・グループが含まれる単一levelのプランのみ ⑤ リソース・プランの有効化 - RESOURCE_MANAGER_PLAN初期化パラメータを使用して有効化 268 Copyright © 2026, Oracle and/or its affiliates
  227. データベース内のデータベース・リソース管理(6) • データベースでデータベース・リソース・プランを設定すると、プランの内容が各ストレージサーバーに自動的に送信 • Exadataで稼働するOracle RACデータベースの場合は、 Oracle RACクラスタのすべてのインスタンスを同じリソース・プランに設定する必要がある • 新規ストレージサーバーの追加または既存のストレージサーバーの再起動を行うと、

    データベースの現在のプランがストレージサーバーに自動的に送信される • リソース・プランは、データベース・サーバーおよびストレージ・サーバーの両方のリソース管理に使用される • バックグラウンドI/Oは、ユーザーI/Oに対する優先度に基づいてスケジュール設定される • 例: - REDO書込み、制御ファイルの読取り・書込み:パフォーマンスにとって重要なため、すべてのユーザーI/Oよりも常に優先される - データベース・ライター・プロセス(DBWR)の書込み:ユーザーI/Oと同じ優先度レベルでスケジュール設定される • データベースでリソース・プランが有効になっていない場合、すべてのユーザーI/Oは同等に処理され、 バックグラウンドI/Oは前述の通りユーザーI/Oに対する優先度に基づいて処理される • 事前定義済みのプラン。一般的に使用されるプラン - MIXED_WORKLOAD_PLAN :バッチ操作よりも対話型操作を優先させる複合ワークロード・プラン - DSS_PLAN :重要ではないDSS問合せやETL操作よりも重要なDSS問合せを優先させるデータ・ウェアハウス・プラン - DEFAULT_MAINTENANCE_PLAN :メンテナンス・ウィンドウのデフォルト・プラン 269 Copyright © 2026, Oracle and/or its affiliates
  228. コンシューマ・グループとリソース・プランについて データベース内のデータベース・リソース管理 • Exadataには、Exadata System Softwareを使用する データ・ウェアハウス専用のデフォルトのコンシューマ・グループ、リソース・プランが付属 • リソース・プランは、現在の環境の要件にあわせて変更可能 •

    データ・ウェアハウス用のコンシューマ・グループ • ETL_GROUP: ETL(抽出、変換およびロード)ジョブ用のコンシューマ・グループ • DSS_GROUP: クリティカルではない意思決定支援システム(DSS)の問合せ用のコンシューマ・グループ • DSS_CRITICAL_GROUP: クリティカルなDSS問合せ用のコンシューマ・グループ • データ・ウェアハウス用のリソース・プラン • DSS_PLANリソース・プラン - クリティカルではないDSS問合せおよびETLジョブよりもクリティカルなDSS問合せを優先するデータ・ウェアハウス用に設計 • ETL_CRITCAL_PLANリソース・プラン - DSS問合せよりもETLが優先 270 Copyright © 2026, Oracle and/or its affiliates
  229. DSS_PLANリソース・プラン クリティカルではないDSS問合せおよびETLジョブよりもクリティカルなDSS問合せを優先するデータ・ウェアハウス用 • SYS_GROUPが最高の優先度 • 次にDSS_CRITICAL_GROUP、DSS_GROUPが続く • DSS_CRITICAL_GROUPグループには、level2で75%のみが割り当て • 未使用の割当ては、同じlevelの他のコンシューマ・グループではなく、すべて次のlevelに付与

    - つまり、DSS_CRITICAL_GROUPグループで割当てが完全に使用されない場合、その割当ては同じlevelのORA$DIAGNOSTICSグループやORA$AUTOTASK_SUBPLANグループには付与されないかわりに、 割当てはlevel3のDSS_GROUPグループに付与 • その次にETL_GROUPとBATCH_GROUPの組合せ • 帯域幅のすべてを使用できるコンシューマ・グループは無い 271 Copyright © 2026, Oracle and/or its affiliates コンシューマ・グループ level1 (%) level2 (%) level3 (%) level4 (%) SYS_GROUP 75 未設定 未設定 未設定 DSS_CRITICAL_GROUP 未設定 75 未設定 未設定 DSS_GROUP 未設定 未設定 75 未設定 ETL_GROUP 未設定 未設定 未設定 45 BATCH_GROUP 未設定 未設定 未設定 45 ORA$DIAGNOSTICS 未設定 5 未設定 未設定 ORA$AUTOTASK_SUB_PLAN 未設定 5 未設定 未設定 OTHER_GROUPS 未設定 未設定 未設定 10
  230. ETL_CRITICAL_PLANリソース・プラン ETL_CRITICAL_PLANでは、DSS問合せよりもETLが優先 • このプランでは、SYS_GROUPグループに帯域幅の75%が割り当て • 残りの帯域幅は、level2の割当てで指定される割合に基づいて、他のコンシューマ・グループ間で分割されます。 • ETL_GROUPとDSS_CRITICAL_GROUPグループの割当て(35%)は、 DSS_GROUPおよびBATCH_GROUPグループの割当て(10%)より多い 272

    Copyright © 2026, Oracle and/or its affiliates コンシューマ・グループ level1 (%) level2 (%) level3 (%) level4 (%) SYS_GROUP 75 未設定 未設定 未設定 DSS_CRITICAL_GROUP 未設定 35 未設定 未設定 DSS_GROUP 未設定 10 未設定 未設定 ETL_GROUP 未設定 35 未設定 未設定 BATCH_GROUP 未設定 10 未設定 未設定 ORA$DIAGNOSTICS 未設定 3 未設定 未設定 ORA$AUTOTASK_SUB_PLAN 未設定 3 未設定 未設定 OTHER_GROUPS 未設定 3 未設定 未設定
  231. CDBプランとプラガブル・データベースについて データベース内のデータベース・リソース管理 • CDBでは、リソースについて競合する複数のPDB内に、複数のワークロードを使用可能 • CDBは、多数のユーザー定義のPDBをサポート。CDBでは、リソースは次のレベルで管理 • CDBレベル: Database Resource

    Managerを使用して、システム・リソースおよびCDBリソースを巡って競合関係にある複数のPDBのワークロードを管 理 - 管理者は、PDBへのリソースの割当て方法を指定し、特定のPDBのリソース使用率を制限可能 • PDBレベル: Database Resource Managerを使用して、各PDB内のワークロードを管理 • 以下例では、SALES、SERVICES、HRという3つのPDBのCDBプランの概要を示す • PDBは、そのCDBプラン内でそれぞれ異なるshares数およびutilization_limit(最大使用率制限)が使用される • PDBにディレクティブを明示的に定義しない場合、PDBではPDB用のデフォルト・ディレクティブが使用 273 Copyright © 2026, Oracle and/or its affiliates PDB名 sharesのためのディレクティブ utilization_limitのためのディレクティブ memory_min memory_limit SALES 3 無制限 20 未設定 SERVICES 3 無制限 20 未設定 HR 1 70 未設定 50 ディレクティブ属性 値 shares 1 utilization_limit 100
  232. コンシューマ・グループおよびカテゴリの設定 データベース内のデータベース・リソース管理 • コンシューマ・グループおよびカテゴリは、PL/SQL DBMS_RESOURCE_MANAGERパッケージのプロシージャを使用して設定 • 新規のコンシューマ・グループおよびカテゴリを作成するか、事前定義済のコンシューマ・グループまたはカテゴリのいずれかを使用することが可能。 • カテゴリ・プランを使用する予定がない場合は、カテゴリ設定は不要 -

    注:現在はCATPLANは非推奨なので、カテゴリ設定は不要、コンシューマグループを利用する • ノート:コンシューマ・グループおよびカテゴリはデータベースに作成されるが、ストレージサーバーに明示的に作成することはできない • コンシューマ・グループとカテゴリを管理するためのDBMS_RESOURCE_MANAGERプロシージャを実行する前に、最初にペンディング・エリアを作成する必要 がある • DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを実行するには、 システム権限のADMINISTER_RESOURCE_MANAGERが必要 • 次のPL/SQLコマンドは、コンシューマ・グループおよびカテゴリで使用 • カテゴリを管理する場合:CREATE_CATEGORY()、DELETE_CATEGORY()、UPDATE_CATEGORY() • コンシューマ・グループを管理する場合:CREATE_CONSUMER_GROUP()、UPDATE_CONSUMER_GROUP() • カテゴリにコンシューマ・グループを割り当てる場合:CREATE_CONSUMER_GROUP()、UPDATE_CONSUMER_GROUP() • データベースには、各自で設定したコンシューマ・グループの他に、事前定義済のコンシューマ・グループも含まれる。 • DBA_RSRC_CONSUMER_GROUPSビューには、コンシューマ・グループに関する情報が表示される、 DBA_RSRC_CATEGORIESビューには、データベース内のカテゴリに関する情報が表示される 274 Copyright © 2026, Oracle and/or its affiliates
  233. コンシューマ・グループおよびカテゴリの設定 データベース内のデータベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_CATEGORY( CATEGORY => 'dss', COMMENT =>

    'DSS consumer groups'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP( CONSUMER_GROUP => 'critical_dss', CATEGORY => 'dss', COMMENT => 'performance-critical DSS queries'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP( CONSUMER_GROUP => 'normal_dss', CATEGORY => 'dss', COMMENT => 'non performance-critical DSS queries'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP( CONSUMER_GROUP => 'etl', CATEGORY => 'maintenance', COMMENT => 'data import operations'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / • データベースにコンシューマ・グループとカテゴリの設定例 • MAINTENANCEカテゴリが事前定義されるが、この 例では作成されない 275 Copyright © 2026, Oracle and/or its affiliates
  234. コンシューマ・グループおよびカテゴリの設定 データベース内のデータベース・リソース管理 SQL> SELECT consumer_group, category FROM DBA_RSRC_CONSUMER_GROUPS where consumer_group

    not like 'ORA%' ORDER BY category; CONSUMER_GROUP CATEGORY ------------------------------ ----------------------------- - SYS_GROUP ADMINISTRATIVE ETL_GROUP BATCH BATCH_GROUP BATCH DSS_GROUP BATCH CRITICAL_DSS DSS NORMAL_DSS DSS DSS_CRITICAL_GROUP INTERACTIVE INTERACTIVE_GROUP INTERACTIVE ETL MAINTENANCE LOW_GROUP OTHER OTHER_GROUPS OTHER AUTO_TASK_CONSUMER_GROUP OTHER DEFAULT_CONSUMER_GROUP OTHER 13 rows selected • DBA_RSRC_CONSUMER_GROUPSビュー • CRITICAL_DSS、NORMAL_DSS、ETL、の コンシューマ・グループが作成 276 Copyright © 2026, Oracle and/or its affiliates
  235. コンシューマ・グループへのセッションの割当て データベース内のデータベース・リソース管理 BEGIN DBMS_SERVICE.CREATE_SERVICE('SALES', 'SALES'); DBMS_SERVICE.CREATE_SERVICE('AD_HOC', 'AD_HOC'); DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.ORACLE_USER,

    'SYS', 'CRITICAL_DSS'); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.SERVICE_NAME, 'SALES', 'CRITICAL_DSS'); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.SERVICE_NAME, 'AD_HOC', 'NORMAL_DSS'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP ( GRANTEE_NAME => 'PUBLIC', CONSUMER_GROUP => 'CRITICAL_DSS', GRANT_OPTION => FALSE); DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP ( GRANTEE_NAME => 'PUBLIC', CONSUMER_GROUP => 'NORMAL_DSS', GRANT_OPTION => FALSE); END; / • リソースのコンシューマ・グループにセッションを手動で割り当てるか、 コンシューマ・グループのマッピング・ルールを使用して自動で割り当てる ことが可能 • ユーザーにコンシューマ・グループを切り替えるための権限付与が必要 • ユーザーが切替え可能なコンシューマ・グループを制御する場合、 - DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP() プロシージャ • コンシューマ・グループのマッピング・ルール • セッション属性に基づく - ユーザー名、データベースとの接続にセッションで使用されたサービス名、 クライアント・プログラムの名前など • コンシューマ・グループのマッピング・ルールを作成する場合 - SET_CONSUMER_GROUP_MAPPINGプロシージャを使用 - SET_CONSUMER_GROUP_MAPPINGプロシージャを実行する前に、最 初にペンディング・エリア作成が必要(CREATE_PENDING_AREA) • セッションを特定のコンシューマ・グループに手動で切り替える場合 - DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_U SER() - DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_S ESS() 277 Copyright © 2026, Oracle and/or its affiliates
  236. CDBプランの作成 データベース内のデータベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN( plan => ''NEWCDB_PLAN ', comment

    => 'CDB resource plan for newcdb'); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'SALESPDB', shares => 3, memory_min => 20, utilization_limit => 100); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => ' NEWCDB_PLAN ', pluggable_database => 'SERVICESPDB', shares => 3, memory_min => 20, memory_limit => 75); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => ' NEWCDB_PLAN ', pluggable_database => 'HRPDB', shares => 1, memory_limit => 50, utilization_limit => 70); DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / • CDBプランの管理対象 • データベース・サーバーのCPUリソース • ストレージ・サーバーのフラッシュ・キャッシュ領域、I/O帯域幅 • 作成方法 • DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN() • DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIV E() • CDBプランは、ルートPDB以外から構成できない • 例 • SALESPDB、SERVICESPDB、HRPDB、3つのPDB間での リソース配分方法 • SALES、SERVICESは優先度が高い、 - HRのshares数が1であるのに対し、 SALESおよびSERVICESのshares数はそれぞれ3 • HR PDBでは、最大使用率制限(utlization_limit)が70%に設定 278 Copyright © 2026, Oracle and/or its affiliates
  237. データベース・プランの作成 データベース内のデータベース・リソース管理 • データベース・リソース・プランはデータベース内プランとも呼ばれる • 以下のプロシージャで作成 • DBMS_RESOURCE_MANAGER.CREATE_PLAN() • DBMS_RESOURCE_MANAGER.

    CREATE_PLAN_DIRECTIVE() • 作成方法 • CREATE_PENDING_AREA()を使用してリソース・プランの作成、更新を開始 • SUBMIT_PENDING_AREA()を使用してそれらを完了する • OTHER_GROUPSのディレクティブを含めることが必要 - OTHER_GROUPSには、コンシューマ・グループに明示的にマップされないすべてのセッションが保持 • DBMS_RESOURCE_MANAGER PL/SQLパッケージのプロシージャを実行する場合 • システム権限のADMINISTER_RESOURCE_MANAGERが必要 • リソース・プランは、データベース・インスタンスのCPUリソースおよびセルのI/Oリソースの両方を管理 279 Copyright © 2026, Oracle and/or its affiliates
  238. データベース・プランの作成(例) データベース内のデータベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_PLAN('DAYTIME_PLAN', 'Resource plan for managing all

    applications between 9 am and 5 pm'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('SALES', 'Sales App'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('FINANCE', 'Finance App'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('MARKETING', 'Marketing App'); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'SALES', 'Allocation for SALES', MGMT_P1 => 60); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'FINANCE', 'Allocation for FINANCE', MGMT_P1 => 25); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'MARKETING','Allocation for MARKETING', MGMT_P1 => 10); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'OTHER_GROUPS','Allocation for default group', MGMT_P1 => 5); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / 280 Copyright © 2026, Oracle and/or its affiliates • 例:複数のアプリケーション間でデータベースを共有し、I/Oリソースを特定の比率で各アプリケーションに割り当てる場合 • SALES、FINANCE、MARKETINGという名前の3つのアプリケーションがある • I/Oリソースを60%、25%、10%の割合でそれぞれ割り当て、これらのコンシューマ・グループにマップされないセッションに残りの5%を割り当て • このシナリオでは、各アプリケーションにコンシューマ・グループを作成し、単一レベルのリソース・プランを作成して、各コンシューマ・グループに割り当てる I/Oリソースの割合を指定 - この割当ては、実際はコンシューマ・グループで使用可能な最小のI/Oリソース • コンシューマ・グループで割当てが使用されなかった場合、その割当てはプランで指定した比率で他のコンシューマ・グループに再配分される • MGMT_P1パラメータを使用して、割当てを指定可能
  239. データベース・プランの作成(例) データベース内のデータベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_PLAN('DAYTIME_PLAN', 'Resource plan for prioritizing queries

    between 9 am and 5 pm'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('REPORT_QUERIES', 'Report Queries'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('AD-HOC_QUERIES', 'Ad-Hoc Queries'); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('DATA_LOAD', 'Data Load'); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'REPORT_QUERIES','Allocation for REPORT_QUERIES', MGMT_P1 => 75); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'AD-HOC_QUERIES','Allocation for AD-HOC_QUERIES', MGMT_P1 => 25); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'DATA_LOAD','Allocation for DATA_LOAD', MGMT_P2 => 100); DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE('DAYTIME_PLAN', 'OTHER_GROUPS','Allocation for default group', MGMT_P3 => 100); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / 281 Copyright © 2026, Oracle and/or its affiliates • 例:あるワークロードを別のワークロードよりも優先する場合 • 問合せの実行中にデータをデータ・ウェアハウスにロードする場合に、データ・ロードよりも問合せを常に優先するとする • このシナリオでは、クエリ用にコンシューマ・グループを2つ(レポートと非定型)作成し、データ・ロード用にコンシューマ・グループを1つ作成 • クエリ用の2つのコンシューマ・グループ間で、I/Oリソースを75:25の比率で共有するとする • クエリ用のコンシューマ・グループで割当てをすべて使用しない場合にのみ、データ・ロードのI/Oを発行する • リソース・プラン・レベルを使用して、割当て優先度を指定 - MGMT_P2:レベル2のリソース割当て値 - MGMT_P3:レベル3のリソース割当て値
  240. データベース・リソース・プランの有効化 データベース内のデータベース・リソース管理 • データベース・リソース・プランは、RESOURCE_MANAGER_PLANパラメータを設定することで手動で有効化可能 • リソース・プランでOracle Schedulerウィンドウを定義すると、リソース・プランを自動で有効化 • Oracle Schedulerウィンドウが開くと、リソース・プランが有効化

    • Oracle Schedulerウィンドウが閉じると、リソース・プランが無効化 • リソース・プランが有効になると、データベースからすべてのストレージサーバーにアラートが通知され、リソース・プランが提供される • リソース・プランが無効になる場合も、すべてのストレージサーバーにアラートが通知される • データベースではリソース・プランを1つしかアクティブにできないため、データベースのすべてのインスタンスで同じリソース・プランを有効に する必要がある • データベースでデータベース・リソース・プランが有効になっていない場合は、すべてのI/Oリクエストが同等に処理される 282 Copyright © 2026, Oracle and/or its affiliates
  241. [参考] 高速ファイル作成の管理(例) データベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('MAINTENANCE_GROUP', 'Maintenance activity'); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_FUNCTION, 'FASTFILECRE',

    'MAINTENANCE_GROUP'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / 283 Copyright © 2026, Oracle and/or its affiliates • Oracle Exadata System Softwareの高速ファイル作成機能では、データ・ファイルの初期化を高速化 • 表領域を新規作成、既存の表領域にデータ・ファイルを追加、または既存の表領域を自動拡張すると自動的に実行 • Exadataでは、多数のI/Oリクエストを同時に発行するため、ファイルの初期化を非常に高速化 • このような同時I/Oリクエストは高い負荷がかかり、パフォーマンスが重要となる問合せに影響を及ぼす可能性がある • I/Oリソース管理(IORM)を使用すると、新規の表領域を作成する場合や、既存の表領域にデータ・ファイルを追加する場合に高速ファイル作成の優先度を制御可能 • FASTFILECRE関数で実行 • デフォルトでは、FASTFILECRE関数は、すべてのコンシューマ・グループおよびバックグラウンドI/Oより優先度の低い非表示のコンシューマ・グループにマップされる • ファイル作成の優先度を高くしてパフォーマンスを向上する場合、 マッピング属性DBMS_RESOUCRE_MANAGER.ORACLE_FUNCTIONと、マッピング値FASTFILECREに基づくマッピング・ルールをPDBで追加 • 既存の表領域の自動拡張は簡単だが、多くの場合はタイムクリティカルな操作のため、IORMを使用して優先度を変更することは不可能
  242. [参考] データのインポート管理(例) データベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.CLIENT_PROGRAM, 'SQLLDR', 'ETL_GROUP'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

    END; / 284 Copyright © 2026, Oracle and/or its affiliates • IORMでは、ETLの優先度だけでなく、ETLで使用されるI/Oリソースの量も制御可能 • データのインポート、または抽出、変換およびロード(ETL)は、データ・ウェアハウスのメンテナンスの重要な部分 • レポートや問合せはデータがロードされるまで実行できないため、ETLがパフォーマンスにとって非常に重要になる場合がある • このような場合は、ETLが他のすべての問合せよりも優先するようにする • 他の場合は、ETLは優先度の低いバックグラウンド処理であり、特定の時刻までに完了しないという稀な事態においてのみ優先される必要がある場合がある • ETLの管理方法 • ETLセッションをETL_GROUPコンシューマ・グループにマップ • ETLのマッピング・ルールは、通常はユーザー名またはクライアント・プログラム名に基づく • データ・ポンプは、DATALOAD関数で実行 • DATALOAD関数は、デフォルトでETL_GROUPコンシューマ・グループにマップ • リソース・プランにETL_GROUPグループを含めます。 • 非圧縮データを圧縮データとしてインポートする方法 • 例:ETL_GROUPコンシューマ・グループにプログラムをマップする方法 • 圧縮データとしての非圧縮データのインポート • デフォルトでExadataハイブリッド列圧縮表として新規表を作成するようにターゲット表領域が構成されている場合 - TRANSFORM:SEGMENT_ATTRIBUTES=nオプションを使用すると、非圧縮データを圧縮データとしてインポート可能
  243. [参考] Oracle Recovery Managerのバックアップおよびコピーの管理(例) データベース・リソース管理 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_FUNCTION, 'BACKUP', 'BATCH_GROUP');

    DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.ORACLE_FUNCTION, 'COPY', 'MAINTENANCE_GROUP'); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / 285 Copyright © 2026, Oracle and/or its affiliates • IORMを使用すると、RMAN I/Oのリソースの消費と優先順位を制御可能 • バックアップはI/O集中型の操作になる • RMANのI/Oの比率は、チャネル数を設定して制御可能 • IORMは、RMAN I/Oのリソースの消費と優先順位をより細かく制御するために使用可能 • RMANを優先度の低いコンシューマ・グループにマップすることにより、 - Storage Serverがビジーになった場合:RMAN操作の実行速度が大幅に低下するため、他のデータベース操作に影響を及ぼすことがなくなる - Storage Serverが十分に使用されていない場合:未使用の帯域幅をRMANのI/Oが使用できるようにIORMによってスケジュール調整される • RMANのバックアップはBACKUP関数で実行 • RMANのコピーはCOPY関数で実行 • デフォルトは、BACKUP関数とCOPY関数の両方ともBATCH_GROUPコンシューマ・グループにマップ • これらの関数は、例に示すように他のコンシューマ・グループに再マップ可能
  244. データベースおよびPDBのためのXRMEMキャッシュ割当て制限の管理(2) ①XRMEMCACHEをCDBデータベース内プランのみで設定する場合 • CDB(NEWCDB)のデータベース内リソース・プランの例(右) • プランに記載されている3つのPDBに memory_minとmemory_limitを指定 - 注意点 •

    memory_minとmemory_limitの値は、0~100のパーセンテージで指定 - オーバー・プロビジョニングがサポートされているため、パーセンテージの合 計は100%には制限されない - 値の合計が100%を超える場合、値はパーセンテージへと正規化される。 • memory_minが指定されていない場合は、デフォルト0に設定 • memory_limitが指定されていない場合は、デフォルト100に設定 • CDB$ROOT用には、5%のmemory_limit値がある - memory_min値合計は40%(20+20+0) - memory_limit値の合計は175%)(100+50+25)、正規化必要 - データベース間プランが指定されていない場合 • これらのパーセンテージがXRMEMキャッシュのサイズ全体に適用 - データベース間プランが指定されている場合 • PDBの割当て制限は、データベース間プランのディレクティブで指定された データベース用のxrmemcacheminとxrmemcachesize値のパーセンテージと して計算 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN( plan => 'NEWCDB_PLAN', comment => 'CDB resource plan for newcdb'); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'SALESPDB', memory_min => 20); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'SERVICESPDB', memory_min => 20, memory_limit => 50); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'HRPDB', memory_limit => 25); DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END; / 287 Copyright © 2026, Oracle and/or its affiliates
  245. データベースおよびPDBのためのXRMEMキャッシュ割当て制限の管理(3) ①XRMEMCACHEをCDBデータベース内プランのみで設定する場合 PDB XRMEMキャッシュの最小 memory_min XRMEMの弱い制限 memory_limit 正規化済の弱い制限 XRMEMの強い制限 SALESPDB

    1.25 TB x 20% = 256 GB 100 (非設定なのでデフォルト 値の100) 100 / 175 * 1.25 TB = 731 GB 該当なし SERVICESPDB 1.25 TB x 20% = 256 GB 50 50 / 175 * 1.25 TB = 366 GB 該当なし HRPDB 0 25 25 / 175 * 1.25 TB = 183 GB 該当なし 288 Copyright © 2026, Oracle and/or its affiliates 略 DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'SALESPDB', memory_min => 20); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'SERVICESPDB', memory_min => 20, memory_limit => 50); DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'NEWCDB_PLAN', pluggable_database => 'HRPDB', memory_limit => 25); 略 • IORM DBPLANを指定せず、XRMEMキャッシュのサイズが1.25 TBの場合で、 memory_limitの値の合計が100%を超えたために制限を正規化した後の割当て 制限の内訳は下記の表の通り • 正規化後、最小値が対応する制限より大きくなった場合は、最小値は制限と等 しくなるように減らされる
  246. データベースおよびPDBのためのXRMEMキャッシュ割当て制限の管理(4) ②XRMEMCACHEをCDBデータベース内プランとIORM DBPLANで設定する場合 データベース名 share XRMEM Cache の最 小使用量 xrmemCacheMin

    XRMEM Cache の最 大使用量 (soft limit) xrmemCacheLimit XRMEM Cache の最 大使用量 (hard limit) xrmemCacheSize Flash Cache の 最小容量 flashCacheMin Flash Cache の 最大容量 (soft limit) flashCachLimit Flash Cache の 最大容量 (hard limit) flashCacheSize newcdb 8 200G 10G finance 8 100G 200G 10G 2G dev 2 1G 10G 4G 1G test 1 289 Copyright © 2026, Oracle and/or its affiliates ALTER IORMPLAN dbplan= ((name=newcdb, share=8, xrmemCacheSize= 200G, flashCacheSize=10G), (name=finance, share=8, xrmemCacheMin= 100G, xrmemCacheLimit= 200G, flashCacheLimit=10G, flashCacheMin=2G), (name=dev, share=2, xrmemCacheMin= 1G, xrmemCacheLimit= 10G, flashCacheLimit=4G, flashCacheMin=1G), (name=test, share=1)) • データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するCDBプランの設定を制約する • データベース間IORMプラン・ディレクティブでデータベースのxrmemCacheMinおよびxrmemCacheSize設定が指定されている場合、 CDBプランでPDB固有のmemory_min割当て制限はxrmemCacheMin設定の一部になり、PDB固有のmemory_limit値はxrmemCacheSizeの一部になる • データベース間IORMプラン・ディレクティブでxrmemCacheMinを指定せずにxrmemCacheSizeが指定されている場合、 PDB固有のmemory_min設定は無視されるが、memory_limit設定は引き続きxrmemCacheSizeの一部になる。 • newcdbのデータベース間IORMプランの例では、xrmemCacheMinなしでxrmemCacheSizeが指定されているため、CDBプランでPDB固有のmemory_min割当て制限が無視され る。 • 次のページに、CDBプランの例をデータベース間IORMプランの例とともに適用した場合の有効なXRMEMキャッシュ制限を示す
  247. データベースおよびPDBのためのXRMEMキャッシュ割当て制限の管理(5) ②XRMEMCACHEをCDBデータベース内プランとIORM DBPLANで設定する場合の、PDBのXRMEMキャッシュの制限 290 Copyright © 2026, Oracle and/or its

    affiliates • CDBプランの例をデータベース間IORMプランの例とともに適用した場合の有効なXRMEMキャッシュ制限 • 非CDBデータベースでは、xrmemCacheSize、xrmemcacheminおよびxrmemcachelimitの値は絶対値として指定され、追加の正規化は必要ありません。xrmemcacheminは保 証付きの予約であるため、xrmemcacheminの合計は、すべてのディレクティブ全体でXRMEMキャッシュの合計サイズより小さくする必要があり PDB XRMEMキャッシュの最小 memory_min XRMEMの弱い制限 memory_limit 正規化済の弱い制限 XRMEMの強い制限 SALESPDB 0 100 (デフォルト) 100 / 175 * 200 GB = 114.29 GB 該当なし SERVICESPDB 0 50 50 / 175 * 200 GB = 57.14 GB 該当なし HRPDB 0 25 25 / 175 * 200 GB = 28.57 GB 該当なし
  248. • Exadata Database Machineが1つのデータベースのみをホストする場合、 • データベース間プランは不要 • データベース間のプランが指定されていない場合、 • すべてのデータベースで割当てが同じになる

    • OTHERディレクティブにマップされるデータベースが1つしかなく、他のすべてのデータベースに明示的なディレクティブがある場合、 • Exadata System Softwareは、そのデータベースのデータベースリソースプランを使用して、OTHERデータベースの割り当てがその データベース内のコンシューマグループ間でどのように再配分されるかを決定 • 複数のデータベースがOTHERディレクティブにマップされる場合、 • Oracle Exadata System Softwareは、それらのデータベースにDatabase Resource Managerを使用しない。 • この場合は、すべてのI/Oリクエストが同等に処理される • shareベースのプランでは、プランで明示的に名前が指定されていない場合でも、各データベースで独自のディレクティブを取得 • Exadata System Softwareでは、データベースのデータベース・リソース・プランを使用して、データベースのコンシューマ・グループ間 で割当てをどのように配分するかを決定する データベース間のリソース・プランの管理のヒント(1) Copyright © 2026, Oracle and/or its affiliates 291
  249. • データベース間のプランのディレクティブは、データベースのDB_UNIQUE_NAMEを識別子として使用 • DB_UNIQUE_NAME値自体では、大文字と小文字は区別されない • ただし、同じOracle RACデータベースの複数のインスタンスでDB_UNIQUE_NAMEに使用される文字の大文字と小文字の区別が 一貫していない場合(PRODやprodなど)、IORMが正しく動作しないことがある。 • 各Oracle

    RACデータベース間でDB_UNIQUE_NAMEに使用される文字の大文字と小文字の区別が一貫していることを確認する こと • DB_UNIQUE_NAME値が指定されていない場合、 • DB_UNIQUE_NAME値はDB_NAMEから導出される。 • その場合は、Oracle RACデータベース全体でDB_NAME値に使用される文字の大文字と小文字の区別が一貫していることを確 認すること • 同じDB_UNIQUE_NAMEを持っているが、異なるOracle ASMクラスタに関連付けられているデータベースがある場合、 • Exadata System Software 19.1.0 以降では、asmcluster 属性を使用すると、ディレクティブの指定時に各データベースを一意に 識別可能 データベース間のリソース・プランの管理のヒント(2) Copyright © 2026, Oracle and/or its affiliates 292
  250. • データベース間IORMプラン・ディレクティブのキャッシュ制限は、対応するコンテナ・データベース(CDB)プランの設定を制 約する • データベース間IORMプラン・ディレクティブでデータベースのflashcacheminおよびflashcachesize設定が指定されて いる場合、 - CDBプランでPDB固有のmemory_min割当て制限はflashCacheMin設定の一部になり、 PDB固有のmemory_limit値はflashCacheSizeの一部になる •

    データベース間IORMプラン・ディレクティブでflashCacheMinを指定せずにflashCacheSizeが指定されている場合、 - PDB固有のmemory_min設定は無視されるが、memory_limit設定は引き続きflashCacheSizeの一部になる • CDBプラン内のPDB固有の割当て制限(memory_minおよびmemory_limit)とデータベース間IORMプラン内の XRMEMキャッシュ設定(xrmemCacheMinおよびxrmemCacheSize)の関係に関して、 Exadata RDMAメモリー・ キャッシュ(XRMEMキャッシュ)にも同じことが当てはまる データベース間のリソース・プランの管理のヒント(3) Copyright © 2026, Oracle and/or its affiliates 293
  251. I/Oリソース管理の構成の確認(1) • 以下のチェックリストを使用して、I/Oリソース管理(IORM)が正しく構成されていることを確認 • IORMを使用してデータベース内のI/Oリソースを管理する場合、次の基準が満たされていることを確認 - リソース・プランが有効化されている - すべてのデータベース・インスタンスで同じリソース・プランが有効化されている -

    スケジューラ・ウィンドウを使用してOracle Database Resource Managerを有効化すると、 すべてのデータベース・インスタンスで常に同じプランが有効化される • RESOURCE_MANAGER_PLANパラメータを使用してOracle Database Resource Managerを有効化する場合、 sid='*'を使用してすべてのデータベース・インスタンスにパラメータを設定 • リソース・プランのコンシューマ・グループごとに、リソース・プランにMGMT_P[1-8]ディレクティブが含まれている - 次の問合せを使用して、前述の基準が満たされているかどうかを確認可能 • 複数のデータベースのI/OリソースをIORMで管理する場合、データベース間プランが適切に構成されているかどうかを確認 - データベース間プランが構成されていない場合、CellCLIのALTER IORMPLANコマンドを使用してプランを構成 • 各アクティブ・データベースは、dbPlanパラメータに独自のディレクティブ保持が必要 294 Copyright © 2026, Oracle and/or its affiliates SELECT DECODE(count(*), 0, 'Intra-Instance IORM Plan Enabled', 'No Intra-Instance IORM Plan Enabled') status FROM gv$instance WHERE inst_id NOT IN (SELECT inst_id FROM gv$rsrc_plan WHERE cpu_managed = 'ON’); CellCLI> LIST IORMPLAN DETAIL
  252. I/Oリソース管理の構成の確認(2) • 以下のチェックリストを使用して、I/Oリソース管理(IORM)が正しく構成されていることを確認(続) • セッションが正しいコンシューマ・グループにマップされているかどうかを確認 - ワークロードの実行中に、次の問合せを実行 - 次の構成エラーが原因で、セッションが適切なコンシューマ・グループに存在していないことがある •

    権限の不足: セッションをいずれかのコンシューマ・グループに切り替えるには、そのコンシューマ・グループに切り替える権限がユーザーまたはロー ルに付与されている必要がある。次の問合せにより、すべてのコンシューマ・グループの権限が表示 - 次のコマンドを使用して、任意のセッションをコンシューマ・グループに切り替える権限を付与。 この例は、BATCH_GROUPに権限を付与する方法を示す。 295 Copyright © 2026, Oracle and/or its affiliates SELECT r.sid, c.consumer_group current_consumer_group FROM v$rsrc_session_info r, dba_rsrc_consumer_groups c WHERE r.current_consumer_group_id = c.consumer_group_id UNION SELECT sid, 'OTHER_GROUPS' from v$rsrc_session_info WHERE current_consumer_group_id = 0; SELECT grantee, granted_group FROM DBA_RSRC_CONSUMER_GROUP_PRIVS ORDER BY granted_group; EXEC dbms_resource_manager_privs.grant_switch_consumer_group ('public', 'BATCH_GROUP', FALSE);
  253. I/Oリソース管理の構成の確認(3) • 以下のチェックリストを使用して、I/Oリソース管理(IORM)が正しく構成されていることを確認(続) • セッションが正しいコンシューマ・グループにマップされているかどうかを確認 - 次の構成エラーが原因で、セッションが適切なコンシューマ・グループに存在していないことがある(続) • アクティブではないコンシューマ・グループ: 現在のリソース・プランに含まれていないコンシューマ・グループにセッションがマップされるか、手動で切り

    替えられると、そのセッションはデフォルトのコンシューマ・グループであるOTHER_GROUPSに切り替えられる。 - セッションがマッピング・ルールを使用してコンシューマ・グループに割り当てられている場合、次の問合せを使用して、マッピング・ルールにより選 択されたコンシューマ・グループ、使用されたマッピング属性、およびセッション開始時の本来のコンシューマ・グループを確認 - マップ済のコンシューマ・グループが元のコンシューマ・グループと異なる場合、マップ済のコンシューマ・グループはリソース・プランに含まれていな かったことになる • CellCLIを使用して、すべてのデータベースの各コンシューマ・グループで発行された大小のI/Oリクエストの数を表示 - アクティブなI/Oワークロードを保持する各コンシューマ・グループは、これらのメトリックのとおりに大小のI/Oリクエストを生成 296 Copyright © 2026, Oracle and/or its affiliates SELECT r.sid, r.mapped_consumer_group, r.mapping_attribute, c.consumer_group original_consumer_group FROM v$rsrc_session_info r, dba_rsrc_consumer_groups c WHERE r.orig_consumer_group_id = c.consumer_group_id; CellCLI> LIST METRICCURRENT CG_IO_RQ_LG, CG_IO_RQ_SM ATTRIBUTES name, metricObjectName, metricValue, collectionTime;
  254. I/Oリソース管理の構成の確認(4) • 以下のチェックリストを使用して、I/Oリソース管理(IORM)が正しく構成されていることを確認(続) • ワークロードの実行中に、I/O負荷が正しいコンシューマ・グループで管理されているかどうかを確認 - 次のCellCLIコマンドでは、すべてのデータベースの各コンシューマ・グループで発行された大小のI/Oリクエストの数が表示 • ワークロードを実行中は、各カテゴリ、データベース、およびコンシューマ・グループの実際のI/O使用率を問合せ -

    次のCellCLIコマンドは、Oracle Exadata Storage Serverで実行中の各データベースの大小I/O使用率のリスト • 出力はデータベースからの大小のリクエストによって使用されるディスク・リソースのパーセントを示したもの 297 Copyright © 2026, Oracle and/or its affiliates CellCLI> LIST METRICCURRENT CG_IO_RQ_LG, CG_IO_RQ_SM ATTRIBUTES name, metricObjectName, metricValue, collectionTime; CellCLI> LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM ATTRIBUTES name, metricObjectName, metricValue, collectionTime;
  255. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Top Database Consumers > Top Database by XX AWRを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 298
  256. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Top Database Consumers > Top Database by IO Requests、 Top Database by Requests - Details AWRを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 299 Top Databases by IO Requests • すべてのStorage Server でI/Oリクエスト数が最も多いデータベースの統計を提供 • リクエストをデバイス・タイプ(フラッシュまたはディスク)別およびサイズ(小または大)別に分類 Top Databases by Requests - Details • I/Oリクエストの平均レイテンシ(Latency)および平均キュー時間(Queue Time) • キュー時間( Queue Time )は、I/Oリクエストが関連するI/Oキューに費やす時間 • 長いキュー時間( Queue Time )は、IORMがI/Oを抑制していることを示す
  257. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Top Database Consumers > Top Database by IO Throughput、 Top Database by IO Requests per Cell AWRを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 300 Top Databases by IO Throughput • すべてのStorage Server でI/Oスループットが最大のデータベースの統計を提供 • スループットをデバイス・タイプ(フラッシュまたはディスク)別およびリクエスト・サイズ(小または 大)別に分類 Top Databases by IO Requests per Cell • 各Storage Server でI/Oリクエスト数が最も多いデータベースの統計を提供 • リクエストをデバイス・タイプ(フラッシュまたはディスク)別およびサイズ(小または大)別に分類 • データベースからのI/Oリクエストを処理するときに、Storage Server の動作が異なっている かどうかを簡単に判断可能
  258. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Top Database Consumers > Top Database by IO Requests per Cell - Details、 Top Database by IO Throughput per Cell AWRを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 301 Top Databases by IO Requests per Cell - Details • 各Storage ServerのI/Oリクエストの平均レイテンシ(Latency)および平均キュー時間 (Queue Time) • Storage Server のIORMの動作が異なっているかどうかを簡単に判断可能 Top Databases by Throughput per Cell • 各Storage ServerでI/Oスループットが最大のデータベースの統計を提供 • スループットをデバイス・タイプ(フラッシュまたはディスク)別およびリクエスト・サイズ(小または 大)別に分類 • データベースからのI/Oを処理するときに、 Storage Serverの動作が異なっているかどうかを 簡単に判断可能
  259. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Top Database Consumers > Top Database by IO Requests、 Top Database by IO Requests - Details 例 AWRを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 302 DB1 が全体の46% DB1 の10%はDiskアクセス すべてのDBで多くの場合 Queue Time は 1ms以下 すべてのDBで多くの場合 Queue Time は 1ms以下 DB1のFlashへの Large IOで 9.12msの例外 マルチテナント・コンテ ナ・データベース(CDB) の場合、 AWRレポートの統計 には、データベースに 関連付けられているす べてのI/Oが含まれる (すべてのプラガブル・ データベース(PDB)を 含む)
  260. データベース統計 統計 説明 Session total flash IO requests フラッシュに対する物理I/Oリクエストの合計数 Session

    IORM flash wait time フラッシュI/OリクエストのIORM待機時間の合計(マイクロ秒) (Session IORM flash wait time) / (Session total flash IO requests) フラッシュI/Oリクエストの平均IORM待機時間 PDB total disk IO requests ディスクに対する物理I/Oリクエストの合計数 PDB IORM disk wait time ディスクI/OリクエストのIORM待機時間の合計(マイクロ秒) (PDB IORM disk wait time) / (PDB total disk IO requests) ディスクI/Oリクエストの平均IORM待機時間 データベース統計を使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 303
  261. IORMデータベース間プランにリストされた各データベースからのI/O負荷に関する情報を提供 • objectType= IORM_DATABASE であるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • メトリックを表示するデータベースは、METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName 属性で指定 • I/O負荷に関連するメトリック(DB_FD_IO_LOADやDB_IO_LOADなど)については、CD_IO_LOADに関連する追加情報を参照

    • Exadata System Software 19.1.0以降、データベースで使用されるASMクラスタにASM-Scoped Securityを構成した場合、データベース名の先頭にASM クラスタ名が付く • cumulativeメトリックの場合は、様々なcollectionTime期間から値を減算することにより、特定の期間のメトリック値を算出できる • rateメトリックの場合は、メトリック値の期間は直前の1分間 • メトリックの説明では、Small IO は128 KB以下で、Large IOリクエストは128 KBを超えるもの • すべてのデータベースの累積メトリックは、カテゴリ、IORMまたはデータベース・リソースのプランが変更されるとゼロにリセットされる • データベース間プランのデータベース・メトリックの履歴を表示したい場合 • CDBの場合、データベース・メトリックの観測データには、データベース(関連付けられているすべてのPDBを含む)に関連付けられているすべてのI/Oが含む • たとえば、DB_FC_IO_BY_SECの値には、CDBによってホストされるすべてのPDBのPDB_FC_IO_BY_SECの値の合計が含まれる • ASMおよびデータベース間プランにリストされていない他のすべてのデータベースの観測データは、metricObjectName 値として_OTHER_DATABASE_を使 用してグループ化される データベース・メトリックを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 305 CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = IORM_DATABASE CellCLI> LIST METRICHISTORY WHERE objectType = 'IORM_DATABASE' AND metricValue != 0 ATTRIBUTES name, metricObjectName, metricValue, collectionTime
  262. IORMデータベース間プランにリストされたコンテナ・データベース(CDB)によってホストされる各PDBからのI/O負荷に関する情報を提供 • objectType= IORM_PLUGGABLE_DATABASE であるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • メトリックを表示するPDBは、METRICCURRENT オブジェクトおよび METRICHISTORY オブジェクトの

    metricObjectName 属性で指定される • PDB名は、CDB名とPDB名を連結した名前 • I/O負荷に関連するメトリック(PDB_FD_IO_LOAD や PDB_IO_LOAD など)については、CD_IO_LOADに関連する追加情報を参照 • Exadata System Software 19.1.0以降、データベースで使用されるASMクラスタにASM-Scoped Securityを構成した場合、データベース名の先頭にASM クラスタ名が付く • cumulative メトリックの場合は、様々な collectionTime 期間から値を減算することにより、特定の期間のメトリック値を算出 • rate メトリックの場合は、メトリック値の期間は直前の1分間 • メトリックの説明では、Small IO は128 KB以下で、Large IOリクエストは128 KBを超えるもの PDBメトリックを使用したIORMの監視 Copyright © 2026, Oracle and/or its affiliates 306 CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = IORM_PLUGGABLE_DATABASE
  263. • OLTPワークロードとDSSワークロードがStorage Serverを共有する場合は、low_latency またはhigh_throughput のいずれに対して最適化するかがIORMにより決定される • low_latency に対して最適化するには、Large IO リクエストの同時実行を減らしてI/O帯域幅が飽和しないようにする

    • high_throughput に対して最適化するには、各 Storage Serverで多くの同時 Large IO リクエストを処理し、最適化アルゴリズムの適用中にストレージをフルに使用できるよう にする • Storage Server に多くの同時 Large IO リクエストがある場合は、各I/Oは他のI/Oの後でキューに入れられるため、平均レイテンシが増加することがある • データベース、プラガブル・データベース(PDB)、コンシューマ・グループからのI/Oリクエストの使用率メトリックは、データベース、PDB、コンシューマ・グループがストレージ・サーバーを使 用した時間に対応 • Large IOリクエストは、Small IO リクエストよりも多くのストレージ・サーバーを使用 • 次のメトリックでIORM の最適化を決定 - CG_IO_UTIL_LG、CG_IO_UTIL_SM、PDB_IO_UTIL_LG、PDB_IO_UTIL_SM、CT_IO_UTIL_LG、CT_IO_UTIL_SM、DB_IO_UTIL_LG、DB_IO_UTIL_SM • データベース管理者は、 I/Oリソース割当てを設定した I/Oリソース使用量を比較することで、IORMの objective を low_latency またはhigh_throughput に対してチューニングする 必要があるかどうか、または balanced が最適かどうかを判断可能。IORMメトリック IORM_MODE は、メトリック値は1から3の範囲内でIORMのモードを示す • 1: IORM objective が low_latency に設定 • 2: IORM objective が balanced に設定 • 3: IORM objectieve が high_throughputに設定 • 1から2の間または2から3の間の値は、IORMの objective がメトリック期間中に変更されたことを示し、正確な値は指定目標への近接度を示す。ワークロードの組合せが絶え ず変化することも示す • IORM属性objectiveがBASICに設定されている場合、IORM_MODEには意味がなく無視される IORM使用率の監視 Copyright © 2026, Oracle and/or its affiliates 307 [root@jojocel01 ~]# cellcli -e LIST metricDefinition IORM_MODE detail name: IORM_MODE description: "I/O Resource Manager objective for the cell" fineGrained: Disabled metricType: Instantaneous objectType: CELL unit: Number [root@jojocel01 ~]# cellcli -e LIST metriccurrent IORM_MODE IORM_MODE jojocel01 0.0
  264. I/Oレイテンシ • IORMに問題がある場合は、通常、I/Oレイテンシが増加 • データベース待機イベント cell single block physical read

    、場合によってはデータベース待機イベント cell smart table scan のレイテンシが長くなる • これらのデータベース待機イベントに大きな影響があり、フラッシュまたはディスク・デバイスに関連付けられているストレージ・サーバーに対応するレイテ ンシがない場合、IORMがワークロードを抑制している可能性がある • IORMによるスロットル(抑制)が発生していることを確認する方法 • AWRレポートの Top Databases by Requests - Details セクションで、Queue Time 列を確認 - この列には、IORMがデータベースのIOリクエストに対する抑制に費やした平均時間が表示される • IORM待機時間のセル・メトリック(DB_IO_WT_SM_RQ、DB_IO_WT_LG_RQ、PDB_IO_WT_SM_RQ、PDB_IO_WT_LG_RQ、 CG_IO_WT_SM_RQ)を確認 • IORMデータベース統計およびAWRレポートを使用すると、I/Oワークロード全体を把握可能 • Exadataメトリックを使用して、各カテゴリ、データベース、コンシューマ・グループ別のI/O使用量をさらに把握可能 • 統計およびメトリックを分析することで、カテゴリ、データベース、PDB、コンシューマ・グループの中で、リソース割当てを使用していないものや、リソース割当 てを超えているものを把握可能 • 待機時間が短いかゼロの場合は、プラン割当てが十分 • 待機時間が長い場合、プラン割当てが不十分 • I/Oレイテンシが長いために待機時間が許容できないパフォーマンスになる場合は、 IORMプランを調整して割当てを増やすか、必要なI/Oリソースを提供するために追加のストレージ・サーバーが必要になる場合がある IORMを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 308
  265. iostatの使用 • ExaWatcher によって収集される iostat を使用して監視されるデバイス使用率、I/Oサービス時間統計は信頼できない • 参考 man iostat

    - svctm - The average service time (in milliseconds) for I/O requests that were issued to the device. Warning! Do not trust this field any more. This field will be removed in a future sysstat version. - 使用率の計算はI/Oサービス時間に依存するため、svctm も信頼できない • セル・ディスク、データベース、PDB、コンシューマ・グループの実際のI/O使用率を監視するには、対応するIORMメトリックを使用するこ と IORMを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 309
  266. IORM Settings > IORM Objective Managing the I/O Resource I/Oリソースの管理

    Add/Update IORM Configuration Copyright © 2026, Oracle and/or its affiliates 310
  267. IORM Settings > Inter-Database Plan > Share based Managing the

    I/O Resource I/Oリソースの管理 The Inter-Database Plan Copyright © 2026, Oracle and/or its affiliates 311 Fixed Size (flashCachSize) を空欄にして実行
  268. Exadata Flash IORM Database Metric Accessing Exadata Metrics Oracle Exadata

    Storage Server target type Copyright © 2026, Oracle and/or its affiliates 312
  269. I/O Distribution by Databases > IORM Settings > Workload Distribution

    by Databases > Flash Cache Space Usage > Current Flash Cache Space Usage for Top 5 Databases Exadataリソース使用率の表示 ストレージ・リソース / Exadata Storage Servers Workload Distribution by Databases Copyright © 2026, Oracle and/or its affiliates 313
  270. ソフトウェアによるハードウェア・リソースの干渉の極小化 Database レイヤー: Database Resource Management • 制御対象の一例 • CPU

    • アクティブ・セッション数 • パラレル・クエリの制御 Storage レイヤー: I/O Resource Management (Exadata Only) • I/O 帯域幅の制御 (Disk 帯域幅/Flash 帯域幅) • Flash 使用量の制御 • PMEM 利用制御 Network レイヤー: Network Resource Management (Exadata Only) Exadata のリソース管理テクノロジー メモリの制御 • SGA_TARGET • PGA_AGGREGATE_TARGET • PGA_AGGREGATE_LIMIT Copyright © 2026, Oracle and/or its affiliates 315
  271. • 重要なデータベースのメッセージについて優先的に処理 • LGWR I/O および、Cache Fusion に関して優先的に処理 • 上記以外のメッセージについての優先度は同じ

    • 完全に自動的かつ透過的に実施される • 利用条件 • Exadata: 11.2.3.3.0 以上 • GI / DB: 11.2.0.4 or 12.1.0.1 以上 • InfiniBand SW firmware 2.1.3-4 以降 • InfiniBand では VL(Virtual Lane) で実装 • RoCE では CoS (Class of Service, 802.1p)で実装 Exadata Network Resource Management Database Server RoCE Network Exadata Storage Servers PRIORITY LANE Copyright © 2026, Oracle and/or its affiliates 316 Exadata 11.2.3.3.0 ~
  272. Oracle Linux KVM と Multitenant • VM は独立性は優れているが、効率や管理性は乏しい • VM

    は独立した OS,メモリ、CPU をもちそれぞれ個別 にパッチ適用が必要 • データベース管理者、システム管理者の信頼なしに 分離 • 一つの OS 上でのデータベース統合は効率がいいが独立 性に乏しい • DB Resource Manager はオーバーヘッドなく動的にリ ソースを割り当てられる • データベースには全体管理できる DBA が必要 • VM と DB統合を組み合わせるのが最適な方法 • VM 中でマルチテナントを含む DB 統合を併用する • リソース(CPU、メモリ、パッチ)を分断した際に発生 するオーバーヘッドを削減する目的と、管理性を煩 雑にしない目的でサーバ上のVM数は多くしない (KVM host あたり 最大 12 VM まで) 【参考】Exadata で実現可能な統合 効率 独立性 VM Database Multitenant 1つのサーバー上に 複数 DBを置く VM (KVM guest) DB ごとに専用 サーバー VM VM Copyright © 2026, Oracle and/or its affiliates 318 Exadata 19.3.0 ~
  273. • Exadata ハードウェア内でスナップショット機能をネイティブサポート • グリッド・ディスクとディスク・グループで新たに ‘Sparse’ に関する属性を サポート • 「Sparse

    な (コピーオンライト形式の)」 スナップショット DB/PDB の作成が可能 • ストレージ使用量を最適化 • クローンの迅速な作成 • DB/PDB の両方をサポート • 単一コマンドで(ファイルとしてだけではなく)データベースとしてのクローンまで完了 (PDB の場合) • Exadata 特有の機能をすべて使用可能 (Smart Scan、Smart Flash Cache、 Smart Flash Log、HCC など) • Grid Infrastructure および Oracle Database は 12.1.0.2.0 BP5 以降が必要 • 開発・テストデータベース用 • 本番環境では使用しないこと Oracle Exadata Snapshots Exadata X3 以降が必要 Exadata プライマリ テスト マスター John Test DB JaneT est DB Jim Dev DB スタンバイ スナップショットDB Copyright © 2026, Oracle and/or its affiliates 319 Exadata 12.1.2.1.0 ~
  274. 階層型 Snapshots • 既に作成済みの snapshot データベースから snapshot を作成する • シンタックスやテクノロジーは以前から変更なし

    • PDB, non PDB の両方で動作 • ユースケース例 • 夜間にビルドされた開発用のDB をリリースする用途 • テスターが Bug をチェックするために snapshot を作成 • テスターが snapshot の snapshot を作成 • テスターが開発者に分析のために新規のコピーを渡す • Snapshot の Sparse バックアップ • RMAN により更新 block と親 DB からの未更新のblock のバックアップを取得することが出来る • Oracle Grid Infrastructure および Oracle Database は 12.2 以降が必要 Oracle Exadata Snapshots Test Snapshot Snapshot to Dev Nightly Master Exadata X3 以降が必要 Copyright © 2026, Oracle and/or its affiliates 320 Exadata 12.2.1.1.0 ~
  275. • ILOM ハングの予防措置のため Exadata 11.2.3.3.0 以降では 90 日ごとに Storage Server

    ILOM に対して 定期的なリセットが行われます。 • 本機能の無効化や次回のリセット時間や間隔の変更はできません • Storage Server の ILOM ポートを監視ツール等から個別に死活監視している場合、全 Storage Server から 一斉に ILOM ポート障害のアラートが上がることがありますため、監視間隔を調整する等必要に応じてご検討頂く 必要もあります • DB Server 上の MS でも Exadata 12.1.2.1.0 以降は DB Server の ILOM に対して定期的なリセットが行われます 定期的な自動 ILOM リセット機能 Exadata 11.2.2.3.0 ~ Copyright © 2026, Oracle and/or its affiliates 321
  276. • Enterprise Manager • Database や ASM の運用管理 • Exadata

    Plug-in - Exadata Storage Server やその他 Exadata ターゲットを管理、監視するためのプラグインを提供 • 包括的なコマンドラインツール • Database Server 管理用 CLI : DBMCLI • Storage Server 管理用 CLI : CellCLI、ExaCLI • 複数の Storage Server に対して同時にコマンドを配布するCLI: dcli • Sun Embedded Integrated Lights Out Manager (ILOM) • ハードウェアのリモート管理、運用のためのツール Exadata の運用管理 Copyright © 2026, Oracle and/or its affiliates 323
  277. • 管理サービス • UI の提供 • 管理エージェントからの情報を 管理リポジトリへ保存 • 管理リポジトリ

    • 管理エージェントが収集した情報を格納 Enterprise Manager Cloud Control の構成 • 管理エージェント • 管理対象の情報を収集 • 管理サービスに情報を送信 管理 エージェント 管理ツール データベース・ インスタンス Database Server EM サーバー 管理 リポジトリ 管理 サービス 管理情報の収集・格納 管理操作の実行 管理情報の参照 Exadata Storage Server http/https http/https Plug-in ssh & snmp Oracle Exadata Database Machine Cisco Switch PDU RoCE/InfiniBand Switch Plug-in Copyright © 2026, Oracle and/or its affiliates 324
  278. 特定の HW 障害を検知した場合、自動的にオラクルサポートへ SR の登録を行う機能 ASR for Exadata Customer Datacenter

    Customer Oracle Field Engineer FRU replaced by Field Engineer Fault occurs Oracle Support Services Oracle Support Engineer FRU dispatched by Support Engineer Service Request routed to Support Engineer Oracle Case Management System Service Request (SR) created ASR Service Product's auto-diagnosis facility sends SNMP trap to ASR Manager SR creation email notification to customer Fault telemetry securely transmitted to Oracle ASR Manager Copyright © 2026, Oracle and/or its affiliates 325
  279. • Database Server OS イメージでは、OS 領域にLVMが構成されています。 • LVM 領域を柔軟に拡張したりすることが可能です。 •

    LVM のスナップショットを利用することでOS 領域のバックアップが可能です。 • 手順は、マニュアル Maintenance Guide for Exadata Database Machine (DBMMN) をご参照ください。 【参考】 Database Server 内ローカルディスク構成 Copyright © 2026, Oracle and/or its affiliates 326
  280. 327 25.1 イメージでセットアップしたベアメタル構成 – Quorum Disk 有りの場合 Database Server X11M

    ベアメタル 内蔵ディスク詳細構成 3.84 TB /dev/nvme0(デフォルト) Namespace (LUNに相当) md md24p1: 7.2 GB Namespace1 : 7.46 GiB nvme0n1 md25 : 3.48 TiB VG 作成(pv:/dev/md25 を使用) VGExaDb: 3.48 Tib VG: VGExaDb より LV 作成 /dev/VGExaDb/ LVDbSys1 : 15 GiB /dev/VGExaDb/ LVDbOra1 : 200 GiB “/” にマウント “/u01” にマウ ント /dev/VGExaDb/ LVDbSwap1 : 16 GiB swap用 /dev/VGExaDb/ LVDbSys2 : 15 GiB マウントされて ない dbserver_bac kup.shのバック アップ先 /dev/VGExaDb/ LVDoNot RemoveOrUse : 2 GiB マウントされて ない patch 適用の 際取得される snapshoバック アップのスペース 確保用 Boot用パーティション “/boot” にマウント EFI パーティション “/boot/efi” にマウント /dev/VGExaDb/ LVDbVd... DATAC1 : 128MiB マウントされて ない Quorum Disk 用 md24p2: 254 MB /dev/VGExaDb/ LVDbHome : 4 GiB /home にマウ ント /dev/VGExaDb/ LVDbTmp : 3 GiB /tmpにマウン ト /dev/VGExaDb/ LVDbVar1 : 2 GiB /varにマウント /dev/VGExaDb/ LVDbVar2 : 2 GiB マウントされて いない /dev/VGExaDb/ LVDbVarLog : 18 GiB /var/log にマ ウント /dev/VGExaDb/ LVDb VarLogAudit : 1 GiB /var/log/audi t にマウント /dev/VGExaDb/ LVDbVd... RECOC1 : 128MiB マウントされて ない Quorum Disk 用 md24 : 7.46 GiB Namespace2 : 3.48 TiB nvme0n2 Namespace1 : 7.46 GiB nvme1n1 Namespace2 : 3.48 TiB nvme1n2 3.84 TB /dev/nvme1(デフォルト) NVMe SSD Copyright © 2025, Oracle and/or its affiliates
  281. 25.1.x イメージでセットアップしたKVM Host構成 Database Server X11M KVM Host 内蔵ディスク詳細構成 /dev/VGExaDb/

    LVDbSys1 : 15 GiB “/” にマウント /dev/VGExaDb/ LVDbSwap1 : 16 GiB swap用 /dev/VGExaDb/ LVDbSys2 : 15 GiB マウント されてない dbserver_ backup.shの バックアップ先 /dev/VGExaDb/ LVDoNot RemoveOrUse : 2 GiB マウント されてない patch 適用の 際取得される snapshoバック アップのスペース 確保用 /dev/VGExaDb/ LVDb ExaVMImages : 3.37 TiB /EXAVMIMA GES に マウント Guest VM 用 インストール時 から最大 拡張には増設 /dev/VGExaDb/ LVDbHome : 4 GiB /home に マウント /dev/VGExaDb/ LVDbTmp : 3 GiB /tmpに マウント /dev/VGExaDb/ LVDbVar1 : 2 GiB /varに マウント /dev/VGExaDb/ LVDbVar2 : 2 GiB マウント されてない /dev/VGExaDb/ LVDbVarLog : 18 GiB /var/log にマ ウント /dev/VGExaDb/ LVDb VarLogAudit : 1 GiB /var/log/ audit に マウント 3.84 TB /dev/nvme0(デフォルト) md24p1: 7.2 GB Namespace1 : 7.46 GiB nvme0n1 md25 : 3.48 TiB VG 作成(pv:/dev/md25 を使用) VGExaDb: 3.48 Tib VG: VGExaDb より LV 作成 Boot用パーティション “/boot” にマウント EFI パーティション “/boot/efi” にマウント md24p2: 254 MB md24 : 7.46 GiB Namespace2 : 3.48 TiB nvme0n2 Namespace1 : 7.46 GiB nvme1n1 Namespace2 : 3.48 TiB nvme1n2 3.84 TB /dev/nvme1(デフォルト) Copyright © 2025, Oracle and/or its affiliates 328 Namespace (LUNに相当) md NVMe SSD
  282. 329 25.1.3 イメージでセットアップしたKVM構成 – Quorum Disk 有りの場合 Database Server X11M

    KVM Guest 内蔵ディスク詳細構成 sda1: 537 MB /dev/sda: 109GB sda3 : 108 GB VGExaDb: 100.55 GB /dev/VGExaDb/ LVDbSys1 : 15 GiB “/” に マウント /dev/VGExaDb/ LVDbSwap1 : 16 GiB swap用 /dev/VGExaDb/ LVDbSys2 : 15 GiB マウント されてない dbserver_bac kup.shのバック アップ先 /dev/VGExaDb/ LVDoNot RemoveOrUse : 2 GiB マウントされて ない patch 適用の 際取得される snapshotバック アップのスペース 確保用 /dev/VGExaDb/ LVDbVd... DATAC1 : 128MiB マウントされて ない Quorum Disk 用 sda2: 268 MB /dev/VGExaDb/ LVDbHome : 4 GiB /home に マウント /dev/VGExaDb/ LVDbTmp : 3 GiB /tmpに マウント /dev/VGExaDb/ LVDbVar1 : 2 GiB /varに マウント /dev/VGExaDb/ LVDbVar2 : 2 GiB マウント されてない /dev/VGExaDb/ LVDbVarLog : 18 GiB /var/log にマ ウント /dev/VGExaDb/ LVDb VarLogAudit : 1 GiB /var/log/audi t にマウント /dev/VGExaDb/ LVDbVd... RECOC1 : 128MiB マウントされて ない Quorum Disk 用 sdb : 23.6 GB VGExaDbDisk. u01.20.img 22GB sdb1 : 22 GB /dev/VGExaDbDi sk.u01.20.img/LV DBDisk 20 GiB /u01 sdd : 55.8 GB VGExaDbDisk. db-klone-Linux- x86-64- 230002407.50. img 52GB sdd1 : 52 GB /dev/VGExaDbDi sk.db-klone- Linux-x86-64- 230002501.50. img/LVDBDisk 50 GiB /u01/app/oracle /product/23.0.0. 0/dbhome_1 LV VG PV KVM Guest あたり 220 GB /bootにマウン ト sdc : 55.8 GB VGExaDbDisk. grid-klone-Linux- x86-64- 230002407.50. img 52GB sdc1 : 52 GB /dev/VGExaDbDi sk.grid-klone- Linux-x86-64- 230002501.50. img/LVDBDisk 50 GiB /u01/app /23.0.0.0/grid /dev/VGExaDb/ LVDbKdump : 20 GiB /crashfiles Copyright © 2025, Oracle and/or its affiliates
  283. Copyright © 2026, Oracle and/or its affiliates 331 1. 自動ワークロード・リポジトリ(AWR)

    2. データベース統計および待機イベント 3. Exadataメトリック 4. Exadataアラート 5. ExaWatcher Exadataの監視ツールおよび情報ソースの概要
  284. AWRレポート • AWRレポートにおけるExadata に関する情報 • 待機イベント(Wait Events Statistics) • IO統計情報(IO

    Stats) • Exadata固有機能に関す る効果の算出方法 (Instance Activity Statistics) • Exadata System Software パフォーマンス統計 (Exadata Statistics) • クエリーのパラレル度 • パーティションワイズジョイン • Exadata 環境におけるデ フォルトのパラレル度 パフォーマンス確認方法 Copyright © 2026, Oracle and/or its affiliates 332
  285. Main Report > Wait Events • Smart Scan の待機イベント •

    cell smart table scan データベースが Storage Server の表スキャンの完了を待機していることを表す • cell smart index scan データベースが Storage Server の索引または索引構成表のスキャンの完了を待機していることを表す • その他の I/O に関する待機イベント • cell single block physical read Storage Server における、db file sequential read と同じ待機イベント • cell multiblock physical read Storage Server における、db file scattered read と同じ待機イベント AWRレポートにおけるExadata固有の情報 Copyright © 2026, Oracle and/or its affiliates 333
  286. Main Report > Instance Activity Statistics(IO 関連) • ① cell

    physical IO interconnect bytes • DB Server と Storage Server の間でやりとりされた IO サイズ • ② cell physical IO bytes eligible for predicate offload • オフロード の対象となった IO サイズ • ③ cell physical IO interconnect bytes returned by smart scan • Smart Scan により Storage Server から返された IO サイズ • ④ cell IO uncompressed bytes • Storage Server で処理された非圧縮のデータサイズ • ⑤ cell physical IO bytes saved by storage index • Storage index による IO 削減サイズ • ⑥ cell physical IO bytes saved during optimized file creation • オフロードされたデータファイル関連処理の IO サイズ • ⑦ cell flash cache read hits • Smart Flash Cache に対するリクエスト回数 • ⑧ cell physical IO bytes sent directly to DB node to balance CPU usage • Optimized Smart Scanにより DBサーバーに戻された I/O サイズ AWRレポートにおける Exadata 特有の情報 Storage Servers DB Servers RoCE/ InfiniBand ⑤ cell physical IO bytes saved by storage index ① cell physical IO interconnect bytes ③ cell physical IO interconnect bytes returned by smart scan Virtual IO Real IO Network IO ② cell physical IO bytes eligible for predicate offload ④ cell IO Uncompressed bytes ⑥ cell physical IO bytes saved during optimized file creation * 3 ② cell physical IO bytes eligible for predicate offload Normal IO (read) physical read total bytes Normal IO (write) physical write total bytes * 3 Copyright © 2026, Oracle and/or its affiliates 335
  287. Exadata による効果の算出方法 • IO 削減効果(セル・オフロード効率) • Read IO に着目して算出 •

    圧縮・非圧縮共通 • (Uncompress された状態の IO サイズ、及び Storage Index による IO 削減サイズの合計) or (Smart Scan の対象になった IO サイズ)のうち大きい値と、 実際に Smart Scan により DB Server に転送された IO サイズ、 との割合を算出 AWRレポートにおける Exadata 特有の情報 [ 1 - {(③cell physical IO interconnect bytes returned by smart scan) / (*1) } ] * 100 (*1) ④cell IO uncompressed bytes + ⑤cell physical IO bytes saved by storage index もしくは ②cell physical IO bytes eligible for predicate offload のうち大きい値 Storage Servers ⑤ cell physical IO bytes saved by storage index ③ cell physical IO interconnect bytes returned by smart scan ④ cell IO Uncompressed bytes IO 削減効果 ② cell physical IO bytes eligible for predicate offload Copyright © 2026, Oracle and/or its affiliates 336
  288. Exadata による効果の算出方法 • Storage Index によるディスク IO 削減効果 • 圧縮・非圧縮共通

    • 全体の読み込みサイズに対して Storage Index で削減できた割合を算出 AWRレポートにおける Exadata 特有の情報 (⑤cell physical IO bytes saved by storage index / physical read total bytes) * 100 Storage Servers ⑤ cell physical IO bytes saved by storage index physical read total bytes Storage Index による IO 削減効果 Copyright © 2026, Oracle and/or its affiliates 337
  289. Exadata による効果の算出方法 • Flash Cache ヒット率 • 圧縮・非圧縮共通 • 全体の読み込み要求数に対する

    Flash Cache のヒット数を計算 AWRレポートにおける Exadata 特有の情報 (⑦ cell flash cache read hits / physical read total IO requests) * 100 Storage Servers ⑦ cell flash cache read hit physical read total IO requests Flash Cache ヒット率 Copyright © 2026, Oracle and/or its affiliates 338
  290. クエリ処理時の基本的な流れ クエリ実行時の流れと待機イベント Copyright © 2026, Oracle and/or its affiliates 339

    Table Full Scan or Index Fast Full Scan Index Accessなど 基本的には”db file sequential read” (Exadataの場合”cell single block physical read”) ”db file scattered read” (Exadataの場合”cell multiblock physical read”) Buffer Cacheにのせる場合 Buffer Cacheにのせない場合 ”direct path read” (Exadataの場合”cell smart table scan” “cell smart index scan”) 11g R1 よりシリアル時でも選択される可能性あり
  291. AWR レポートがあれば、Exadata 全体のパフォーマンス分析が可能 • Exadata のパフォーマンス解析のためには、Storage の情報も必要なケースもある • I/O ネックになっていないかを判断

    • I/O リソースの取り合いが発生していないかを判断(統合環境の場合) • ディスク障害などどこか一つのディスク・パフォーマンスが劣化していないかを判断 - アプリケーション全体のパフォーマンスが劣化する恐れ • Storage Server の CPU ネックになっていないかを判断 • Storage Server の構成が適切かどうかを判断 • Exadata 12.1.2.1.0 から、上記のような情報もAWR レポートより確認が可能に Exadata 向け AWR 機能の拡張 Exadata 12.1.2.1.0 ~ 従来、これらの情報を確認するためには、 ExaWatcher や Storage Server のメトリックなどを確認する必要があった Copyright © 2026, Oracle and/or its affiliates 340
  292. AWR Report > Exadata Configuration and Statistics • AWR レポートに、Exadata

    のStorage Server 情報を表示 (Exadata Configuration and Statistics) • Exadata の構成情報(Exadata Server Configuration) - HW モデル、ESSバージョン、Flash Cache、PMEM Cache 構成、Griddisk、Celldisk、Diskgroup、IORM Objective の情報 • Exadata のヘルス・レポート(Exadata Server Health Report) - オープン・アラートの有無 - Offline disk の有無 • Exadata 統計(Exadata Statistics) - Performance Summary - Exadata Resource Statistics - Exadata Smart Statistics(Smart IO、Flash Log、Flash Cache、Columnar Cache、PMEM Cache) - Exadata IO Reasons - Exadata Top Database Consumers - Exadata IO Latency Capping - Exadata Flash Wear • Oracle Database 12.1.0.2 + Exadata 12.1.2.1.0 以降が必要 • HTML 形式、Active Report 形式でのみサポート Exadata 向け AWR 機能の拡張 Copyright © 2026, Oracle and/or its affiliates 341
  293. AWR Report > Exadata Configuration and Statistics > Exadata Server

    Configuration 【参考】AWR レポートの例:Exadata の構成情報 Copyright © 2026, Oracle and/or its affiliates 342 Exadata 12.1.2.1.0 ~
  294. AWR Report > Exadata Configuration and Statistics > Exadata Server

    Health Report 【参考】AWR レポートの例:Exadata のヘルス・ステータス情報 Copyright © 2026, Oracle and/or its affiliates 343
  295. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Performance Summary > Smart Scan Summary AWRを使用したスマートI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 344 cell num bytes in block IO during predicate offload クライアントがブロックI/Oモードで あったためにオフロードされなかった バイト数 → スマートI/Oを使用して通常実行 される操作のOracle Databaseが ブロックI/Oモードに戻った cell num smart IO sessions in rdbms block IO due to online encr 進行中のオンライン暗号化操 作が原因でブロックI/Oモー ドになっている(オフロード されない)セッション数 → スマートI/Oの使用を妨げる進行 中のオンライン暗号化操作が原 因でブロックI/Oモードに戻された
  296. Smart IO セクションのエンハンス AWR Report –Exadata セクションの機能拡張 Copyright © 2026,

    Oracle and/or its affiliates 345 Smart IO • Eligible for Smart IO : Smart Scan 対象なストレージ・サーバーの読取りIO(MB単位)を表示 • Columnar Cache : 列キャッシュからの読取りIO(MB単位)で表示 • CC Eligible : Columnar Cache 対象なストレージ・サーバーの読取りIO(MB)を表示 • CC Saved : Columnar Cache によって保存された(削減された)ストレージ・サーバーの読取りIO(MB)を表示 • Oracle Database 19c にバックポート済み 従来
  297. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Smart Statistics > Smart IO Statistics 【参考】AWR レポートの例:Smart IO の監視 Copyright © 2026, Oracle and/or its affiliates 346 Smart Scanの対象と なるI/O量 Storage Index の使 用によるIO削減 Exadataスマート・フラッシュ・ キャッシュ内のデータの量 データベース・サーバーに転送せずに、ストレージ・サーバーに よってフィルタ処理されたデータ量 例(Offload: MB ) / (MB Requested: Total) = 98%) パススルー そのままDBサーバーに送 信されたデータ量 (Storage Server のCPU 負荷が高いときなど) リバース・オフロード (Storage Server の CPU負荷が高いとき など) Smart Scanの統 計 パススルーの理由 cell num smart IO sessions in rdbms block IO due to online encr 進行中のオンライン 暗号化操作が原因で ブロックI/Oモード になっている(オフ ロードされない) セッション数
  298. 動的パフォーマンス・ビューに、多くのデータベース統計および待機イベントが含まれる。AWRの情報ソース •V$SYSSTAT • Exadataストレージ・サーバーに関連するI/O統計など、現在のデータベース・インスタンスに関連する様々なシステム全体の統計 •V$SESSION • 現在アクティブなデータベース・セッションの様々な統計および待機イベント •V$SESSION_EVENT • セッション別のイベントの待機情報

    •V$SYSTEM_EVENT • イベントの待機合計に関するシステム全体の情報 • AWRレポートの待機イベント統計セクションに含まれる •V$ACTIVE_SESSION_HISTORY • システム上のアクティブ・セッションの履歴を保持 - アクティブの定義は、CPUを使用しているか、アイドル状態でない待機イベントを待機していること • セッションごとに、V$ACTIVE_SESSION_HISTORYには、SQL実行計画や待機イベントの詳細(Exadataストレージの相互作用に関する情報など)など、セッションの実行内容に関す る多くの情報が含まれる •V$SQL • データベース・インスタンスで処理されたSQL文の情報および統計 •V$SEGMENT_STATISTICS • セグメントごとの統計 • セグメント・レベルの統計は、Exadataストレージから最適化読取りを実行中の表または索引などの特定のオブジェクトの検出に使用 データベース統計および待機イベント Copyright © 2026, Oracle and/or its affiliates 348
  299. 統計 説明 cell IO uncompressed bytes セルで処理された非圧縮データの合計サイズ。 Exadataハイブリッド列圧縮を使用して圧縮されたセグメントに対する操作の場合、この統計が解 凍後のデータのサイズになります。 cell

    num bytes in block IO during predicate offload クライアントがブロックI/Oモードであったためにオフロードされなかったバイト数。 cell num bytes in filter passthru due to low mem セルに対するメモリー不足が原因でオフロードされず、処理のためにデータベースに返されたバイト 数。 cell num bytes in filter passthru due to subheap size limit exc セルに対するメモリー制限が原因でオフロードされず、処理のためにデータベースに返されたバイト 数。 cell num bytes in passthru due to quarantine セルに対する検疫が原因でオフロードされず、処理のためにデータベースに返されたバイト数。 cell num bytes in passthru during predicate offload オフロードされず、処理のためにデータベースに返されたバイト数。 cell num smart IO sessions in rdbms block IO due to big payload 大きすぎるメタデータが原因でブロックI/Oモードになっている(オフロードされない)セッション数。 cell num smart IO sessions in rdbms block IO due to no cell mem ストレージ・サーバーのメモリー不足が原因でブロックI/Oモードになっている(オフロードされない)セッ ション数。 cell num smart IO sessions in rdbms block IO due to online encr 進行中のオンライン暗号化操作が原因でブロックI/Oモードになっている(オフロードされない)セッショ ン数。 cell num smart IO sessions in rdbms block IO due to open fail セルへの接続のオープンの失敗が原因でブロックI/Oモードになっている(オフロードされない)セッショ ン数。 データベース統計を使用したスマートI/Oの監視 (1) Copyright © 2026, Oracle and/or its affiliates 349
  300. 統計 説明 cell num smart IO sessions in rdbms block

    IO due to user ユーザー設定が原因でブロックI/Oモードになっている(オフロードされない)セッション数。 cell num smart IO sessions using passthru mode due to cellsrv CELLSRVの問題が原因でパススルー・モードになっている(オフロードされない)セッション数。 cell num smart IO sessions using passthru mode due to timezone データベース・タイムゾーン・アップグレード操作の進行中が原因でパススルー・モードに なっている(オフロードされない)セッション数。 cell num smart IO sessions using passthru mode due to user ユーザー設定が原因でパススルー・モードになっている(オフロードされない)セッション数。 cell physical IO bytes added to storage index スマート・スキャン中にStorage Indexに追加されたバイト数。これは、Storage Indexが作 成中であることを示します。 cell physical IO bytes eligible for predicate offload 条件のオフロードの対象となるディスク上のバイト数。 cell physical IO bytes eligible for smart IOs 条件のオフロードの対象となる実際のバイト数。 たとえば、列キャッシュを使用する場合、これはディスク上のサイズではなく列キャッシュの サイズです。 cell physical IO bytes processed for IM capacity 列キャッシュからmemcompress for capacity形式で読み取られたバイト数。 cell physical IO bytes processed for IM query 列キャッシュからmemcompress for query形式で読み取られたバイト数。 cell physical IO bytes processed for no memcompress 列キャッシュからno memcompress形式で読み取られたバイト数。 cell physical IO bytes processed for XrCC Exadata RDMAメモリー(XRMEM)上の列キャッシュから読み取られたバイト数。 データベース統計を使用したスマートI/Oの監視 (2) Copyright © 2026, Oracle and/or its affiliates 350
  301. 統計 説明 cell physical IO bytes saved by columnar cache

    列キャッシュによって保存されたバイト数。つまり回避された読取りバイト数。 cell physical IO bytes saved by storage index Storage Indexによって保存されたバイト数。 cell physical IO bytes saved during optimized file creation ファイル作成操作をセルにオフロードして、データベース・ホストで保存されたI/Oバイト数。 この統計は、最適化されたファイル作成操作の利点を示します。 cell physical IO bytes saved during optimized RMAN restore RMANのファイル・リストア操作をセルにオフロードして、データベース・ホストで保存された I/Oバイト数。この統計は、最適化されたRMANのファイル・リストア操作の利点を示しま す。 cell physical IO bytes sent directly to DB node to balance CPU usage ストレージ・サーバーのCPU使用率が高いためにデータベース・サーバーに処理のために返 されたI/Oバイト数。 cell physical IO interconnect bytes インターコネクト(データベース・ホストとセルの間)で交換されたI/Oバイト数。 cell physical IO interconnect bytes returned by smart scan スマート・スキャン操作のためにセルによって返されたI/Oバイト数。他のデータベースI/Oの バイト数は含まれません。 データベース統計を使用したスマートI/Oの監視 (3) Copyright © 2026, Oracle and/or its affiliates 351
  302. データベース待機イベントを使用したスマートI/Oの監視(1) Copyright © 2026, Oracle and/or its affiliates 352 待機イベント

    説明 cell external table smart scan この待機イベントは、セルで外部表スキャンを待機しているときに表示されます。 V$SESSIONのP1列のセル・ハッシュ番号では、他のセルに比べて遅いセルを識別できます。 cell smart file creation (セルのスマート・ファイル作成) この待機イベントは、セルでファイル作成が完了するのをデータベースが待機しているときに表示されます。 V$SESSIONのP1列のセル・ハッシュ番号では、他のセルに比べて遅いセルを識別できます。 cell smart incremental backup (セルのスマート増分バックアップ) この待機イベントは、セルで増分バックアップが完了するのをデータベースが待機しているときに表示されます。 V$SESSIONのP1列のセル・ハッシュ番号では、他のセルに比べて遅いセルを識別できます。 cell smart index scan (セルのスマート索引スキャン) この待機イベントは、索引高速フル・スキャンを待機しているときに表示されます。 V$SESSIONのP1列のセル・ハッシュ番号では、他のセルに比べて遅いセルを識別できます。 cell smart index scan: db timezone upgrade この待機イベントは、データベース・タイムゾーンのアップグレードが進行中のためにセルがオフロードできないときに表示さ れます。 cell smart index scan: disabled by user この待機イベントは、ユーザー設定が原因でセルがオフロードできないときに表示されます。 cell smart index scan: pass through この待機イベントは、セルがスマート・スキャンをオフロードできないときに表示されます。
  303. データベース待機イベントを使用したスマートI/Oの監視(2) Copyright © 2026, Oracle and/or its affiliates 353 待機イベント

    説明 cell smart index scan request これはcell smart index scanに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示されます。 待機イベントが終了すると、プレースホルダは通常cell smart index scanに変換されます。ただし、待機の結果をより適 切に説明するために、プレースホルダをcell smart index scan: db timezone upgrade、cell smart index scan: disabled by userまたはcell smart index scan: pass throughに変換できます。 cell smart restore from backup (バックアップからのセルのスマート・リストア) この待機イベントは、セルでバックアップからのリストアのファイル初期化が完了するのをデータベースが待機しているときに 表示されます。 V$SESSIONのP1列のセル・ハッシュ番号では、他のセルに比べて遅いセルを識別できます。 cell smart table scan (セルのスマート表スキャン) この待機イベントは、セルでスマート・スキャンが完了するのをデータベースが待機しているときに表示されます。 V$SESSIONのP1列のセル・ハッシュ番号では、他のセルに比べて遅いセルを識別できます。 cell smart table scan: db timezone upgrade この待機イベントは、データベース・タイムゾーンのアップグレードが進行中のためにセルがオフロードできないときに表示さ れます。 cell smart table scan: disabled by user この待機イベントは、ユーザー設定が原因でセルがオフロードできないときに表示されます。 cell smart table scan: pass through この待機イベントは、セルがスマート・スキャンをオフロードできないときに表示されます。
  304. 条件のオフロードの対象とな るディスク上のバイト数 フラッシュ・ストレージに対する 物理I/Oリクエスト数。 スマートI/O操作に関する追加情報を含む、行ソースの詳細な統計 Enterprise Manager : SQL Monitor

    を使用したスマートI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 354 セルによって返されたバイト数 条件のオフロードの対象とな る実際のバイト数 たとえば、列キャッシュを使用 する場合、これはディスク上 のサイズではなく列キャッシュ のサイズ 列キャッシュによって保存され たバイト数、つまり読み取る 必要がなかったバイト数 列キャッシュから memcompress for capacity 形式で読み取られたバイト 数 Exadataスマート・フラッシュ・ キャッシュから読み取られたバ イト数 データベース・コンピュート・ノードから セルに送信された問合せメタデータ のサイズ
  305. スマートI/O操作に関する追加情報を含む、行ソースの詳細な統計(前ページの続き) [参考] Enterprise Manager : SQL Monitor を使用したスマートI/Oの監視 (1) 統計

    説明 Filtered bytes セルによって返されたバイト数。 Cell passthru IO bytes オフロードされず、処理のためにデータベースに返されたバイト数。 Cell passthru IO bytes due to quarantine セルに対する検疫が原因でオフロードされず、処理のためにデータベースに返されたバイト数。 Eligible bytes for smart IO 条件のオフロードの対象となる実際のバイト数。たとえば、列キャッシュを使用する場合、これはディスク上のサイ ズではなく列キャッシュのサイズです。 SI saved bytes ストレージ索引によって保存されたバイト数。つまり読み取る必要がなかったバイト数。 Columnar cache saved bytes 列キャッシュによって保存されたバイト数。つまり読み取る必要がなかったバイト数。 Partial flash cache and disk bytes Exadataスマート・フラッシュ・キャッシュとディスクの両方から読み取られたバイト数。 Flash cache bytes Exadataスマート・フラッシュ・キャッシュから読み取られたバイト数。 IM Capacity bytes 列キャッシュからmemcompress for capacity形式で読み取られたバイト数。 IM Query bytes 列キャッシュからmemcompress for query形式で読み取られたバイト数。 No memcompress bytes 列キャッシュからno memcompress形式で読み取られたバイト数。 XRMEM Columnar Cache bytes Exadata RDMAメモリー(XRMEM)上の列キャッシュから読み取られたバイト数。 Bytes added to storage index スマート・スキャン中にストレージ索引に追加されたバイト数。これは、ストレージ索引が作成中であることを示 します。 Copyright © 2026, Oracle and/or its affiliates 355
  306. スマートI/O操作に関する追加情報を含む、行ソースの詳細な統計(前ページの続き) [参考] Enterprise Manager : SQL Monitor を使用したスマートI/Oの監視 (2) 統計

    説明 cell IORM IO requests on flash フラッシュ・ストレージに対する物理I/Oリクエスト数。 cell IORM wait time on flash (us) IORMがフラッシュ・リクエストをキューに入れた時間(マイクロ秒)。 cell IORM wait time on flash (us)/cell IORM IO requests on flashは、IORMキューで費やされ た平均時間を示します。 cell IORM IO requests on disk ディスク・ストレージに対する物理I/Oリクエスト数。 cell IORM wait time on disk (us) IORMがディスク・リクエストをキューに入れた時間(マイクロ秒)。 cell IORM wait time on disk (us)/cell IORM IO requests on diskは、IORMキューで費やされた 平均時間を示します。 Block IO bytes ブロックI/Oモードのバイト数。 Slow metadata bytes Metadata bytes データベース・コンピュート・ノードからセルに送信された問合せメタデータのサイズ。 Eligible bytes 条件のオフロードの対象となるディスク上のバイト数。 Copyright © 2026, Oracle and/or its affiliates 356
  307. SQL実行計画を使用したスマートI/Oの監視 • SQL EXPLAIN PLANコマンドは、SQL実行計画のスマートI/O最適化に関する情報を表示 • EXPLAIN PLANコマンドを使用すると、ストレージ・サーバーにオフロードできるSQL問合せの一部を識別可能 • SQL実行計画のスマートI/O最適化を表示するには、EXPLAIN

    PLANコマンドのデータベース・パラメータ CELL_OFFLOAD_PLAN_DISPLAYをAUTOまたはALWAYSに設定 • 例6-5 SQL実行計画を使用したスマートI/Oの監視 • この例は、EXPLAIN PLANコマンドを使用して、SQL実行計画のスマートI/O最適化を表示する方法を示す • 問合せ計画では、TABLE ACCESS STORAGE FULL操作は、対応する全表スキャンがストレージ・サーバーにオフロー ドされることを示す。条件情報には、ストレージ・サーバーにオフロードされる問合せ条件の詳細が表示 357 Copyright © 2026, Oracle and/or its affiliates
  308. EXPLAIN PLANコマンド SQL実行計画を使用したスマートI/Oの監視 Copyright © 2026, Oracle and/or its affiliates

    358 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 147K (1)| 00:29:25 | | | | 1 | SORT AGGREGATE | | 1 | | | | | | | 2 | VIEW | | 439 | | 147K (1)| 00:29:25 | | | | 3 | HASH GROUP BY | | 439 | 8341 | 147K (1)| 00:29:25 | | | | 4 | VIEW | TABLEA | 439 | 8341 | 147K (1)| 00:29:25 | | | | 5 | UNION-ALL | | | | | | | | | 6 | PARTITION RANGE SINGLE | | 51 | 1938 | 51907 (1)| 00:10:23 | 1 | 1 | |* 7 | TABLE ACCESS STORAGE FULL| TABLEB | 51 | 1938 | 51907 (1)| 00:10:23 | 1 | 1 | | 8 | PARTITION RANGE SINGLE | | 15 | 555 | 4456 (1)| 00:00:54 | 1 | 1 | |* 9 | TABLE ACCESS STORAGE FULL| TABLEC | 15 | 555 | 4456 (1)| 00:00:54 | 1 | 1 | |* 10 | TABLE ACCESS STORAGE FULL | TABLED | 3 | 111 | 70234 (1)| 00:14:03 | | | | 11 | PARTITION RANGE SINGLE | | 4 | 152 | 2577 (2)| 00:00:31 | 1 | 1 | |* 12 | TABLE ACCESS STORAGE FULL| TABLEE | 4 | 152 | 2577 (2)| 00:00:31 | 1 | 1 | | 13 | PARTITION RANGE SINGLE | | 110 | 4180 | 6514 (1)| 00:01:19 | 2 | 2 | |* 14 | TABLE ACCESS STORAGE FULL| TABLEF | 110 | 4180 | 6514 (1)| 00:01:19 | 2 | 2 | | 15 | PARTITION RANGE SINGLE | | 242 | 9196 | 10802 (2)| 00:02:10 | 2 | 2 | |* 16 | TABLE ACCESS STORAGE FULL| TABLEG | 242 | 9196 | 10802 (2)| 00:02:10 | 2 | 2 | |* 17 | TABLE ACCESS STORAGE FULL | TABLEH | 14 | 518 | 518 (1)| 00:00:07 | | | ----------------------------------------------------------------------------------------------------------- TABLE ACCESS STORAGE FULL 対応する全表スキャンがストレージ・サーバーにオフロードされることを示す
  309. • Exadataシステム・ソフトウェアに関連する重要なプロパティまたは値の観測データを記録したもの • ほとんどのExadataコンポーネントの詳細な統計が含まれる • メトリックは、ストレージ・サーバーとそのコンポーネント(Flash Cache、セル・ディスク、グリッド・ディスクなど)に関連 • ストレージ・サーバーのメトリックを使用すると、Exadataストレージ・サーバーのパフォーマンスを詳細に監視可能 •

    メトリックのタイプ • 累積メトリック - メトリックが作成されてから、またはサーバーが再起動されてから一定期間累積される統計 - 例:CL_IO_RQ_NODATAは、データを返さなかったI/Oリクエストの合計数 • 即時メトリック - メトリックの観測時点の現在の値 - 例:CL_MEMUTは、サーバー上の現在使用されている合計物理メモリーの割合 • 率メトリック - 値を経時的に観測する、計算された統計 - 例:N_NIC_KB_TRANS_SECは、サーバーのイーサネット・インタフェースを介して転送される1秒当たりのKB数 • 一部のメトリックでは、Small IOとLarge IOが区別される • Small IOは、サイズが128 KB以下のI/O • Large IOは、サイズが128 KBを超えるもの • メトリック収集は1分間隔、7日間保持、一部のキー・メトリックは、最長で1年間保持 • ESS 24.1以降最大1年間保持するメトリックの表示、制御が可能に • ディスクベースのメトリック履歴リポジトリの領域不足を検出すると、Exadataは履歴メトリック観測データを自動的にパージ • ESS 22.1以降、オプションのファイングレイン・メトリック構成が可能 Exadataメトリック Copyright © 2026, Oracle and/or its affiliates 359
  310. スマートI/Oのメトリック定義の表示 • objectType=SMARTIO であるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • 関連メトリック(抜粋) Exadataメトリックを使用したExadata Smart IOの監視 Copyright

    © 2026, Oracle and/or its affiliates 360 SIO_IO_EL_OF "Cumulative number of megabytes eligible for smart IO offload" SIO_IO_EL_OF_SEC "Number of megabytes per second eligible for smart IO offload" SIO_IO_OF_RE "Cumulative number of interconnect megabytes returned by smart IO" SIO_IO_OF_RE_SEC "Number of interconnect megabytes per second returned by smart IO" SIO_IO_PA_TH "Cumulative number of megabytes of passthru IOs by smart IO" SIO_IO_PA_TH_SEC "Number of megabytes per second of passthru IOs by smart IO" SIO_IO_RD_FC "Cumulative number of megabytes read from flash cache by smart IO" SIO_IO_RD_FC_HD "Cumulative number of megabytes read from both flash cache and hard disk by smart IO" SIO_IO_RD_FC_HD_SEC "Number of megabytes per second read from both flash cache and hard disk by smart IO" SIO_IO_RD_FC_SEC "Number of megabytes per second read from flash cache by smart IO" SIO_IO_RD_HD "Cumulative number of megabytes read from hard disk by smart IO" SIO_IO_RD_HD_SEC "Number of megabytes per second read from hard disk by smart IO" SIO_IO_RD_RQ_FC "Cumulative number of read IO requests from flash cache by smart IO" SIO_IO_RD_RQ_FC_HD "Cumulative number of read IO requests from both flash cache and hard disk by smart IO" SIO_IO_RD_RQ_FC_HD_SEC "Number of read IO requests per second from both flash cache and hard disk by smart IO" SIO_IO_RD_RQ_FC_SEC "Number of read IO requests per second from flash cache by smart IO" SIO_IO_RD_RQ_HD "Cumulative number of read IO requests from hard disk by smart IO" SIO_IO_RD_RQ_HD_SEC "Number of read IO requests per second from hard disk by smart IO" SIO_IO_RV_OF "Cumulative number of megabytes sent to DB node to balance CPU by smart IO" SIO_IO_RV_OF_SEC "Number of megabytes per second sent to DB node to balance CPU by smart IO" SIO_IO_SI_SV "Cumulative number of megabytes saved by storage index" SIO_IO_SI_SV_SEC "Number of megabytes per second saved by storage index" SIO_IO_WR_FC "Cumulative number of megabytes of flash cache population writes by smart IO" SIO_IO_WR_FC_SEC "Number of megabytes per second of flash cache population writes by smart IO" SIO_IO_WR_HD "Cumulative number of megabytes written to hard disk by smart IO" SIO_IO_WR_HD_SEC "Number of megabytes per second written to hard disk by smart IO" SIO_IO_WR_RQ_FC "Cumulative number of IO requests for flash cache population writes by smart IO" SIO_IO_WR_RQ_FC_SEC "Number of IO requests per second for flash cache population writes by smart IO" SIO_IO_WR_RQ_HD "Cumulative number of write IO requests to hard disk by smart IO" SIO_IO_WR_RQ_HD_SEC "Number of write IO requests per second to hard disk by smart IO" CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE=SMARTIO
  311. 列キャッシュのメトリック定義の表示 • NAME LIKE 'FC_COL.*' であるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • 関連メトリック(抜粋) Exadataメトリックを使用したExadata Smart

    IOの監視 Copyright © 2026, Oracle and/or its affiliates 361 FC_COL_BYKEEP_USED "Number of megabytes used for keep objects in Columnar FlashCache" FC_COL_BY_USED "Number of megabytes used in Columnar FlashCache" FC_COL_IO_BYKEEP_R "Number of megabytes read from Columnar FlashCache for keep objects" FC_COL_IO_BYKEEP_R_SEC "Number of megabytes read per second from Columnar FlashCache for keep objects" FC_COL_IO_BY_R "Number of megabytes that were read from Columnar FlashCache" FC_COL_IO_BY_R_ELIGIBLE "Number of megabytes eligible to read from Columnar FlashCache" FC_COL_IO_BY_R_ELIGIBLE_SEC "Number of megabytes per second eligible to read from Columnar FlashCache" FC_COL_IO_BY_R_SEC "Number of megabytes per second that were read from Columnar FlashCache" FC_COL_IO_BY_SAVED "Number of megabytes saved by reads from Columnar FlashCache" FC_COL_IO_BY_SAVED_SEC "Number of megabytes saved per second by reads from Columnar FlashCache" FC_COL_IO_BY_W_POPULATE "Number of megabytes that are population writes into Columnar FlashCache due to read miss" FC_COL_IO_BY_W_POPULATE_SEC "Number of megabytes per second that are population writes into Columnar FlashCache due to read miss" FC_COL_IO_RQKEEP_R "Number of requests read for keep objects from Columnar FlashCache" FC_COL_IO_RQKEEP_R_SEC "Number of requests read per second for keep objects from Columnar FlashCache" FC_COL_IO_RQ_R "Number of requests that were read from Columnar FlashCache" FC_COL_IO_RQ_R_ELIGIBLE "Number of reads eligible for Columnar FlashCache" FC_COL_IO_RQ_R_ELIGIBLE_SEC "Number of reads per second eligible for Columnar FlashCache" FC_COL_IO_RQ_R_SEC "Number of requests per second that were read from Columnar FlashCache" FC_COL_IO_RQ_W_POPULATE "Number of requests that are population writes into Columnar FlashCache due to read miss" FC_COL_IO_RQ_W_POPULATE_SEC "Number of requests per second that are population writes into Columnar FlashCache due to read miss" CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE NAME LIKE 'FC_COL.*'
  312. • Exadataフリート内のすべてのサーバーから最新のメトリック観測を自動的にストリーミング • リアルタイムの分析と問題解決のためにカスタマイズ可能な監視ダッシュボードをフィード • 包括的 • 200+ Exadata Software

    & Hardware メトリック • きめ細かいメトリックは、1秒ごとに収集可能 • 統合 • 一般的に利用されている時系列、可観測性プラットフォーム と統合可能 • きめ細かいメトリックをユーザー定義のエンドポイントに リアルタイムでストリーミング • 洞察 • プロアクティブな問題検出とリアルタイムの意思決定を 可能に Exadata Real-Time Insight Copyright © 2026, Oracle and/or its affiliates 362 Exadata 22.1.0 ~
  313. list cell detail 初期値 CellCLI> list cell detail name: jojocel01

    accessLevelPerm: remoteLoginEnabled bbuStatus: normal cellVersion: OSS_22.1.0.0.0_LINUX.X64_220518 cpuCount: 24/24 diagHistoryDays: 7 fanCount: 8/8 fanStatus: normal flashCacheMode: WriteBack httpsAccess: ALL id: 1348NM50CG ilomIpAddress: 10.122.4.51 interconnectCount: 2 interconnect1: ib0 interconnect2: ib1 iormBoost: 0.0 ipaddress1: 192.168.20.37/22 ipaddress2: 192.168.20.38/22 kernelVersion: 4.14.35-2047.511.5.5.3.el7uek.x86_64 locatorLEDStatus: off makeModel: Oracle Corporation SUN SERVER X4-2L High Performance managementIpAddress: 10.122.4.29 memoryGB: 94 metricFGCollIntvlInSec: 0 metricHistoryDays: 7 metricStreamEndPoint: metricStreamIntvlInSec: 60 続く Exadata Real-Time Insight Copyright © 2026, Oracle and/or its affiliates 363 22.1 からの新しいパラメーター(赤 字) Exadata 22.1.0 ~
  314. • 従来のメトリック収集 • 1分間隔 • Fine-Graind Metrics • ESS 22.1.0~

    • CellCLI> ALTER CELL metricFGCollIntvlInSec=1 - 1秒から60秒間隔で設定可能(実機では 5秒以上 • CellCLI> ALTER CELL metricFGCollIntvlInSec=0 - Fine Graind Metrics を disable • metric毎の Fine-Graind のオンオフ - CellCLI> ALTER METRICDEFINITION N_NIC_KB_TRANS_SEC finegrained=enabled - CellCLI> ALTER METRICDEFINITION N_MB_SENT finegrained=disabled Exadata Real-Time Insight Copyright © 2026, Oracle and/or its affiliates 364 Exadata 22.1.0 ~
  315. ExaWatcher とは? • システム情報採集と診断用のツール • オペレーティング・システム・ツールおよびユーティリティ(iostat、vmstat、mpstat、topなど)を使用してサーバーおよび ネットワーク関連のデータを収集 • 5秒間隔で収集 •

    各サーバーで個別に実行 • Exadata System Software 11.2.3.3.0 から OSWatcher に代わり、ExaWatcher がシステムの情報を常時収集 • DBサーバ、ストレージサーバに存在 • /opt/oracle.ExaWatcher/ Copyright © 2026, Oracle and/or its affiliates 365 Exadata 11.2.3.3.0 ~
  316. 366 Copyright © 2026, Oracle and/or its affiliates ExaWatcher ログの保持サイズ

    • 最大値(データベースサーバ:6GB & ストレージサーバ: 600MB)を超過すると、古いファイルを削除 • 目安 DB サーバー 約40日 Storage Server 約4日 • /opt/oracle.ExaWatcher/ExaWatcherCleanup.sh • クオータの 80% の領域を超過すると、古い ExaWatcher ログに対してクリーンアップ • クオータの 20% の領域を開放 • データベース・サーバ上でクオータの変更が可能、ストレージサーバでの設定の変更は不可能 • /opt/oracle.ExaWatcher/ExaWatcher.conf - <SpaceLimit> [sizeInMB] •
  317. • ExaWatcher データよりそのノードの ExaWatcher 履歴から自 動的にグラフを HTML 形式で出力 • GetExaWatcherResults.sh

    コマンドにて期間を指定 (下記は実 行例) • 結果ファイル群は、デフォルトでは /opt/oracle.ExaWatcher/archive/ExtractedResults/ 下に tar でまとめられて bzip2 で圧縮されて出力 • 対象ノードの 以下をhtml グラフで出力 • CPU 使用率 • IO 使用率(iops, throughput, wait time 等) • cellsrv 統計(Storage Server のみ。Flash Cache 使用 率、SmartIO 統計等) - CPU 使用率、IO 使用率は、iostat から - CPU 詳細使用率は、mpstat から - cellsrv 統計は cellsrvstat から ExaWatcher の自動グラフ化 Exadata 12.2.1.1.0 ~ # /opt/oracle.ExaWatcher/GetExaWatcherResults.sh –from 2021/02/13_10:50:00 –to 2021/02/13_11:50:00 Copyright © 2026, Oracle and/or its affiliates 367
  318. ecstat (Exadata Cache Stats)は、ストレージ・サー バー・キャッシュ内を覗くための新しいツール ストレージ・サーバー上のクライアントIOの可視性を 簡素化 Media Type および

    IO Reason 別に クライアントI/Oを分解 • Flash Cache での I/Oヒットの TOP IO reasons • Hard Disk での I/Oヒットの TOP IO reasons Exawatcherデータに自動的に含まれる Exadata Cache Observability - ecstat Copyright © 2026, Oracle and/or its affiliates 368 Exadata 24.1.0 ~
  319. Top PDBs by Database IO Requests : CDB内の上位50個のPDBのPDB別I/Oリクエストの詳細を表示 Top PDBs

    by Database IO Requests • Requests: PDB 毎の I/O リクエスト • Optimized Read Reqs/s: メディア毎の IO 回数 – XRMEM/Flash/Disk • Megabytes: I/O スループット(MB/s) • IORM: I/O Resource Manager (IORM) の状態 • Oracle Database 19c にもバックポート済み(DBRU 19.22) • Bug 33120682 - Adding PDB I/O Statistics in AWR Report (Doc ID 33120682.8) AWR Report – Exadata sections に新しいセクションの追加 Copyright © 2026, Oracle and/or its affiliates 369
  320. Exadata X10M Extreme Flash のデバイスのサポート AWR Report –Exadata セクションの機能拡張 Copyright

    © 2026, Oracle and/or its affiliates 370 X10M Extreme Flash support • Capacity-optimized Flash (F/14.0T) と Performance- optimized Flash (F/6.2T) を 別のデバイスとして表示できるようになった • Exadata Configuration and Statistics セクション すべてに適用される • 前世代のEFストレージ・サーバーでは 単一のフラッシュ・ディスク・タイプを表示していた • Oracle Database 19cにバックポート済み • Bug 34859550 - Add awr exadata support for capacity-optimized flash (Doc ID 34859550.8) X9M-2 EF X10M EF
  321. 【参考】 Join Filter (Bloom Filter) とは? p.p_color=‘pink' l.lo_partkey in (

    15, 38, 64, ….) 内部的に LINEORDER 表の カラムスキャンに変換 Lineorder Part partkey color=pink partkey in 15, 38, 64 partkey color Join Filter (Bloom Filter) SQL 処理内にて表結合を実施する際に、 結果対象ではないデータを結合前に、 効率よく排除する機能 SELECT … FROM LINEORDER l, PART p WHERE l.lo_partkey = p.p_partkey AND p.p_color=‘pink'; Copyright © 2026, Oracle and/or its affiliates 371
  322. 【参考】Join Filter を利用した場合の実行計画例 --------------------------------------------------- | Id | Operation | Name

    | --------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | SORT AGGREGATE | | |* 2 | HASH JOIN | | | 3 | JOIN FILTER CREATE | :BF0000 | |* 4 | TABLE ACCESS INMEMORY FULL| DATE_DIM | | 5 | JOIN FILTER USE | :BF0000 | |* 6 | TABLE ACCESS INMEMORY FULL| LINEORDER | --------------------------------------------------- Copyright © 2026, Oracle and/or its affiliates 372
  323. Exadata では、Join Filter を Storage Server で実施可能 【参考】 Join Filter

    を利用した2つの表の Join 処理イメージ DB Server ①ディメンション表に対し、Storage Server 側 でSmart Scanにて行・列抽出 ②抽出した結果を DB Server 側転送 ③Join Key について Bloom Filter を作成 0 1 0 1 1 0 0 1 ④全 Storage Server にBloom Filterを転送 0 1 0 1 1 0 0 1 ⑤ファクト表に対し、Bloom Filter を 使用して確実に該当しない行を 排除しつつSmart Scanにて行・ 列抽出 ⑥抽出した結果を DB Server 側に転送 ⑦各表の結果を Join Storage Server Copyright © 2026, Oracle and/or its affiliates 373
  324. 大規模な表でのハッシュ結合の高速化 データベースでは、ハッシュ結合内の小さい表が自動的に透過的に要約される 大規模な表に Bloom Filter を適用すると、データ量が削減され、結合が高速になる • Bloom Filter は、すべてのストレージ・サーバーに分散され、大規模表にパラレルに適用される

    • Database 23aiでは、より大きなサイズの Bloom Filter をオフロードできるようになり、結合内の大きな表からのデータを削減 Faster Hash Joins on Large Tables Copyright © 2026, Oracle and/or its affiliates 374 分析クエリの性能が、最大 2倍高速化 Large Table Small Table Hash Join Bloom Filter 無しでデータベース・サーバー上での結合 ストレージ・サーバー上でBloom Filter を利用しての結合 Large Table Small Table Hash Join B L O O M F I L T E R Exadata 24.1.0 ~
  325. • データベース・パフォーマンスの問題がExadataストレージ・サーバーのI/O負荷に関連する場合 • I/O関連の待機イベントのレイテンシが増加し、User I/OまたはSystem I/OのWait Class のデータベース時間が増加する • データベース・レイテンシの増加がExadataストレージ・サーバーのパフォーマンスによるものである場合

    • 増加したレイテンシもStorage Server 側の統計(Exadata Statistics)に示される • システムが適切に実行されている期間の包括的なベースライン統計がある場合 • ベースライン統計を他の観測データと比較して差異を特定する • 例:Oracle Databaseでcell single block physical readのレイテンシが増加した場合 • Storage Server の統計(Exadata Statistics)をチェックし、ベースラインと比較して、原因を判断 - ディスクI/Oの増加 - フラッシュ・デバイスのレイテンシーの増加 - その他の原因 • Exadata StatisticsにディスクI/Oリクエストの増加が示されている場合 - Exadataスマート・フラッシュ・キャッシュの変更に関連している可能性があるため、Exadataスマート・フラッシュ・キャッシュの統計を確認する • Exadata Statisticsにフラッシュからのsmall reads のレイテンシの増加が示されている場合 - I/Oパターンの変更が原因である可能性がある • 増加したI/Oのタイプ(Small Reads、Small Writes、Large Reads, Large Writes)を把握すると、調査を進める際に役立つ • 通常、Exadata環境では、すべてのStorage Server およびすべてのディスクにワークロードを均等に分散 • 1つのStorage Server または1つのディスクが他のStorage Serverまたは他のディスクよりも多くの作業を行っている場合、 そのStorage Serverまたはディスクがシステム全体の速度を低下させる可能性がある セル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 377
  326. • AWRレポートでExadataのI/O負荷を把握するのに特に役立つ各セクション • Disk Activity - AWR Report > Exadata

    Configuration and Statistics > Exadata Statistics > Performance Summary > Disk Activity • Exadata Resource Statistics - AWR Report > Exadata Configuration and Statistics > Exadata Statistics > Exadata Resource Statistics • Exadata IO Reasons - AWR Report > Exadata Configuration and Statistics > Exadata Statistics > Exadata IO Reasons • Internal IO Reasons - AWR Report > Exadata Configuration and Statistics > Exadata Statistics > Exadata IO Reasons > Internal IO Reasons セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 378
  327. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Performance Summary > Disk Activity セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 379
  328. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Performance Summary > Disk Activity セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 380 Smart Scans • Exadataスマート・フラッシュ・ キャッシュを使用して対応され ないSmart Scan リクエストのた めのディスク読取り • 通常、これらはLarge Reads • 詳細は、AWRレポートのSmart IOに記載 Flash Cache misses • リクエストされたデータが Exadataスマート・フラッシュ・ キャッシュの対象でない場合、 ディスク読取りが発生 • 詳細は、Flash Cache User Reads - Skips Redo Log Writes • REDOがディスクに書き込ま れるときにディスク書込みが 発生 • Exadataスマート・フラッシュ・ ログを使用する場合、REDO はExadataスマート・フラッ シュ・ログとオンラインREDOロ グ・ファイルの両方に書き込 まれる • Exadata 20.1~では、ディス ク・ストレージではなく Exadataスマート・フラッシュ・ キャッシュをライトバック・モー ドで使用する、スマート・フ ラッシュ・ログ・ライトバックを 利用 Flash Cache read skips • リクエストされたデータが Exadataスマート・フラッシュ・ キャッシュに存在しない場合、 ディスク読取りが発生 • 通常、これらはSmall Reads • 詳細は、Flash Cache User Reads Per Second の Misses を確認 Scrub IO • Exadata System Softwareがハード・ディス クを自動的に検査および修復するときに 発生 • Scrub I/Oはハード・ディスクがアイドル状 態のときに定期的に実行され、ほとんどの 場合Large Reads が発生し、ディスクが I/Oバウンドになると自動的に抑制される Flash Cache write skips, Flash Cache LW rejections • データがExadataスマート・フラッ シュ・キャッシュの対象でない場 合、ディスク書込みが発生 • 詳細は、Flash Cache User Writes - Skips と Flash Cache User Writes - Large Write Rejections を参照 Disk writer writes • ライトバック・モードのExadataスマート・ フラッシュ・キャッシュのデータがディスクに 永続化されるときに、Disk writer writes が発生 • 詳細は、AWRレポートのFlash Cache Internal Writes を確認
  329. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 381
  330. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Outlier Summary • 様々な外れ値サブセクションで識別される外れ値のサマリーが表示 • 統計平均値(Mean)、標準偏差(Standard Deviation)、 正常範囲(Normal Range)を表示 - 正常範囲(Normal Range) • 平均値と標準偏差に基づいて範囲を設定 - 観測された下限値と上限値ではない • Storage Server の場合、平均値から標準偏差±1の値の範囲 • ディスクの場合、平均値から標準偏差±3の値の範囲 • 外れ値(Outlier) - 標準範囲外のStorage Server またはディスク • 強調表示 - デバイスの予想される最大IOPS、またはデバイスの予想される最大ス ループット、を超えるStorage Serverまたはディスク • Disk Type - F: Flash 、H:HDD、M:pMem • 性能値(1デバイスあたり) - Maximum hard disk 容量: IOPS: H/12.5T: 213 IOPS - Maximum hard disk IO スループット MB/s: H/12.5T: 148 MB/s - Maximum flash disk capacity: IOPS: F/5.8T: 85,286 IOPS - Maximum flash disk IOスループット MB/s: F/5.8T: 6,250 MB/s セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 382
  331. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata OS Statistics Outliers • IOPS、スループット(MB/秒)、使用率、サービス時間、待機時 間、セル当たりのCPU使用率など、 • OS統計に基づいたStorage Server およびディスクの外れ値サ ブセクション セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 383
  332. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Cell Server Statistics Outliers セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 384 • IOPS、スループット(MB/秒)、使用率、サービス時間、待機時 間、Storage Server当たりのCPU使用率など、 • I/Oタイプ(Small Reads、Small Writes、Large Reads、Large Writes)でさらに分類
  333. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Cell Server Statistics Outliers (続き) セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 385
  334. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Cell Server IOPS Statistics - Outlier Cells / Exadata Cell Server IOPS Statistics - Outlier Disks セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 外れ値の表示例 Copyright © 2026, Oracle and/or its affiliates 386 • ハード・ディスクのスループット (IOPS)が予想される最大値を 超えている(ハイライトされ る) • 特定のディスクが明らかに他の ディスクよりも多くの小規模の 読取りを実行している
  335. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Outlier Details • 識別された外れ値の詳細情報と、外れ値に関連するその他 の統計 セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 387
  336. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata OS Statistics Top セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 388 • IOPS、レイテンシ、CPU使用率など、OS統計に基づいた Storage Server およびディスクの上位Nサブセクション
  337. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata OS Statistics Top (続き) セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 389
  338. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Cell Server Statistics Top セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 390 • IOPS、スループット(MB/秒)、使用率、サービス時間、待機時 間、Storage Server当たりのCPU使用率など、 • I/Oタイプ(Small Reads、Small Writes、Large Reads、Large Writes)でさらに分類
  339. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata Resource Statistics > Exadata Cell Server Statistics Top セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Copyright © 2026, Oracle and/or its affiliates 391
  340. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata IO Reasons セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Exadata IO Reasons Copyright © 2026, Oracle and/or its affiliates 392 • データベースがI/Oリクエストを Exadataに送信すると、そのリク エストにはI/Oの理由を含む情 報がタグ付けされている • IOを実行する理由を把握可能
  341. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata IO Reasons > Top IO Reasons by Requests セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 リクエスト別IO理由の例 Copyright © 2026, Oracle and/or its affiliates 393 • リクエスト別の上位IO Reason およびMB別の上位IO Reason(スループット)を表示 • Smart ScanのIOの割合が多い
  342. Top IO Reasons by Requests のエンハンス AWR Report –Exadata セクションの機能拡張

    Copyright © 2026, Oracle and/or its affiliates 394 Top IO Reasons by Requests • ストレージ・サーバーでI/Oが 実行される理由を表示 • I/O Reasons セクションが エンハンスされて以下を表示: • I/O type - reads/writes • I/O media - flash/disk Previous Version
  343. AWR Report > Exadata Configuration and Statistics > Exadata Statistics

    > Exadata IO Reasons > Internal IO Reasons セル・ディスクI/Oの監視 AWRを使用したセル・ディスクI/Oの監視 Internal IO Reasons の例 Copyright © 2026, Oracle and/or its affiliates 395 • Disk Writer がライトバック・モー ドでExadataスマート・フラッ シュ・キャッシュから読み取り、 データをディスクに永続化すると きに、フラッシュ読取りが発生 • Disk Writerがライトバック・モー ドでExadataスマート・フラッ シュ・キャッシュからディスクに データを永続化するときに、ディ スク書込みが発生 • リクエストされたデータが Exadataスマート・フラッシュ・ キャッシュに読み込まれるときに、 フラッシュ書込みが発生。デー タがディスクから読み取られると、 Exadataスマート・フラッシュ・ キャッシュにも移入される。多く の場合、これはフラッシュ・キャッ シュ・ミスと相関関係がある • 新しいデータがライトバック・モードでExadataス マート・フラッシュ・キャッシュに書き込まれるときに、 フラッシュ書込みが発生する。多くの場合、これ は最初の書込みが原因で発生する
  344. データベース統計 統計 説明 physical read IO requests データベースによって発行された物理読取りリクエストの数 physical read

    requests optimized Exadataスマート・フラッシュ・キャッシュを使用して対応された読取りリクエストと、Storage Indexまたは列キャッシュを 使用することによって回避された読取りリクエストの合計数 physical read total bytes 読取りがストレージ・サーバーにオフロードされたかどうかに関係なく、データベースによって発行された読取りの合計 I/Oバイト数 physical read total bytes optimized Exadataスマート・フラッシュ・キャッシュから読み取られたバイト数と、Storage Indexまたは列キャッシュを使用して回避 されたバイト数の合計 physical read total IO requests すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベース によって発行された読取りリクエストの合計数 physical write IO requests データベースによって発行された物理書込みリクエストの数 physical write total bytes すべてのアクティビティに対してデータベースによって発行された書込みの合計IOバイト数 physical write total bytes optimized Exadataスマート・フラッシュ・キャッシュに書き込まれた合計バイト数。これらのバイトはレイジー方式でディスクに同期 されます physical write total IO requests すべてのアクティビティ(アプリケーション、バックアップ、リカバリおよびその他のユーティリティを含む)に対してデータベース によって発行された書込みリクエストの合計数 データベース統計および待機イベントを使用したセル・ディスクI/Oの監視(1) Copyright © 2026, Oracle and/or its affiliates 396
  345. 待機イベント 統計 説明 cell list of blocks physical read この待機イベントは、リカバリ中またはバッファのプリフェッチ中(複数の単一ブロック読取りの実行ではない)に発生する。

    これは、リカバリの一環として変更する必要があり、データベースに対してパラレルで読み取られるデータベース・ブロッ クを監視するために使用される。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、Storage Server のdb file parallel readと同等。 cell list of blocks read request これはcell list of blocks physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示さ れる。待機イベントが終了すると、プレースホルダは通常cell list of blocks physical readに変換される。 cell multiblock physical read (Storage Serverの複数ブロックの物理読込み) この待機イベントは、マルチブロック・データベース読取りのすべてのI/Oの実行に要した時間を表す。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、Storage Serverのdb file scattered readと同等。 cell multiblock read request これはcell multiblock physical readに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示され る。待機イベントが終了すると、プレースホルダは通常cell multiblock physical readに変換される。 データベース統計および待機イベントを使用したセル・ディスクI/Oの監視(2) Copyright © 2026, Oracle and/or its affiliates 397
  346. 待機イベント 統計 説明 cell single block physical read (Storage Serverの単一ブロックの物理読込み)

    この待機イベントは、単一ブロック・データベースI/Oの実行に要する時間を表す。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれまる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、Storage Serverのdb file sequential readと同等。 2022年5月のRU(19.15.0.0.220419、21.6.0.0.220419以降)以降では、この待機イベントには、Exadataスマート・フラッシュ・ キャッシュのI/O、PMEMキャッシュのI/O、またはリモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用したデータベースの I/Oが含まれなくなった。 cell single block physical read: flash cache この待機イベントは、Exadataスマート・フラッシュ・キャッシュから単一ブロック・データベースI/Oの実行に要する時間を表す。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータ(キャッシュの場所ではない)を含むグリッド・ディスクのディスク・ハッシュ番 号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、2022年5月のRUで導入され、Oracle Database 19.15.0.0.220419、21.6.0.0.220419以降に存在する。 以前は、cell single block physical readにこれらの待機が含まれていた。 cell single block physical read: xrmem cache cell single block physical read: pmem cache この待機イベントは、PMEMキャッシュから単一ブロック・データベースI/Oの実行に要する時間を表す。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータ(キャッシュの場所ではない)を含むグリッド・ディスクのディスク・ハッシュ番 号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、2022年5月のRUで導入され、Oracle Database 19.15.0.0.220419、21.6.0.0.220419以降に存在する。 以前は、cell single block physical readにこれらの待機が含まれていた。 データベース統計および待機イベントを使用したセル・ディスクI/Oの監視(3) Copyright © 2026, Oracle and/or its affiliates 398
  347. 待機イベント 統計 説明 cell single block physical read: RDMA この待機イベントは、リモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用して単一ブロック・データベースI/Oの

    実行に要する時間を表す。 V$SESSIONでは、このイベントに関連付けられたレコードに、次の追加パラメータが含まれる。 •P1には、V$CELL.CELL_HASHVALに対応する関連するストレージ・サーバーのハッシュ番号が含まれる。 •P2は、V$ASM_DISK.HASH_VALUEに対応するデータを含むグリッド・ディスクのディスク・ハッシュ番号を識別する。 •P3は、I/O読取り操作中に処理されるバイト数を指定する。 この待機イベントは、2022年5月のRUで導入され、Oracle Database 19.15.0.0.220419、21.6.0.0.220419以降に 存在する。以前は、cell single block physical readにこれらの待機が含まれていた。 cell single block read request これは、単一ブロック・データベースI/Oに関連付けられたプレースホルダ待機イベントで、待機期間中にのみ表示され る。待機イベントが終了すると、プレースホルダは適切な待機イベント(通常はcell single block physical readイベン トの1つ)に変換されます。 cell interconnect retransmit during physical read この待機イベントは、単一ブロック読取りまたはマルチブロック読取りのI/Oの再転送中に表示される。 V$SESSION_WAITビューのP1列のセル・ハッシュ番号は、cell single block physical readおよびcell multiblock physical readで識別されるStorage Serverと同じ。P2列には、Storage Serverに対するサブネット番号が格納され、 P3列には、I/O読取り操作中に処理されたバイト数が格納される。 データベース統計および待機イベントを使用したセル・ディスクI/Oの監視(4) Copyright © 2026, Oracle and/or its affiliates 399
  348. Wait Event AWR Report –Exadata セクションの機能拡張 Copyright © 2026, Oracle

    and/or its affiliates 400 Wait Events • single block read のExadata Wait Event が追加 • cell single block physical read: RDMA • リモート・ダイレクト・メモリー・アクセス(RDMA)読取りを使用して、 シングル・ブロック・データベースI/Oの実行に要する時間 • cell single block physical read: flash cache • Exadata Smart Flash Cacheから シングル・ブロック・データベースI/Oの実行に要する時間 • cell single block physical read: xrmem cache • XRMEMキャッシュから シングル・ブロック・データベースI/Oの実行に要する時間 • XRMEMキャッシュを効果的に使用すると、 この待機イベントのレイテンシが非常に短くなる • Oracle Database 19c にバックポート済み • Bug 33354011 - Cell single block physical read - New Wait Events (Doc ID 33354011.8) • 19.15.0.0.220419 (April 2022) DB Release Update (DB RU) • Bug 33402406 - AWR Exadata: include all cell single block physical read waits in summary (Doc ID 33402406.8) • 19.16.0.0.220719 (July 2022) DB Release Update (DB RU)
  349. IORMデータベース間プランにリストされた各データベースからのI/O負荷に関する情報を提供 • objectType= CELLDISK であるMETRICCURRENT、METRICDEFINITIONおよびMETRICHISTORYオブジェクト • CD_IO_LOAD • "Average I/O

    load for the cell disk" セル・ディスクの平均I/O負荷 • I/O負荷によってディスク・キューの長さが決まる。iostatのavgqu-szに似ているが、I/O負荷はディスクのタイプ応じて重みが付けられた値 - ハード・ディスクの場合:large I/Oの重みはsmall I/Oの3倍 - フラッシュ・ディスクの場合:large I/Oとsmall I/Oの重みは同じ • 対応するメトリックは、各データベース(DB_IO_LOAD)、プラガブル・データベース(PDB) (PDB_IO_LOAD)、IORMカテゴリ(CT_IO_LOAD)、 コンシューマ・グループ(CG_IO_LOAD)ごとにも使用可能 • CD_IO_ST_RQ • "Average service time per request for small IO requests to a cell disk” • フラッシュ・デバイスには使用不可能(iostatの使用を参照) • CD_IO_UTIL • "Percentage of disk resources utilized for the cell disk" • ハード・ディスクのiostatの%utilに似ているが、iostatの使用で説明されているようにフラッシュ・デバイスには使用不可能。 フラッシュ・デバイスの場合、これは製品データ・シートで指定された、システムの最大I/O帯域幅の割合になる • このメトリックはIORMによって計算されるため、データベース、PDBおよびコンシューマ・グループごとに使用することも可能 • レイテンシ・メトリックの測定単位はマイクロ秒。レイテンシ・メトリックのメトリック名は、CD_IO_TM_で始まる データベース・メトリックを使用したセル・ディスクIOの監視 Copyright © 2026, Oracle and/or its affiliates 401 CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = CELLDISK
  350. 不均衡 • Exadata環境では、すべてのStorage Serverまたはディスクに負荷を均等に分散することが推奨 • 負荷の不均衡が発生する可能性があるワークロード 1. 小さい表のスキャンの繰返し - ネステッド・ループ結合の右側の表が原因で発生

    - 小規模の表は少数のディスクまたはStorage Serverにのみ存在する可能性があるため、繰返しアクセスは、小さいデバイス・セット(データがExadataスマート・フラッシュ・キャッシュに存在す る場合はフラッシュ・デバイス)からの読取りを意味する - 不均衡に対処するために、影響を受けるSQL文を特定し、その実行計画を確認する。また、影響を受けるセグメントの物理構成を考慮する 2. 制御ファイルの読取りの繰返し - 制御ファイルの読取りは、一部のデータベース動的パフォーマンス・ビューに対する問合せが原因で発生する場合がある。 制御ファイルは小さく、少数のディスクまたはStorage Serverにのみ存在する可能性があるため、繰返しアクセスは、小さいデバイス・セット(通常はフラッシュ)からの読取りを意味する。 制御ファイルの読取りが繰り返されていることは、AWRレポートの IOStat by File Type セクションの control file sequential read 待機イベントからわかる - 制御ファイルの読取りが繰り返される原因を把握するには、AWRレポートのExadata IO Reasons セクションを使用して、多数の制御ファイルの読取りを処理するStorage Serverを識別し、 Top Databases セクションの統計と相互に関連付けて、制御ファイルの読取りを発行するデータベースを識別する。また、アクティブ・セッション履歴(ASH)を確認して、 control file sequential readの待機が発生しているSQL文を特定する - 負荷の軽いシステムでは、制御ファイルの読取りにより、不均衡な少量のI/Oが発生する場合があることに注意する。この場合、不均衡は無視して問題ない 3. LOBセグメントなどの小さいセグメントの読取りの繰返し - このような不均衡に対処するには、セグメントのデータベース統計を確認するか、ASHを調べて原因となるSQLコマンドを特定する。次に、SQLおよび周囲のアプリケーション・ロジックを調べ て、繰返し読取りを回避できるかどうかを確認する 4. ASMメタデータへのアクセスの繰返し - これは多くの場合、ASMメタデータへのアクセスが必要な、領域使用量に関連するデータベース問合せが原因 - ASMメタデータは小さく、少数のディスクまたはセルにのみ存在する可能性があるため、繰返しアクセスは不均衡として表示される場合がある - AWRレポートのExadata IO Reasons セクションに、ASMの接頭辞(ASM CACHE IOなど)が付いた理由とともに表示される場合がある - Exadata IO Reasonsセクションを使用して影響を受けるStorage Serverを識別し、これを Top Databases セクションの統計と相互に関連付けて、ASMをI/Oのソースとして確認できる。不 均衡に対処するには、メタデータにアクセスするASM領域使用量問合せの必要性と頻度を確認する セル・ディスクI/Oを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 403
  351. 不均衡(続き) • ワークロード関連の原因とは別に発生する不均衡の原因 1. データ分散が不均等 - 一部のディスクに含まれるデータが他のディスクよりも多いまたは少ない場合、ホット・スポットが発生することがある - データ分散が均等であるかをチェックするには、大規模な全表スキャンを含むSQL問合せの実行前後にV$ASM_DISK_IOSTATビューを問い合せる。 この場合、read列とread_bytes列の統計は、ディスク・グループ内のすべてのディスクでほぼ同じである必要がある

    - My Oracle Supportのドキュメント367445.1で入手できるスクリプトを使用して、データ分散が均等であるかをチェック可能 • Script to Report the Percentage of Imbalance in all Mounted Diskgroups- Non Exadata/ODA (Doc ID 367445.1) 2. グリッド・ディスク構成が非対称 - グリッド・ディスクのサイズがStorage Serverごとに異なる場合は、各Storage Serverのデータ量が異なる可能性があるため、不均等なデータ分散が原因で不均衡になる - システム内のすべてのストレージ・サーバーで対称な構成を推奨 3. 障害または障害からのリカバリ - 一部の処理では、残りのディスクまたはStorage Serverに均等に分散できなくなる場合がある - たとえば、フラッシュ・カードに障害が発生した場合、そのカードを含むStorage Serverのフラッシュ・キャッシュ領域は少なくなり、フラッシュ・キャッシュ統計が他のStorage Serverと比較されると不均衡として表示されることがある • 不均衡は、多くの場合、AWRレポートの様々な統計に表示される。AWRレポートの様々なセクションを相互に関連付けることで、不均衡を判別可能 セル・ディスクI/Oを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 404
  352. Internal IO • AWRレポートでは、Top IO Reasons の中に Internal IO が報告されている場合は、Internal

    IO Reasons を要約したセクションも含められる。 このセクションを使用して、Internal IO の構成を理解すること。 • セル・ディスクI/Oを監視する際の注意事項 Copyright © 2026, Oracle and/or its affiliates 406
  353. Exadata マニュアルは、下記で公開されています。 • 英語版 https://docs.oracle.com/en/engineered-systems/exadata-database-machine/books.html • 日本語版 https://www.oracle.com/jp/database/technologies/oracle-exadata-database-machine-documentation.html • 最新の情報は、英語版から反映されます点、ご注意ください。

    • Exadata Database Machine – Concept and Administration Books • Extending and Multi-Rack Cabling Guide for Engineered Systems (DBMMR) – マルチラック・ケーブリング情報 • Installation and Configuration Guide for Exadata Database Machine (DBMIN) – 設置、インストール関連情報 • Maintenance Guide for Exadata Database Machine (DBMMN) – メンテナンス一般 ・仮想化管理情報 • Oracle Exadata Exascale User‘s Guide (EXSCL) - Exascale関連 • Security Guide for Engineered Systems (DBMSQ) – セキュリテ関連情報 • System Overview for Exadata Database Machine (DBMSO) – 概要・新機能情報 • System Software User‘s Guide for Exadata Database Machine (SAGUG) – Exadata System Software 情報 • Licensing Information User‘s Guide for Exadata Database Machine (DBMLI)- ライセンス情報 • Oracle Auto Service Request Quick Installation Guide for Oracle Exadata Database Machine • Oracle Engineered System Safety and Compliance Guide • Enterprise Manager Oracle Exadata Database Machine Getting Started Guide 製品マニュアル Copyright © 2026, Oracle and/or its affiliates 408
  354. • IT Infrastructure > Engineered Systems > Exadata • 英語版

    - https://www.oracle.com/engineered-systems/exadata/database-machine/ • 日本語版 - https://www.oracle.com/jp/engineered-systems/exadata/database-machine/ - データシートなどが確認可能 • Database > Technologies > Oracle Exadata Database Machine • 英語版 - https://www.oracle.com/database/technologies/exadata/ • 日本語版 - https://www.oracle.com/jp/database/technologies/exadata/ - OECA と OEDA のダウンロード、データシートやベスト・プラクティスのホワイトペーパーなどへのリンク Oracle.com 製品情報 Copyright © 2026, Oracle and/or its affiliates 409
  355. Exadata 関連重要 Note • Exadata Database Machine and Exadata Storage

    Server Supported Versions (KB153930旧Doc ID 888828.1) • Oracle Exadata Best Practices (Doc ID 757552.1)→MOSC移行で削除 • Oracle Exadata Database Machine EXAchk (KB74841 旧Doc ID 1070954.1) My Oracle Support Copyright © 2026, Oracle and/or its affiliates 410
  356. Exadata System Software の進化① Exadata System Software 追加機能 / 拡張

    DB GI HW 11.2.1.2 Exadata Smart Flash Cache Hybrid Columnar Compression Storage Index Smart Scan of Encrypted Data Interleaved Grid Disks Data Mining Scoring Offload 11.2.2.3 Oracle Solaris Operating System for Database Servers Exadata Secure Erase Optimized Smart Scan 11.2.2.4 Oracle Exadata Smart Flash Log 11.2.0.2 BP11 or later Copyright © 2026, Oracle and/or its affiliates 413
  357. Exadata System Software の進化② Exadata System Software 追加/拡張 機能 DB

    GI HW 11.2.3.1 Support for Oracle Solaris 11 Linux Database Server Updates with Unbreakable Linux Network Oracle Enterprise Manager Cloud Control for Oracle Exadata Database Machine I/O Resource Management Support for More Than 32 Databases Oracle Database 11g Release 2 (11.2.0.3) Exadata Cell Connection Limit 11.2.3.2 Write-Back Flash Cache with Exadata Smart Flash Cache 11.2.0.3.9 , 11.2.0.4.1 or later Graceful Shutdown of CELLSRV Services LED Notification for Storage Server Disk Removal Identification of Underperforming Disks Oracle Database File System Support for Oracle Solaris Health Factor for Predictive Failed Disk Drop Hard Disk Drive Numbering in Servers Copyright © 2026, Oracle and/or its affiliates 414
  358. Exadata System Software の進化③ Exadata System Software 追加/拡張 機能 DB

    GI HW 11.2.3.3.0 Flash Cache Compression X3 or X4 Automatic Flash Caching for Table Scan Workloads Fast Data File Creation 11.2.0.4 , 12.1.0.1 or later Network Resource Management 11.2.0.4 , 12.1.0.1 or later ※switch firmware release 2.1.3-4 Active Bonding Network X4 or later Oracle ASM Disk Group in Appliance Mode 11.2.0.4 , 12.1.0.2 or later Automatic Hard Disk Scrub and Repair 11.2.0.4 , 12.1.0.2 or later Drop Hard Disk for Replacement Drop BBU for Replacement Oracle Exadata Database Machine Eighth Rack Configuration Cell Alert Summary Secure Erase for Larger Drives Periodic ILOM Reset Oracle ExaWatcher Replaces Oracle OSwatcher Copyright © 2026, Oracle and/or its affiliates 415
  359. Exadata System Software の進化④ Exadata System Software 追加/拡張 機能 DB

    GI HW 11.2.3.3.1 Oracle Capacity-on-Demand for Database Servers X4 or later Exadata I/O Latency Capping 11.2.0.4 BP8 or later Exadata Cell I/O Timeout Threshold 11.2.0.4 BP8 or later 12.1.1.1.0 Support for Oracle Database Releases 12c Release 1 (12.1) and 11g Release 2 (11.2) IORM Support for Container Databases and Pluggable Databases 12.1 or later Cell to Cell Data Transfer 12.1 or later Desupport of HP Oracle Database Machine Hardware 12.1.1.1.1 Additional SQL Operators and Conditions for LOB and CLOB 12.1.0.2 or later ※ 11.2.3.3.1 と同時対 応 Oracle Capacity-on-Demand for Database Servers Exadata I/O Latency Capping 11.2.0.4 BP8 or later Exadata Cell I/O Timeout Threshold 11.2.0.4 BP8 or later Copyright © 2026, Oracle and/or its affiliates 416
  360. Exadata System Software の進化⑤ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.1.2.1.0 Oracle Exadata Database Machine Elastic Configurations Sparse Grid Disks 12.1.0.2 BP5 or later Snapshot Databases for Test and Development 12.1.0.2 BP5 or later X3 or later Columnar Flash Caching 12.1.0.2.0 or later Oracle Exadata System Software I/O Latency Capping for Write Operations 11.2.0.4 BP8 , 12.1.0.2 or later Elimination of False Drive Failures X5 Flash and Disk Life Cycle Management Alert 12.1.0.2 BP4 or later Performance Optimization for SQL Queries with Minimum or Maximum Functions 12.1.0.2 or later Oracle Exadata System Software Performance Statistics in AWR Reports 12.1.0.2 or later Management Server on Database Servers SQL Operators for JSON and XML 12.1.0.2 or later for JSON 12.1.0.2 BP1 or later for XML Copyright © 2026, Oracle and/or its affiliates 417
  361. Exadata System Software の進化⑥ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.1.2.1.0 I/O Resource Management for Flash X2 or later Flash Cache Space Resource Management 11g , 12.1.0.2 or later X2 or later I/O Resource Management Profiles 12.1.0.2 BP4 or later Write Back Flash Cache on Extreme Flash Cells Secure Erase for 1.6 TB Flash Drives in Extreme Flash and High Capacity Systems Increased Exadata Cell Connection Limit Support for SNMP v3 Federal Information Processing Standards (FIPS) 140-2 Compliant Smart Scan 11.2.0.4 BP6 , 12.1.0.2.0 BP3 or later Oracle Exadata Virtual Machines X2 or later 12.1.2.1.1 Exafusion Direct-to-Wire Protocol 12.1.0.2 BP6 or later X2 or later 12.1.2.1.2 InfiniBand Partitioning for Virtualized Exadata Environments Copyright © 2026, Oracle and/or its affiliates 418
  362. Exadata System Software の進化➆ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.1.2.2.0 IPv6 Support Running CellCLI Commands from Compute Nodes Disabling SSH on Storage Servers Fixed Allocations for Databases in the Flash Cache Increased Maximum Number of Database Processes Custom Diagnostic Package for Storage Server Alerts Updating Nodes Using patchmgr kdump Operational for 8-Socket Database Nodes Redundancy Check When Powering Down the Storage Server Specifying an IP Address for SNMP Traps Reverse Offload Improvements 12.1.0.2 BP1 or later Cell-to-Cell Rebalance Preserves Flash Cache Population 12.1.0.2 BP11 or later Smart Fusion Block Transfer 12.1.0.2 BP13 or later Copyright © 2026, Oracle and/or its affiliates 419
  363. Exadata System Software の進化⑧ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.1.2.3.0 Performance Improvement for Storage Server Software Updates Quorum Disk Manager Utility Grid Infrastructure release 12.1.0.2.160119 with these patches: 22722476 and 22682752; or Grid Infrastructure release 12.1.0.2.160419 or later VLAN Support Adaptive Scrubbing Schedule 11.2.0.4.16 (April 2015) or higher 12.1.0.2.4 (January 2015) or higher IPv6 Support in ASR Manager ASR Manager 5.4 or later Increased Maximum Number of Database Processes Oracle Database 12c Release 1 (12.1) release 12.1.0.2.160119 with these patches: 22711561, 22233968, and 22609314 Cell-to-Cell Rebalance Preserves Storage Index Grid Infrastructure release 12.1.0.2.160119 with patch 22682752 ASM Disk Size Checked When Reducing Grid Disk Size Grid Infrastructure release 12.1.0.2.160119 with patch 22347483 Support for Alerts in CREATE DIAGPACK Copyright © 2026, Oracle and/or its affiliates 420
  364. Exadata System Software の進化➈ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.2.1.1.0 In-Memory Columnar Caching on Storage Server Oracle Database 12c release 1 (12.1.0.2) ,Oracle Database 12c release 2 (12.2.0.1) Minimum:12.1.0.2.161018 DBBP Columnar Flash Cache for Encrypted Tablespace Oracle Database 12c release 1 (12.1.0.2) ,Oracle Database 12c release 2 (12.2.0.1) Minimum:12.1.0.2.161018 DBBP Set Membership in Storage Index Oracle Database 12c release 1 (12.1.0.2) ,Oracle Database 12c release 2 (12.2.0.1) Minimum:12.1.0.2.161018 DBBP Storage Index to Store Column Information for More Than Eight Columns 5X Faster Storage Server Software Updates Copyright © 2026, Oracle and/or its affiliates 421
  365. Exadata System Software の進化➉ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.2.1.1.0 Faster Performance for Large Analytic Queries and Large Loads if you are using Oracle Database 11g release 2 (11.2) or Oracle Database 12c release 1 (12.1), then you need the patches for bug 24944847. V2,X2 はサポー ト外、X3,X4 出 flashcache compress使用 時はサポート外 Secure Eraser V2 以降 Cell-to-Cell Offload Support for Oracle ASM-Scoped Security Adding an Additional Network Card to Oracle Exadata X6-2 Database Servers X6-2 Automatic Diagpack Upload for ASR ASR Manager Release 5.6 - Rescue Plan Support for IPv6 OVM and Tagged VLANs Management Server Can Remain Online During NTP, DNS, and ILOM Changes New Charts in ExaWatcher Copyright © 2026, Oracle and/or its affiliates 422
  366. Exadata System Software の進化⑪ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.2.1.1.0 New Metrics for Redo Log Writes Quarantine Manager Support for Cell-to-Cell Rebalance and High Throughput Write Operations CREATE DIAGPACK and LIST DIAGPACK Commands Available for Database Servers ExaCLI and REST API Enabled for Management Server Oracle ASM Flex Disk Groups Oracle Grid Infrastructure 12c release 2 (12.2.0.1) Oracle Flex ASM Oracle Grid Infrastructure 12c release 2 (12.2.0.1) Faster Redundancy Restoration After Storage Loss Oracle Grid Infrastructure 12c release 2 (12.2.0.1) Dynamic Power Change Oracle Grid Infrastructure 12c release 2 (12.2.0.1) Quorum Disk Support in Oracle Installer Oracle Grid Infrastructure 12c release 2 (12.2.0.1) Copyright © 2026, Oracle and/or its affiliates 423
  367. Exadata System Software の進化⑫ Exadata System Software 追加/拡張 機能 DB

    GI HW 12.2.1.1.0 Database Server I/O Latency Capping Oracle Database and Oracle Grid Infrastructure 12c release 2 (12.2.0.1.0) Exadata Smart Scan Offload for Compressed Index Scan Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) Exadata Smart Scan Offload Enhancements for In- Memory Aggregation (IMA) Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) Exadata Smart Scan Offload Enhancements for XML Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) Exadata Smart Scan Offload Enhancements for LOBs Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) New Features in Oracle Exadata Snapshots Oracle Database and Oracle Grid Infrastructure 12c release 2 (12.2.0.1.0) X3 以降 Oracle Linux Kernel Upgraded to Unbreakable Enterprise Kernel 4 and OVM Upgraded to 3.4.2 If you use Oracle ASM Cluster File System (Oracle ACFS), then you must apply the fix for bug 22810422 prior to the upgrade of the Oracle Grid Infrastructure home to enable Oracle ACFS support on the UEK4 kernel. Oracle recommends that you install the fix for bug 23642667 on both the Oracle Grid Infrastructure home and the Oracle Database home to increase OLTP workload performance. Copyright © 2026, Oracle and/or its affiliates 424
  368. Exadata System Software の進化⑬ Exadata System Software 追加/拡張 機能 DB

    GI HW 18.1.0 In-Memory OLTP and Consolidation Acceleration 12.2.0.1 April 2018 DBRU または 18.1 以降 X6 以降 In-Memory Columnar Caching on Storage Servers 12.1.0.2.170418 DBBP 必須 , 12.1.0.2.171017 DBBP 推 奨 12.2.0.1.170620 DBRU 必須, 12.2.0.1.171017 DBRU 推 奨 Oracle Exadata Storage Server Cloud Scale Software Update Faster Oracle Exadata Database Server Software Update Improved Ethernet Performance in Oracle VM Performance Improvement Following Disk Online Completions Improved High Availability After Flash Failures IORM Maximum Utilization Limit Applies to Flash Devices OEDA Command Line Interfaces OEDA, August 2017 Release 以降 Do-Not-Service LED on Storage Servers 12.1.0.2.171017 DBBP + 26333141 または 12.1.0.2.171017 DBBP 12.2.0.1.170718DBRU + 26333141 または 12.2.0.1.171017 DBRU X7 以降 Online Flash Disk Replacement Exadata X7 Storage Servers X7 以降 New Configurations on System Partitions on Storage Servers X7 以降 Secure Boot X7 以降 (Bare Metal のみ) Copyright © 2026, Oracle and/or its affiliates 425
  369. Exadata System Software の進化⑭ Exadata System Software 追加/拡張 機能 DB

    GI HW 19.1.0 Oracle Linux Upgraded to Oracle Linux 7.5 - Server Time Synchronization Uses Chrony - Quorum Disk Manager Service Change - Audit Rules File Automated Cloud Scale Performance Monitoring Faster Smart Scans Using Column-level Checksum Enhanced OLTP High Availability During Cell Outages and Flash Failures Oracle Database 19c X6 HC 以降 Support for Host and ILOM on Separate Network DB_UNIQUE_NAME Support for Multiple Clusters Sharing Exadata Storage Secure Eraser Updates - Automatic Upgrading of Multi-pass Disk Erasure to Secure Eraser - Automatic Secure Eraser as Part of Imaging - Secure Eraser Improvements and New Features X5 以降 Customizable SYSLOG Format USE_LARGE_PAGES Default Value Set To AUTO_ONLY Copyright © 2026, Oracle and/or its affiliates 426
  370. Exadata System Software の進化⑮ Exadata System Software 追加/拡張 機能 DB

    GI HW (V2 以前は ノンサポート) 19.1.0 Security Improvements - Access Control for RESTful Service - Password Expiration for Remote Users - Advanced Intrusion Detection Environment (AIDE) - Implementing the Principle of Least Privilege to Improve Security - Increased Security for Storage Server Processes - SSHD ClientAliveInterval Changed to 600 Seconds - Stronger Password Requirements - Upload DIAGPACK to Oracle ASR Manager using HTTPs Deprecated Features - Interleaved Grid Disks - nfsimg Images Desupported Features - Exadata V2 V2 19.2.0 Support for New Hardware - X8 Servers X8 Oracle Exadata Storage Server X8-2 Extended (XT) X8 Changes to IORM flashcachesize Attribute and Hard Disk I/O limits Copyright © 2026, Oracle and/or its affiliates 427
  371. Exadata System Software の進化⑯ Exadata System Software 追加/拡張 機能 DB

    GI HW (X2 以前は ノンサポート) 19.3.0 Persistent Memory Data Accelerator 19c X8M Persistent Memory Commit Accelerator 19c X8M Support for Oracle Exadata X8M Systems X8M Instant Failure Detection for X8M Systems X8M KVM for Virtual Environment X8M Faster Encrypted Table Smart Scans Smart Aggregation 18c 以降 Smart In-Memory Columnar Cache with Row IDs 18c 以降 Smart In-memory Columnar Cache with Chained Rows Fast Smart In-memory Columnar Cache Creation Encryption of System Logs to Remote Destinations Update a Single SNMP User Definition Securing Storage Server Software Processes with Memory Protection Keys X7 以降 Default XFS File System for X8M Servers X8M Oracle Linux Kernel to Unbreakable Enterprise Kernel 5 and Oracle Linux Distribution Upgraded to Oracle Linux 7.7 Software Certification Ends for Exadata Database Machine X2 Servers X2 Copyright © 2026, Oracle and/or its affiliates 428
  372. Exadata System Software の進化⑯ Exadata System Software 追加/拡張 機能 DB

    GI HW (X2 以前は ノンサポート) 20.1.0 Exadata Secure RDMA Fabric Isolation 19.6.0.0.200114 with patches 18.8.0.0.191015 with patches 12.2.0.1.191015 with patches 12.1.0.2.180831 11.2.0.4.180717 19.6.0.0.200114 with patches 18.8.0.0.191015 with patches 12.2.0.1.191015 with patches 12.1.0.2.190716 with patches X8M Smart Flash Log Write-Back X7 以降 Fast In-Memory Columnar Cache Creation Cell-to-Cell Rebalance Preserves PMEM Cache Population X8M Control Persistent Memory Usage for Specific Databases X8M Application Server Update for Management Server Copyright © 2026, Oracle and/or its affiliates 429
  373. Exadata System Software の進化⑱ Exadata System Software 追加/拡張 機能 DB

    GI HW (X2 以前は ノンサポート) 21.2 Exadata X9M Support Persistent Storage Index 12.2 Persistent Columnar Cache IORM Cluster Plan Smart Scan Metadata Sharing Oracle ASR Support for Cisco RoCE Network Fabric Switches and Management Network Switch X8M Patch Manager Support for the Management Network Switch X7 Options to Preserve Redundancy while Dropping a Physical Disk Faster Upgrades with ILOM Pre-Staging X7 Faster Recovery from Flash Cache Failure X7 Automatic Recovery from Disk Controller Cache Failure Enhanced Database Server Alerting Oracle ACFS I/O Caching in Flash Cache Smart Scan Fast Decryption X9M Caching Flashback Log Writes in Exadata Smart Flash Cache Deprecated Features in Oracle Exadata System Software Release 21.2 Copyright © 2026, Oracle and/or its affiliates 430
  374. Exadata System Software の進化⑲ Exadata System Software 追加/拡張 機能 DB

    GI HW (X2 以前は ノンサポート) 22.1 Real-Time Insight Oracle VM Server Management Domain Upgrade to Oracle Linux 7 Exadata Upgrade Improvements X8-2以前 Deprecation of RAM Cache Deprecation of USB Images Copyright © 2026, Oracle and/or its affiliates 431
  375. Exadata System Software の進化⑳ Exadata System Software 追加/拡張 機能 DB

    GI HW (X4 以前は ノンサポート) 23.1 Oracle Exadata X10M Support X10M Exadata RDMA Memory X8M Higher Compression for Storage Server Columnar Compression X10M Oracle Linux 8 Support Centralized Identification and Authentication of OS Users Minimum Versions and Other Requirements 19.15 19.15 X5-2 PMEM cache only operates in write-through mode Copyright © 2026, Oracle and/or its affiliates 432
  376. Exadata System Software の進化㉑ Exadata System Software 追加/拡張 機能 DB

    GI HW (X5 以前は ノンサポート) 24.1 AI Smart Scan 23ai 23ai Oracle Exadata Exascale 23.5 23.5 X8M Increased Number of Virtual Machines on Database Servers X10M Columnar Cache on Exadata RDMA Memory (XRMEM) X10M Exadata Cache Observability Automatic Loading of KEEP Objects into Exadata Smart Flash Cache 23ai 23ai Improved RoCE Network Resilience X8M Enhanced RoCE Network Discovery X8M Exadata Live Update Ready-to-go System Image for New KVM Guests X8M KVM Guest Secure Boot X8M SNMP Security Enhancements JSON Output from Management Server Minimum Versions and Other Requirements 19.15 19.15 X6-2 Copyright © 2026, Oracle and/or its affiliates 433
  377. Exadata System Software の進化㉒ Exadata System Software 追加/拡張 機能 DB

    GI HW (X5 以前は ノンサポート) 24.1 Features Coupled with Oracle Database 23ai 23ai 23ai Smart Scan on Wide Tables 23ai 23ai Smart Scan on Index-Organized Tables 23ai 23ai Smart Scan on AES-XTS Encrypted Data 23ai 23ai Smart Scan during Online Encryption 23ai 23ai Smart Scan during Timezone Upgrades 23ai 23ai Smart Scan for Oracle Database 23ai Functions and Operators 23ai 23ai In-Memory Columnar Speed JSON Query 23ai 23ai Transparent Cross-Tier Scan 23ai 23ai Faster Opening of Pluggable Databases 23ai 23ai Pipelined Log Writes 23ai 23ai Faster Hash Joins on Large Tables 23ai 23ai Copyright © 2026, Oracle and/or its affiliates 434
  378. Exadata System Software の進化㉓ Exadata System Software 追加/拡張 機能 DB

    GI HW (X6 以前は ノンサポート) 25.1 Oracle Exadata X11M Support Advanced Power Management on Exadata Database Servers AI Smart Scan Enhancements Simpler Management of Additional Software Packages During Database Server Updates Automatic Tuning of ASM Rebalance Operations Improved Free Space Management in Exascale Creating an Exascale Volume Clone Directly from an Existing Volume Secure Fabric is Recommended and Enabled by Default X8M Exadata Cache Observability Enhancements Faster Software Upgrade on Cisco Network Switches Minimum Versions and Other Requirements 19.23 19.23 X7-2 Desupport of the IORM Category Plan Copyright © 2026, Oracle and/or its affiliates 435
  379. Exadata System Software の進化㉔ Exadata System Software 追加/拡張 機能 DB

    GI HW (X6 以前は ノンサポート) 25.2 Exadata Storage Server X11M Extended (XT) AI Smart Scan Enhancements 23.7 Immediate Reuse of Flash Cache for Temporary Data Improved Performance Using Partner Cache Reads Prioritize Critical Large Writes in Flash Cache Improved Data Durability with Exascale Delta Tracking Exascale Intelligent Free Space Management Exascale Volume Groups JSON Support in Exascale Shell (XSH) Stronger Security with SELinux Enabled by Default Optimized Linux OS Image Elastic Rack Configurations in OEDA Storage Server SQL Query Statistics Monitoring Minimum Versions and Other Requirements Copyright © 2026, Oracle and/or its affiliates 436
  380. Exadata System Software の進化㉕ Exadata System Software 追加/拡張 機能 DB

    GI HW (X6 以前は ノンサポート) 26.1 Copyright © 2026, Oracle and/or its affiliates 437