Oracle DBA & Developer Days 2010 行ってきました。このようなイベントには初めて参加したのですが、ブログ書くまでが勉強会です？ということで、適当につぶやいた内容を手元の資料やその他リソースとともに整理。よく分かっていないところは資料のコピペが多いですがご容赦ください。技術的な詳細については各種ニュースサイトや後日公開される資料などをご確認ください。とある Oracle Database 10gR2 RAC 管理者が 11gR2 の新機能を中心に受講した内容のまとめです。
oracletech.jp によるレポートはこちら：
- イベントレポート(2010/11/9) 「Oracle DBA & Developer Days 2010 - Day1」
- イベントレポート(2010/11/10) 「Oracle DBA & Developer Days 2010 - Day2」
Day1 S-1 Oracle Database 11g- データベースのチカラをアプリケーション開発に最大限活用するために
米オラクル Michael Hichiwa 氏基調講演。同時通訳なしで頑張ろうと無駄な努力をしましたが、やっぱりほとんど頭に入りませんでした。その内容については前述のイベントレポートや @IT の記事『Oracle DBA ＆ Developer Days 2010開幕 - 11gでこそ味わえるOracleのうまみ』に詳しくあります。デモを見ていると、やはり SQL Developer でいろいろ出来ることが分かったので、もっとみんなガシガシ使えばいいのにと思いました。次期バージョン 3.0 では Data Modeler の機能も無償で利用できるみたいですし。
Day1 ランチ
お昼はスポンサードセッションには申し込まず、ラウンジで Premium コースの弁当をいただきました。中身はこんなのでした(縦画像でスミマセン) どうやらこのラウンジは日本HPのブースも兼ねていたらしく、途中でストレージのお話が始まりましたが、XP とか EVA とか MSA とか言われてもサッパリ分からないので黙々と食べてました（＾＾ #ODDD ハッシュタグを見ていると L-2 のセッションで Coherence、Hadoop のデモが行われたみたいで、どちらも動いているのを見たことがない自分としては参加しておけば良かったなと後悔しました。（事前の講演内容からは推測できませんでした。。。）このラウンジは Premium コースだとランチ会場として利用できるみたいですが、それ以外でランチセッションを申し込まれていない方はフロアにある（参加人数に対する割合としては）数少ない椅子であまりくつろげていない様子でした。。。
Day1 B-1 実践！データ圧縮の効果的な活用テクニック
開始前 @oracletechnetjp の中の人に発見されてしまい、ご丁寧にご挨拶いただき恐縮してしまいました。今後も気ままにつぶやかせていただきます！
日本オラクル 柴田さま( @tkssbt )のセッション。以前、[Oracle Evening Seminar］徹底解説! データベース圧縮セミナー ～データ圧縮技術でインフラ構築、運用、性能の問題を解決する～ で伺った内容の OLTP 表圧縮に絞ったダイジェスト版という感じ。ディスク I/O がボトルネックとなっている環境では、積極的に Enterprise Edition のオプションである Advanced Compression Option を活用することで比較的空いている CPU リソースを無駄なく使用でき、ディスク容量も削減できるとのこと。
格納データの圧縮(データブロック単位の圧縮)を行うと、OLTP 系ではバッファキャッシュに乗るブロック数の増加→キャッシュヒット率向上→スループット向上が見込まれ、DWH 系ではバッファキャッシュに載るブロック数の増加→In-Memory Parallel Execution の適用範囲拡大によるレスポンスタイム削減が期待できるとのこと。本セッションでは触れられませんでしたが、ディスク容量が削減されるということはバックアップに要する時間も減りますし、RMAN の高速圧縮機能を用いることでさらに時間を短縮できそうです。同じ理屈で Data Guard の Redo 転送も高速化が期待できます。コンピュータリソースを無駄なく使うなら Advanced Compression Option 使いましょうと。
OLTP 表圧縮の GRID Center での検証結果説明にて、J2EE デモアプリの JPetStore について「オンラインでペットを買う、ちょっと危険なサイト」と仰っていたのが個人的にウケました。
- データベース圧縮: Oracle Advanced Compression - 概要(とは), 資料, マニュアル
- Oracle Database 11g R2 In-Memory Parallel Queryの検証報告
- 【検証資料】Oracle RAC上でのIn-Memory Parallel Executionによる効率的なリソース活用
- Oracle Advanced Compression Advisor
Day1 B-2 詳解！大規模なストレージ・クラスタを実現するACFS最新機能
日本オラクル 宮永さま( @mamiyana )のセッション。最近気になる ASM を核とした Storage GRID の適用範囲を広げる可能性を秘める ACFS について聞いてきました。ASM はソフトウェアとしてストライピング、ミラーリング、動的リバランシングなどを行い、物理構造を Oracle Database に最適化する機能。その考え方は一般的なファイル操作にも当てはまるため、ASM で管理されている領域の一部を切り出してファイルシステムとして利用するというのが ACFS(ASM Cluster File System) の概念。
次のような機能を備えているので、今まで ASM 上に配置できなかった非構造化ファイル(アプリケーション、DB の各種ログ、DB バイナリファイル、その他ファイル)も ASM 上で管理できるようになります。
- 拡張性に優れた汎用ファイルシステム
- NASプロトコル(NFS、CIFS)でアクセス可能
- マルチOSプラットフォーム(Linux、Windows、Solaris、AIX)
- 動的なボリューム管理をサポート
- スナップショット(CoW)、レプリケーションなどの付加価値を提供
他にもファイル、ディレクトリにまたがってタグを設定、タグ単位でのファイル操作を行うことができる ACFS タギングや、Database Vault の枠組みに基づいた ACL を設定できる ACFS セキュリティ、Advanced Encryption Standard(AES) をサポートしてファイル単位、ボリューム単位で行える ACFS 暗号化などの機能があります。
- Oracle Cluster File System, Cloud Edition(a.k.a. Oracle CloudFS)
The Oracle CloudFS provides unprecedented simplicity in storage management, automation in provisioning and storage consolidation for Oracle database files as well as general purpose files. Oracle CloudFS is a storage cloud infrastructure with resource pooling, network accessibility, rapid elasticity and rapid provisioning that are key requirements for cloud computing environments.
Day1 HA-2 Oracle Database 11g R2 新機能 & RAC体感ハンズオン
日本オラクル 早坂さま、伊藤さまのセッション。個人的に Day1 の注目セッション。まず席に着いたら持ち込んだ PC を有線 LAN に接続して、机上にある各々のハンズオン環境情報シートに記載されているサーバに ssh ログインできることを確認。ハンズオン環境は 3台の Oracle VM Server で構成されていて、30名の受講者それぞれに2ノード RAC 環境が用意されていました。待ってましたとばかりに MacBook Air を取り出して、電源と有線 LAN に接続。iTerm の起動と同時に GNU screen が立ち上がるようにしているので、すかさずログを有効にして、言われてもないのに各ノードに 2本ずつ ssh 接続して待機。
まずは Oracle Real Application Clusters(RAC) の概要説明。このセッションの受講者の多くは RAC を既に知っているようなのでサラっとおさらい程度。「RAC のライセンスは高い」とよく言われるそうですが、ソフトウェアの費用としては確かにそのとおりだが、ハードウェアを有効に活用（アクティブ・アクティブ型）できるし、運用管理、人件費などを含めた全体で見たときのコストと比較して考える必要があるとのこと。次に Oracle Database 11g Release 2 概要の説明。データベース統合からインフラ統合へと進化した 11gR2。それを可能にする各種技術の紹介。動的インフラに対応した接続(SCAN:Single Client Access Name)、サーバーの仮想化(サーバー・プール)、ネットワーク固有の設定を排除(GPnP:Grid Plug and Play)、全てのデータを ASM 管理(ACFSの導入)
そして 11g Release 2 新機能＆ RAC 機能体験。待ってました！
- Oracle Automatic Storage Management(ASM) 動的リバランシング
Enterprise Manager 上から候補メンバー・ディスクをディスクグループに追加してディスクを３本から４本にする。追加したディスクの使用率が他のディスクと同じようにリバランスされている様子を EM のグラフで確認。受講者が一斉に同じ操作を行うので、応答がすごーく遅くてなかなか返ってこなかったのは仕方なし。 - Oracle ASM Cluster File System(ACFS)
EM で既存のディスク・グループからボリュームを切り出して ACFS のボリューム・デバイスを作成。そのボリュームにマウントポイントを指定して ACFS を作成。作成と同時にマウントまで行われるので、片方のノードで touch したファイルが他方のノードで見えることを確認。(以下 screen ログより)
2010-11-09 16:17:31 [grid@raca-node1] /home/grid $ cd /opt/acfsmount/acfs 2010-11-09 16:19:41 [grid@raca-node1] /opt/acfsmount/acfs $ ls -l 合計 64 drwx------ 2 root root 65536 11月 9 16:16 lost+found 2010-11-09 16:19:43 [grid@raca-node1] /opt/acfsmount/acfs $ touch a.txt 2010-11-09 16:19:47 [grid@raca-node1] /opt/acfsmount/acfs $ ls -l 合計 64 -rw-r--r-- 1 grid oinstall 0 11月 9 16:19 a.txt drwx------ 2 root root 65536 11月 9 16:16 lost+found
2010-11-09 16:19:32 [grid@raca-node2] /home/grid $ ls -l /opt/acfsmount/acfs 合計 64 drwx------ 2 root root 65536 11月 9 16:16 lost+found 2010-11-09 16:19:35 [grid@raca-node2] /home/grid $ cd /opt/acfsmount/acfs 2010-11-09 16:19:38 [grid@raca-node2] /opt/acfsmount/acfs $ ls -l 合計 64 -rw-r--r-- 1 grid oinstall 0 11月 9 16:19 a.txt drwx------ 2 root root 65536 11月 9 16:16 lost+found
- サーバー・プールの属性変更
ユーザー定義サーバー・プール(srvpool1)の属性を変更し、ポリシー管理 RAC データベース(orcl)の拡張・縮退動作を確認。
2010-11-09 16:31:23 [grid@raca-node1] /opt/acfsmount/acfs $ srvctl status srvpool -a サーバー・プール名: Free アクティブ・サーバー数: 0 アクティブ・サーバー名: サーバー・プール名: Generic アクティブ・サーバー数: 0 アクティブ・サーバー名: サーバー・プール名: srvpool1 アクティブ・サーバー数: 2 アクティブ・サーバー名: raca-node1,raca-node2 NAME=raca-node1 STATE=ONLINE NAME=raca-node2 STATE=ONLINE
2010-11-09 16:31:34 [grid@raca-node1] /opt/acfsmount/acfs $ srvctl config srvpool サーバー・プール名: Free 重要度: 0、最小: 0、最大: -1 候補サーバー名: サーバー・プール名: Generic 重要度: 0、最小: 0、最大: -1 候補サーバー名: サーバー・プール名: srvpool1 重要度: 0、最小: 0、最大: 2 候補サーバー名:
2010-11-09 16:34:01 [grid@raca-node1] /opt/acfsmount/acfs $ srvctl modify srvpool -g srvpool1 -u 1 -f 2010-11-09 16:36:53 [grid@raca-node1] /opt/acfsmount/acfs $
2010-11-09 16:37:08 [grid@raca-node1] /opt/acfsmount/acfs $ srvctl config srvpool サーバー・プール名: Free 重要度: 0、最小: 0、最大: -1 候補サーバー名: サーバー・プール名: Generic 重要度: 0、最小: 0、最大: -1 候補サーバー名: サーバー・プール名: srvpool1 重要度: 0、最小: 0、最大: 1 候補サーバー名:
2010-11-09 16:37:16 [grid@raca-node1] /opt/acfsmount/acfs $ srvctl modify srvpool -g srvpool1 -u 2 -f 2010-11-09 16:39:06 [grid@raca-node1] /opt/acfsmount/acfs $
2010-11-09 16:39:15 [grid@raca-node1] /opt/acfsmount/acfs $ srvctl config srvpool サーバー・プール名: Free 重要度: 0、最小: 0、最大: -1 候補サーバー名: サーバー・プール名: Generic 重要度: 0、最小: 0、最大: -1 候補サーバー名: サーバー・プール名: srvpool1 重要度: 0、最小: 0、最大: 2 候補サーバー名:
あらためてログを見ると、資料にあるような srvctl status database していなかったことに気づきました。。。
おまけ：CRS リソースの状態を確認。(あいかわらずデフォルトの出力は見づらい。。。)
2010-11-09 16:39:27 [grid@raca-node1] /opt/acfsmount/acfs $ crs_stat -t 名前 型 タ
...<83><88> 状態 ホスト ------------------------------------------------------------ ora.DATA.dg ora....up.type ONLINE ONLINE raca-node1 ora....ER.lsnr ora....er.type ONLINE ONLINE raca-node1 ora....N1.lsnr ora....er.type ONLINE ONLINE raca-node1 ora....N2.lsnr ora....er.type ONLINE ONLINE raca-node2 ora....N3.lsnr ora....er.type ONLINE ONLINE raca-node2 ora.asm ora.asm.type ONLINE ONLINE raca-node1 ora.eons ora.eons.type ONLINE ONLINE raca-node1 ora.gsd ora.gsd.type OFFLINE OFFLINE ora....network ora....rk.type ONLINE ONLINE raca-node1 ora.oc4j ora.oc4j.type OFFLINE OFFLINE ora.ons ora.ons.type ONLINE ONLINE raca-node1 ora.orcl.db ora....se.type ONLINE ONLINE raca-node1 ora....SM1.asm application ONLINE ONLINE raca-node1 ora....E1.lsnr application ONLINE ONLINE raca-node1 ora....de1.gsd application OFFLINE OFFLINE ora....de1.ons application ONLINE ONLINE raca-node1 ora....de1.vip ora....t1.type ONLINE ONLINE raca-node1 ora....SM2.asm application ONLINE ONLINE raca-node2 ora....E2.lsnr application ONLINE ONLINE raca-node2 ora....de2.gsd application OFFLINE OFFLINE ora....de2.ons application ONLINE ONLINE raca-node2 ora....de2.vip ora....t1.type ONLINE ONLINE raca-node2 ora....ry.acfs ora....fs.type ONLINE ONLINE raca-node1 ora.scan1.vip ora....ip.type ONLINE ONLINE raca-node1 ora.scan2.vip ora....ip.type ONLINE ONLINE raca-node2 ora.scan3.vip ora....ip.type ONLINE ONLINE raca-node2 - 透過的アプリケーション・フェイルオーバー(TAF)
用意された５万件の全件検索を行うスクリプトを実行して、その最中にサーバプロセスを kill しても select しているセッションが継続されることを確認。
2010-11-09 16:43:51 [oracle@raca-node1] /opt/ractest $ sqlplus /nolog @taf SQL*Plus: Release 11.2.0.1.0 Production on 火 11月 9 16:44:07 2010 Copyright (c) 1982, 2009, Oracle. All rights reserved. "============================================" " Transparent Application Failover (TAF) " " インスタンス障害時の SELECT 文の " " フェイルオーバーの動作検証 " "============================================" '-----------------------------------------------------------------' ' この検証スクリプトでは TAF 用のサービス taf_srv を使用します。 ' ' 事前に oracle ユーザーで /opt/ractest/taf_srv.sh を実行して、 ' ' サービス taf_srv を以下の設定で作成し、開始します。 ' ' 既にサービス taf_srv が作成済みの場合は、再作成します。 ' ' ' ' - サービス名 : taf_srv ' ' - データベース名 : orcl ' ' - 構成タイプ : ポリシー管理型 (2 ノード以上) ' ' - サーバー・プール名 : srvpool1 ' ' - フェイルオーバー・タイプ : SESSION ' ' ' ' "Enter" で開始します。 ' '-----------------------------------------------------------------' サービス taf_srv を停止します PRCR-1001 : リソースora.orcl.taf_srv.svcは存在しません サービス taf_srv を削除します PRCR-1001 : リソースora.orcl.taf_srv.svcは存在しません サービス taf_srv を作成します サービス taf_srv を開始します '-----------------------------------------------------------------' ' 最初にユーザー "taf_user" を作成します。 ' ' 作成したユーザーでテーブル "taf_table" を作成し、 ' ' 5 万件のデータを insert します。 ' ' ' ' "Enter" で開始します。 ' '-----------------------------------------------------------------' SQL> conn / as sysdba 接続されました。 SQL> drop user taf_user cascade; drop user taf_user cascade * 行1でエラーが発生しました。: ORA-01918: ユーザー'TAF_USER'は存在しません SQL> grant dba to taf_user identified by taf_user; 権限付与が成功しました。 SQL> @/opt/ractest/taf_conn SQL> conn taf_user/taf_user@raca-scan.jpoac.com/taf_srv 接続されました。 SQL> @/opt/ractest/taf_user SQL> sho user ユーザーは"TAF_USER"です。 SQL> create table taf_tbl (c1 number, c2 varchar2(100)); 表が作成されました。 SQL> declare 2 i integer; 3 begin 4 for i in 1..50000 loop 5 insert into taf_tbl values (i,'TAF_'||i); 6 end loop; 7 end; 8 / PL/SQLプロシージャが正常に完了しました。 SQL> commit; コミットが完了しました。 SQL> set echo off '-----------------------------------------------------------------' ' 現在のセッション情報を確認します。 ' ' どのインスタンスに接続されているかを確認してください。 ' ' ' ' "Enter" で開始します。 ' '-----------------------------------------------------------------' ===================== * セッション情報 ① * ===================== SQL> select host_name, instance_name from v$instance; HOST_NAME INSTANCE_NAME ------------------------------ --------------- raca-node2.jpoac.com orcl_2 SQL> set echo off '-----------------------------------------------------------------' ' セッション情報から、接続されているノードを確認します。 ' ' 別のターミナルから、そのノードに oracle ユーザー または ' ' root ユーザーでログインし次のコマンドの実行準備をします。 ' ' $ pgrep -f ora_pmon_orcl ' ' $ kill -9 <上記のコマンドの結果の数値> (まだ実行しません) ' ' ' ' これから、先ほど作成したテーブルの全件検索を行います。 ' ' "SQL> select * from taf_tbl order by 1;" ' ' ' ' 検索結果が全て返る前に別ターミナルの kill コマンドを実行します。' ' $ kill -9 <上記のコマンドの結果の数値> ' ' ' ' 検索結果が一旦停止しますが、TAF の機能により、別インスタンスに ' ' 接続し、残りの検索結果が返され、SELECT 文が完了します。 ' ' ' ' "Enter" で開始します。 ' '-----------------------------------------------------------------' SQL> select * from taf_tbl order by 1; C1 C2 ---------- -------------------- 1 TAF_1 2 TAF_2 3 TAF_3ノード１で select を実行している最中にノード２で PMON を kill。
2010-11-09 16:45:20 [oracle@raca-node2] /home/oracle $ pgrep -f ora_pmon_orcl 3537 2010-11-09 16:45:25 [oracle@raca-node2] /home/oracle $ kill -9 3537
ノード１で実行している select は一時停止しますが、その後何事もなかったかのように継続されます。v$session を確認するとそのセッションの FAILED_OVER が YES になっていることが確認できます。
49995 TAF_49995 49996 TAF_49996 49997 TAF_49997 C1 C2 ---------- -------------------- 49998 TAF_49998 49999 TAF_49999 50000 TAF_50000 50000行が選択されました。 SQL> set echo off '-----------------------------------------------------------------' ' SELECT 文が完了しました!!! ' ' ' ' それでは、現在接続されているセッションを確認してみましょう。 ' ' ' ' "Enter" で開始します。 ' '-----------------------------------------------------------------' ===================== * セッション情報 ② * ===================== SQL> select host_name, instance_name from v$instance; HOST_NAME INSTANCE_NAME ------------------------------ --------------- raca-node1.jpoac.com orcl_1 SQL> set echo off ---------------------------------------------------------------------- 現在接続しているのは「 raca-node1.jpoac.com 」の「 orcl_1 」です SQL> SQL> select username, failover_type, failover_method, failed_over from v$session 2 where username=(select sys_context( 'userenv', 'session_user' ) from dual); USERNAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER ---------- --------------- --------------- --------------- TAF_USER SELECT BASIC YES SQL> set echo off '-----------------------------------------------------------------' ' 以上で TAF の検証スクリプトは終了です。 ' ' ' ' このスクリプトは何度でも実行できます。 ' ' ' ' "Enter" で終了します。 ' '-----------------------------------------------------------------' Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing optionsとの接続が切断されました。以前、ORACLE MASTER Gold の要履修コースとして受講した『Oracle Database 10g Release 2 RAC 構築と運用』で似たようなことを行ったのを思い出し、TAF の便利さを再認識。現場でも構成すればいいのにと思いつつ、TAF に頼らざるを得ない状況に陥らないことがベストだなとか思ってみたり。高可用性を実現する技術として TAF や Fast Connection Failover(FCF) は使いどころとその構成方法を押さえておきたいところ。
- 【技術資料】透過的アプリケーション・フェイルオーバー（TAF）：Oracle Database 10g
透過的アプリケーション・フェイルオーバー（TAF）では、アプリケーションの状態を保持し、障害発生時に実行していた作業を再開し、ほとんどの障害をエンド・ユーザーから完全に見えないようにします。TAF は、それを活用するアプリケーションを開発するツールを提供するだけでなく、トランザクションに影響を与える障害など、すべての障害をエンド・ユーザーから見えなくするツールも提供します。
- 【技術資料】透過的アプリケーション・フェイルオーバー（TAF）：Oracle Database 10g
- インスタンス・ケージング
11g Release 2 のリソース・マネージャの新機能。しかし時間が足りなかったので説明のみ。残念！
- 【技術資料】Oracle Database 11gR2 リソース･マネージャ新機能
CPUリソースを複数インスタンス間で割り当て制御する機能と最大使用率の制限する機能をご紹介します。
- 【技術資料】Oracle Database 11gR2 リソース･マネージャ新機能
Day1 B-5 本当は遅くない！オラクルの監査と暗号の実際
日本オラクル 西村さまのセッション。いきなり本音トーク。
- 暗号は・・・正直ベースにいうと高速になっています。特に表領域暗号化＆AES-NIなら超高速ですっ！！
- 監査は・・・正直に言うと使い方を間違うと遅くなるのは事実です。でも、正しい用法なら問題はありません。
Oracle Advanced Security は可用性と機密性を両立した Oracle データベース暗号化機能。暗号化が求められるセキュリティ要件への対応を支援。(ネットワークの暗号化、格納データの暗号化、バックアップの暗号化) ネットワークの暗号化は、Oracle Net Manager あるいは sqlnet.ora を直接編集して以下のようなパラメータを設定するだけ。
SQLNET.ENCRYPTION_SERVER = required SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
格納データの暗号化は Transparent Data Encryption(TDE) で行うことができる。その名の通り、アプリケーションからは透過的にデータの暗号化、復号を実行するため、既存のアプリケーション(SQL)を改修する必要がない。Oracle Wallet や Hardware Security Module 利用した暗号鍵管理。NIST の標準共通鍵暗号方式 AES(128/192/256bit)を利用した暗号化を実施。暗号化方式として、列暗号化、表領域暗号化の２種類があるので、許容できるセキュリティ・レベルと可用性のバランスに応じて選択する。列暗号化は暗号化列数が増えるごとに処理時間に影響する。列暗号化と比較して、表領域暗号化はバッチ処理、OLTP 処理ともに性能への影響が小さい。
さらに高速な暗号化を実現するため、Intel Xeon 5600 番台から搭載された新しい命令セット AES-NI(Advanced Encryption Standard New Instructions) を Oracle Database と組み合わせることで、暗号化／複合化処理をプロセッサー側で高速処理することができる。(暗号化 10倍高速、複合化 8倍高速) →ホワイトペーパー インテル® AES-NIを使用した企業のセキュリティー保護(PDF)
次に監査機能。ファイングレイン監査以外の必須監査(OS監査)、DBA 監査、標準監査は全てのエディションで使えます。監査対象、監査証跡出力先、取得可能な監査証跡など、要件に応じて選択します。特権ユーザ、管理者ユーザのログは基本的に全てのログを取得する必要があり、一般ユーザのログについては、アプリケーション内で使用されるものよりは、開発者・運用者が SQL*Plus や開発ツールなどから使用する自動化されていない(自由記述の SQL)の操作履歴をとる必要がある。ログの 95% 以上はアプリケーションからのログ。本当に意味のあるのは、残り 5% のアプリケーションを経由しないログ！
たまり続けるログのメンテナンスとして DBMS_AUDIT_MGMT(ログ管理パッケージ) が用意されている。タイムスタンプを使用した定期的なログの削除が可能(11gR2 からは単体で使用可能) Audit Vault と組み合わせることで、ログを Audit Vault に送信後、送信済みを削除するジョブとして使用できる。Oracle Audit Vault は DB 監査ログの収集、保全、監視、分析をシームレスに実現する統合監査ログウェアハウス。
そして最後にさりげなく Oracle Database Firewall の紹介。データベースへのアクセスを常時モニタリングし、SQL インジェクション攻撃や許可されていないアクセスをブロック。SQL 文法をベースにした分析により正確な検知を実現。IDS のように使え、ホワイトリスト、ブラックリストを SQL レベルで作成・強制。監視＆ブロッキング、監視のみなど用途に合わせた柔軟な配置が可能。GUI による分析、レポーティング機能を標準搭載。来年出荷。
- Oracle Database Firewall
Oracle Database Firewall is the first line of defense for databases, providing real-time monitoring of database activity on the network. Highly accurate SQL grammar-based technology blocks unauthorized transactions, helping prevent internal and external attacks from reaching the database.
講師の話すスピードがものすごく・・・速かったです・・・内容の理解がとても間に合いませんでした。。。
Day2 B-6 徹底解説!! Oracle RAC /Clusterware 11g R2 (R11.2.0.2)最新技術解説
日本オラクル 早坂さま、伊藤さまのセッション。個人的に Day2 の注目セッション。最初に Oracle 11g Release 2 Patch Set 1 の概要説明。これは初期リリース(11.2.0.1)からの修正を含んだ Patch Set Release(PSR)に加え、従来のパッチセットとは異なり以下の新機能が含まれる。
- 管理ツールの拡張機能
- Oracle ASM クラスタ・ファイルシステム(ACFS)拡張機能
- Real Application Testing(RAT)機能拡張
- Oracle Database QoS管理(※Oracle Exadata Database Machine X2の新機能)
適用方法も完全インストレーション(フルインストレーション)として提供されるため、PSR の新規インストール時に初期リリースが不要。PSR であっても初期リリースと同じ手順で環境構築ができるなど、より安全に PSR の適用を実施、最新の PSR 環境の構築を簡易化できる。
- 11g R1 まで：in-placeアップグレード
既存の CRS ホームへインストールされたバイナリファイルを直接入れ替えることでアップグレードを実行 - 11g R2 より：out-of-placeアップグレード
既存の CRS ホームとは別の場所に 11g Release 2 の Oracle Clusterware バイナリファイルをインストール
次に 11g R2 新機能 Oracle RAC One Node の説明と 11.2.0.2 における主な変更点の説明。
- 対応プラットフォームが拡大
従来の Linux x86/x86-64 に加え、Oracle Solaris SPARC/x86-64、HP-UX Itanium、AIX on POWER - RAC One Node データベースの構成タイプにポリシー管理が追加
- Omotionがオンライン・データベース再配置と名称変更
最大許容時間も720分に（デフォルトは30分)。実行も srvctl や EM から行える。 - サーバー管理ユーティリティ(srvctl)の機能拡張
RAC One Nodeの作成からライブマイグレーション、RACへのアップグレード等の管理も行える。 - RAC One Node データベース対応
- Database Configuration Assistant(DBCA)
- Enterprise Manager Database(EM DB) Control
つづいて Oracle Grid Infrastructure アーキテクチャ改善の５つのポイントについての説明。
- Oracle Clusterwareの起動
- 起動の起点をスクリプトベースから Oracle High Availability Services(OHAS)デーモンへ
- リソース管理に Oracle Local Registry(OLR) を導入
- リソース・モデリングの強化
- リソースタイプ／依存性の強化
- ローカル・リソース／クラスタ・リソースの概念を導入
- 秒単位のリソース監視を実現するためエージェントを導入(OHAS、CRS)
- ASM 用 SPFILE／OCR／投票ディスクの ASM管理への対応
- クラスタ構成情報を OCR から分離し、Grid Plug and Play(GPnP) プロファイルを利用
- Oracle Clusterware スタックの中で ASM を起動
- GPnP プロファイル＋ASM ディスクヘッダによる ASM SPFILE、投票ディスクの検出機能を実装
- ネットワーク機能の強化
- サブネットごとに VIP の作成が可能に
- より早期なネットワーク障害検知および自動リカバリ
- ネットワーク・リソースの導入
- 監視間隔の短縮
- VIP 自動フェイルバック
- 動的インフラへの対応
- クラスタ環境の DHCP 対応(Grid Naming Service(GNS) 環境)
- リスナーの動的エンドポイントを実装
- LOCAL_LISTENER の自動設定
- ポリシー管理への対応としてインスタンス固有設定の必要性を排除
そして Oracle Clusterware 11.2.0.2 新機能の説明。
- インターコネクトの冗長構成
- Oracle Clusterware によるインターコネクトの冗長構成が可能に
- gpicdデーモンによってネットワーク・インターフェースを監視
- OUI からインターコネクトの冗長構成が可能に
- 高可用性IP(HAIP)を使用
- プライベート NIC 障害時(インターコネクト障害)の再起動の防止
- ネットワーク帯域の増大、ロード・バランシングとしても有効
- HAIP がプライベート NIC に割り当てられた IP アドレスとは別に稼働
- インターコネクト障害時には正常稼働している NIC に HAIP が移動
- 通信が回復すると HAIP は自動で元の NIC にフェイルバック
- 特別なH/W、OSの設定は不要
- Oracle Clusterware によるインターコネクトの冗長構成が可能に
- Cluster Health Monitor
- ノード排除、ハング、RAC 環境固有の問題かどうかを診断するためのツール
- システムメトリックとデータの採取
- 深刻な障害の発生前に問題要因と成りうる要素の特定
- Grid Infrastructureに統合(11.2.0.2ではLinux、Solarisのみ)
- 関連プロセス
- System Monitor Service(osysmond.bin)
クラスタの全ノードで稼働し、1秒間隔で OS 情報を取得 - Cluster Logger Service(ologgerd)
System Monitor Service が取得した情報をリポジトリに記録。
1ノードでマスターが稼働し他1ノードでレプリカが稼働する HA 構成。
- System Monitor Service(osysmond.bin)
- 関連ファイル(CHMリポジトリ)
- デフォルトでは Grid Infrastructure ホーム配下に設置(<GRID_HOME>/crf/db/<HOSTNAME>)
- Berkeley Database(BDB) をリポジトリ DB として利用
- サイズ、配置場所の変更が可能。共有ファイルシステム上にも配置可能。
- 1ノード、1日辺りの取得データ量はおおよそ0.5GB
- 情報取得方法
- oclumon コマンド
- 11.2.0.2 CHM に対応した GUI ツールが OTN より提供予定
- ビジネス要件に応じたワークロード毎の SLA を定義可能
- 接続するサービス名、ユーザ名とセッション・パラメータで識別
- アプリケーションを変更せずに監視対象を自動で識別
- ポリシーに基づいてパフォーマンスを監視してボトルネックを特定
- パフォーマンス・クラス（サービス）に対するサービスレベル目標
- 11.2.0.2 では データベース・コールごとの平均レスポンスタイムをパフォーマンス目標として指定可能
- Performance Satisfaction Metric(PSM)によってパフォーマンス目標の適合状況を確認可能
- メモリ不足、スワップ発生による既存のワークロード、アプリケーションへの影響を避けるために、サービスを使用した新規接続を遮断(メモリーガード)
- メモリが over-commit 状態であることを検知した場合、そのノード上で稼働しているサービスを OFFLINE へ変更(メモリープレッシャーの管理)
- サーバー・プールによるサーバー・リソース管理
- ポリシー管理の RAC データベースのワークロードを監視、管理
- リソース・マネージャを内部的に使用
- Cluster Health Monitor と連携してメモリの使用状況に応じたサービスの起動管理
- ora.oc4j リソースとして Oracle Clusterware が管理
- Enterprise Manager Database Control で構成および管理
- Oracle Exadata Database Machine X2 で利用可能
Day2 ランチ
Day1 と同じく、ラウンジで Premium コースの弁当をいただきました。中身はこんなのでした(縦画像) 昨日の反省（何の？）もあってか机が全て同じ向きになっていました。2日目は HP Integrity Superdome 2 の説明。こんなハイエンドサーバを使う案件に携わることはきっとないので、またもや黙々と食べておりました（＾＾ ラウンジを出るときにコーヒーサーバがあることに気づきました。。。
Day2 B-7 詳解！Oracle DatabaseのSQLパフォーマンス管理機能
日本オラクル 小幡さま( @hobata_em ) のセッション。現場ではパフォーマンスが問題となるようなことはあまり起きていませんが、イザという時のための情報を仕入れるべく聞いてきました。
実行計画が最適ではない？そんなときに…
まずは実行計画についておさらい。
- SQL 文を実行するために必要なステップの集合
- データの取り出し方法、フィルタ条件、結合情報
- SQL 文の単体パフォーマンスを決定する重要な要素
- コストベースオプティマイザ(CBO)が種々のインプットを元にコストが小さくなるように生成
- 「コスト」は各ステップで見積もられた必要リソース(CPU、I/O)から算出
つぎに適切な統計情報のインプットに必要ないくつかの項目についての説明。
- セレクティビティ
- 各ステップで返される(条件に当てはまる)行の割合
- 索引使用の有無、結合方法など実行計画に幅広く影響
- 適切な統計情報によるセレクティビティの正確な見積もりはきわめて重要
- ヒストグラム
- 値の分布を知るための統計情報の一つ
- 高さ調整ヒストグラム
- 列データをソートし、指定したバケットの数に等分
- バケット内の最大値で複数回表れるものは頻度が高いと考えられる
- 10g 以降、自動メンテナンスタスクにより自動収集される
- ワークロードを元に取得される列を決定
- 動的サンプリング
- SQL 実行時(ハードパース時)に動的に統計情報をサンプリング(9iR2〜)
- 統計がない表があれば自動的にレベル２で動的サンプリング(10g〜)
- 複雑な述語への対応
- 例：２つの列に相関関係がある場合
- 明示的にレベル４(以上)を指定し、２列にまたがる追加統計を取得することが可能
- 拡張統計(11g〜)
- 複数列にまたがる統計や、関数が使用された列の統計
- 通常の統計同様、ディクショナリに保持され、定期的に収集される
- 参考資料（チュートリアル）列の相関および関数を使用した統計を最適化する拡張統計の使用
SQL チューニングは問題発見までの時間、情報収集の工数、チューニング方法を割り出すまでの時間、効果が出なかった場合の再検討の工数など、様々な工数と時間を伴います。SQL チューニングアドバイザを利用すると、オプティマイザによる追加分析、アドバイスなどを自動化して行うことができます。(10g〜 Enterprise Edition＋Diagnostics Pack＋Tuning Pack)
- SQL の追加分析
- 追加統計の取得、アクセスパス分析、SQL 構造分析など
- 内部的にチューニング後の SQL を実行し効果を確認
- アドバイス
- SQL プロファイルの作成
- SQL 文固有の追加統計情報
- セレクティビティの見積もりを改善し、実行計画を改善
- SQL チューニングアドバイザからのみ利用可能
- 迅速かつ柔軟に SQL チューニングが可能
- 他の SQL 文に影響を与えない
- アプリケーション(SQL)の改修の必要がない
- 索引の作成
- 失効・欠落している統計の収集
- SQL 文の再構築
- 代替実行計画の提示
- 自動並列度(DOP)の設定
- GUI からアドバイス内容の実装も可能
- SQL プロファイルの作成
- データの偏りの変化に対する自律的な対応
- 10g 以降、自動化メンテナンスタスクによりデフォルトで統計情報を自動取得
- 11g 以降、自動化メンテナンスタスクにより SQL チューニングアドバイザが実行される
- AWR からチューニング対象となる SQL を識別してアドバイザを実行
- ３倍以上パフォーマンスが向上する場合の SQL プロファイル（キー SQL プロファイル）は自動実装するようにも設定可能
- 【セミナー資料】もうアプリ改修は必要ない！これからのSQLチューニング
SQLチューニングが簡単になりました！これからは実行計画とにらめっこしたり、泣く泣くアプリケーションを書き換えたりするはありません。ぜひ、この新しいSQLチューニング方法をご利用ください！
11g ではバインドピークによる実行計画の固定化への対応も進んでいるそうです。
- バインドピーク
- ハードパース時にバインド変数内の値を"先読み"
- 変数内の値に応じて最適な実行計画を作成可能
- しかし、他の値に対しては最適でないこともある
- Adaptive Cursor Sharing (11g〜)
- バインド変数が使われた SQL の統計(buffer getsなど)を監視
- 統計に大きな変化があった場合、実行計画を再作成
- バインド変数への柔軟な対応を実現
意図しない実行計画の採用を防止したい場合、これまでは実行計画の固定か、統計情報のロックなどをしなければならなかったそうですが、11g からは SQL 計画管理(SQL Plan Management)という機能が加わり、SQL 計画ベースラインを使って実行計画を「進化」（≠固定）することができるようです。
- SQL 計画ベースライン
- 承認された実行計画(ベースライン)のみ使用可能とする
- 新たな実行計画が見つかった場合すぐには採用しない
- 検証を経て承認されると使用可能になる
- エクスポート・インポートも可能
- SQL 計画管理によるバインド変数への対応
- バインドピーク時に例外的な値が入った場合なども、予期せぬ実行計画が使用されることを防止可能
バッチが終わらない！？そんなときに…
実行計画の各ステップで何にどれぐらい時間を使っているのか知りたい、あるいはチューニングの後、どれくらい効果が出たかを詳しく確認したい、などの実行済みの SQL のパフォーマンス分析を行いたい場合は SQL トレースによる分析を行います。
- SQL トレースとは、SQL 文が実際に実行された際の統計情報の出力
- 「実行計画」の値は Oracle Database が実行前に見積もったもの
- 実行時に実際にどうなったかは SQL トレースから確認することができる
- EM あるいは DBMS_MONITOR パッケージを使用して取得
- SQL 全体、また実行ステップごとに以下の情報が取得される
- 解析、実行、フェッチの各フェーズを行った回数
- CPU 時間、経過時間
- 物理読み取り、論理読み取りでそれぞれ読み込んだブロック数
- 処理した行数
- ライブラリ・キャッシュ・ミスの回数など
- TKPROF ユーティリティーを使用して出力を整形
- 再現待ちで時間が費やされる
- SQL トレースの設定後、問題のある SQL を再現しないといけない
- 再現するまでに数時間〜数日待つことも
- 不定期に起こる問題の場合はより困難
- 分析に時間がかかりやすい
- グラフィカルではないので直観的に判断することが難しい
- パラレル実行の場合、I/O の偏りを判別するのも大変
- オーバーヘッドに注意する必要がある
- トレースファイルへの大量の I/O が発生するため
- OS 統計は別途取得する必要がある
- vmstatなど
- グラフ化する作業の手間もかかる
これらの課題に対する答えとして 11g Tuning Pack で提供される新機能「リアルタイム SQL 監視」があります。これは実行中の SQL を自動で監視して詳細な統計を取得し、EM のグラフィカルなレポート画面から分析できる機能で、以下のような特徴があります。
- GUI から簡単にボトルネックを突き止められる
- 再現待ちや特別な設定をせずすぐに分析を始められる
- レポートをエクスポートして外部で参照可能
- オーバーヘッドがほとんどない
そういえば最近、処理に時間のかかるようになったバッチの調査、対策を行いました。テスト環境で autotrace の出力とにらめっこしましたけど普段見慣れないのであまり分からず、結局 PL/SQL を追って遅そうなところを特定しました。あわせて進捗度合いを測るためにカーソル処理のループ中で DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS プロシージャを呼ぶようにして、V$SESSION_LONGOPS で外から SQL で処理件数を確認できるようにしました。けどコレがあればそんな手間のかかることをしなくても済むんですよね。。。
- 【セミナー資料】複雑なSQLチューニングもラクにする！SQL監視機能とは
「バッチが終わらない、いつ終わるのかわからない」「もっと手間をかけずにSQLチューニングしたい」、そんな悩みを解決する機能が Oracle Database にまたひとつ加わりました。本セミナーでは、グラフィカルでわかりやすい画面からSQLの詳細な性能分析ができる、Oracle Database 11g の新機能「リアルタイムSQL監視」をご紹介します。
Day2 B-8 虎の巻！Oracle Database 11g Release 2へのアップグレードの手順と秘訣を直伝
日本オラクル 田口さまのセッション。いまのところアップグレードの予定はありませんが、来るべきいつかの日に備えようと聞いてきました。セッションタイトルからは何かすごい裏技を伝授していただけるのではないかという気持ちになりますが、Oracle Database に限らずアップグレードの手順について秘訣というものはなく、適切な事前の計画と十分な検証を行うということ。
- ビジネス要件と技術的シナリオにあったアップグレード方法の選択
- システム停止によるビジネスインパクトに比例した計画・テストの実施
- 労力・リスク・コストを減らすためにアップグレード前後のフェーズで適切なツールを使用
- 切り戻し方法の準備とテスト
- 『Oracle Databaseアップグレード・ガイド 11g リリース2（11.2）』
- 『Oracle Database 11g R2 Upgrade Companion』Note:785351.1 KROWN:141177
- 8.1.7 512ページ
- 9.0.1 484ページ - 9コンポーネントの RDBMS に対して111ステップ
- 9.2.0 344ページ
- 10.1.0 170ページ
- 10.2.0 140ページ
- 11.1.0 186ページ
- 11.2.0 178ページ
- パフォーマンス統計情報の保存
- アップグレードの前後で比較
- 少なくともアップグレードの4週間前に開始
- 特定時間帯のクエリーとバッチ処理の両方で取得
- STATSPACK: アップグレード前に PERFSTAT ユーザをエクスポート(元が 8i、9i SEの場合)
- AWR: デフォルト60分ごとにスナップショットを取得して30日間保存(元が 10g、11gの場合)
アップグレード後の DB にインポートして AWR 比較を実行
- アップグレード情報スクリプト
- $ORACLE_HOME/rdbms/admin/utlu112i.sql (112i の i は Info)
- 移行元データベース(9.2.0.8、10.1.0.5、10.2.0、11.1.0)で実行する
- すべての初期化パラメータに対してチェックが実行され、古いパラメータや非推奨のパラメータに関する警告が表示される
- チェック対象
- コンポーネントとオプション
- 適切な SYSAUX 表領域サイズ
- キャラクタ・セット
- タイムゾーン・ファイルのバージョン・チェック
- クラスタのチェック
- 11g R2 のソフトウェアをインストール後に PSR、PSU、推奨個別パッチ、CPU を適用する
- アップグレード前に 11.2 のリスナーを作成する
Oracle Enterprise Manager Database Control を構成するため
- 時間に影響しない要素
- データベースのサイズ
- 使用されているデータ型
- 時間に影響する要素
- インストールされているコンポーネントとオプションの数
- 有効または失効しているディクショナリ統計
- シノニムの数（シノニムは再コンパイルされるため：9iからのアップグレード）
- XDB のオブジェクト数
- COMPATIBLE が上がるとき、わずかに影響するもの
- データ・ファイルの数
- REDO ログのサイズ
- 監査証跡 SYS.AUD$ 表の削除（必要に応じて）
SQL> truncate SYS.AUD$;
- ディクショナリ統計の作成
- Oracle 9i
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS ('SYS', options => 'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE); - Oracle 10g / 11g
SQL> exec DBMS_STATS.GATHER_DICTIONARY_STATS;
- Oracle 9i
- リサイクル・ビンの削除
SQL> purge DBA_RECYCLE_BIN;
- 無効なオブジェクトの再コンパイル
- 無効なオブジェクトのチェック
SQL> SELECT UNIQUE object_name, object_type, owner FROM dba_objects WHERE status = 'INVALID';
- sys と system ユーザー・スキーマ内の無効なオブジェクトを修正
- utlrp.sql で無効なオブジェクトを再コンパイル
- アップグレード前後で無効なオブジェクトを比較する
- 11.1.0.7 以降では、この比較は自動的に実行される
- registry$sys_inv_objs と registry$nonsys_inv_objs で無効なオブジェクトを発見する
- 前後の比較：utluiobj.sql (11gR2)
- 無効なオブジェクトのチェック
- Database Vault の無効(使用している場合)
- Database Vault を無効化にして再リンク
$ make -f ins_rdbms.mk dv_off $ dvca -action disable ...
- アップグレードを行った後に、再度有効化する
$ dvca -action enable ...
- Database Vault を無効化にして再リンク
- Oracle 11g をインストールし、PSR や PSU などを適用
- utlu112i.sql を新サーバ(11g)から旧サーバ(9i)へコピー
- utlu112i.sql を使用してデータベースを分析し、分析結果が示す要件を全て満たす
- 9i データベースをシャットダウン
- 9i 環境から 11g 環境へ関連ファイルを全てコピーする
- utlu112i.sql によって提示された変更を適用(初期化パラメータ、環境変数など)
- netca を使用して新しい 11g リスナーを作成する
- 11g 環境に切り替え、データベースを起動する(startup upgrade)
- SYSAUX 表領域を作成する(移行元が Oracle 9i の場合のみ)
- アップグレード・スクリプト catupgrd.sql を実行する
- utlrp.sql で再コンパイルし、utluiobj.sql と比較する
- 古いパラメータを削除する
init.ora / spfile から以前のパラメータや隠しパラメータ、イベントのパラメータ設定を削除する
- 固定表の統計情報を取得
- アップグレード直後に実施→再コンパイルを高速化
- 通常の運用フェーズに入ったら再取得。
SQL> execute dbms_stats.gather_fixed_objects_stats;
- 通常の運用フェーズに入ったらシステム統計情報を取得(CBO が不適切な値を使用するのを防止するため)
SQL> execute dbms_stats.gather_system_stats('start'); ... SQL> execute dbms_stats.gather_system_stats('stop');
- アップグレード後に使用するスクリプト
- $ORACLE_HOME/rdbms/admin/catuppst.sql
- 10.1 以降からアップグレード時にのみ必要
- AWR ベースライン情報のアップグレード
- ADDM タスク・メタデータのアップグレード
- $ORACLE_HOME/rdbms/admin/utlu112s.sql (112s の s は Status)
- 11g 環境内の新しいデータベースに対して実行する
- アップグレード後のコンポーネントのステータスをチェック
- アップグレードにかかったコンポーネントごとの時間と合計時間を表示
- $ORACLE_HOME/rdbms/admin/catuppst.sql
- 最新の spfile から編集可能な init.ora を作成
アップグレード時の問題の 90% 以上は実はアップグレードの問題ではなく、アップグレード後のパフォーマンスに関する問題。テスト・シナリオとテスト方法を万全なものにすることが重要。アップグレード時のテスト工数の削減として、Oracle Real Application Testing を機能テスト、パフォーマンス・テストに活用できる。
- アップグレード元の環境で実行されている処理・SQL を記録し、アップグレード後の環境で再現(Database Replay)
- データベース全体のスループット性能をテスト・分析
- クエリ単体のレスポンス性能、SQL 実行計画をテスト・分析(SQL Performance Analyzer)
- 実行計画の変更をアップグレード前に検出
- SPA レポートを使用して初期化パラメータの理想的な設定を判断
アップグレード後に問題が生じた場合の切り戻し。これはすごく大事。「そんなリストア計画で大丈夫か？」
- バックアップの取得
- バックアップのリストア
- 許容ダウンタイムにリストア時間も考慮
- アップグレード・プロセス中の複数のポイントにおいて切り戻しのテスト
- リストアは正常に機能するか
- リストア手順の確認
- リストアにかかる時間の把握
アップグレードにおける注意すべき変更点のまとめ。
- 11g の新しい初期化パラメータ（例）
- DIAGNOSTIC_DEST (11.1) デフォルト：$ORACLE_BASE
background_dump_dest、user_dump_dest、リスナー・トレースなどを置き換え、ADR(Automatic Diagnostic Repository)ホームを指定する。
<diagnostic_dest>/diag/rdbms/<dbname>/<instname> - SEC_CASE_SENSITIVE_LOGON (11.1) デフォルト：オン
パスワードの大文字・小文字の区別のオン/オフを切り替える。 - AUDIT_TRAIL のデフォルト値 (11.1) デフォルト：DB
データベース監査のオン／オフ、監査ログの出力先を指定する。9.2/10.1/10.2からのアップグレード時はそのバージョンのデフォルトである NONE が保持される。11g 新規データベースの場合は DB となり、SYS.AUD$ 内に記録される。 - DEFERRED_SEGMENT_CREATION (11.2) デフォルト：TRUE (COMPATIBLE >= 11.2.0)
ローカル管理表領域上に新たに作成された表は、行が挿入されたときに初めてセグメントを割り当てる。
- DIAGNOSTIC_DEST (11.1) デフォルト：$ORACLE_BASE
- CONNECT ロールの変更 (10.2〜)
10gR2 以降、CONNECT ロールは CREATE SESSION 権限のみ - 共有プールの計算 (10g〜)
10g 以降、shared_pool_size パラメータの計算方法が変更。
実際の共有プール = shared_pool_size - 起動オーバーヘッド(Startup overhead in Shared pool) - GROUP BY の結果(10g〜)
"Hash Group By" 集計によりハッシュ・アルゴリズムで GROUP BY 文を処理可能になったため、結果的にソートされない。GROUP BY による暗黙ソートを使用していた場合は ORDER BY を指定する必要がある。
- PL/SQL のカーソルのキャッシュ(10.2.0.4〜)
10.2.0.4 より前のリリースでは、PL/SQL カーソルは OPEN_CURSORS に基づいてキャッシュされていたが、それ以降では PL/SQL のカーソル・キャッシュを確保するために SESSION_CACHED_CURSORS を定義する。 - その他の初期化パラメータや動作変更点については『Oracle Database アップグレード・ガイド』や『Upgrade Companion』を参照
- 【技術資料】Oracle Database 11g Release 2 アップグレード・ワークショップ
オラクル・コーポレーション（米国）の開発部門のスペシャリストチームにより、2日間にわたって開催されたワークショップの資料です。アップグレード実施時の注意点から、さまざまなパターンでの手順や海外での成功事例まで、詳細に解説しています。
合計 425 ページほどのワークショップ資料が公開されています。11gR2 へのアップグレード手順、考慮点はもとより、11g、11gR2 でどのような点が変更されたのか具体的な記述がありとても参考になります。
Oracle Database に関するさまざまな技術情報に２日間みっちりと触れることができ、とてもよい刺激になりました。質疑応答などの時間やセッション間の移動時間がもう少しあれば良かったかなと思いました。自分が受講したセッションについて振り返るだけでもかなり時間がかかってしまいましたが、他に興味のあるセッションについては後日資料を確認しようと思います。講師の皆様、スタッフの皆様、お疲れ様でした。またこのような催しがあれば是非とも参加させていただきたいと思います。
|ω･`)ゞ セッションに参加できない＆意外と資料が公開されていなかったので非常に参考になりました！
返信削除