Oracle® Database

アップグレード・ガイド

11gリリース2(11.2)

B56310-08(原本部品番号:E23633-11)

2014年5月

Oracle Databaseアップグレード・ガイド, 11gリリース2(11.2)

B56310-08

Copyright © 2002, 2014, Oracle and/or its affiliates.All rights reserved.

原本著者: Cathy Shea

協力者: Toshinori Ami、Vickie Carbonneau、Ian Dai、Mike Dietrich、Joseph Errede、Ayako Ito、Masakazu Ito、Cindy Lim、Brian McCarthy、Tony Morales、Carol Palmer、Satish Panchumarthy、Ravi Pattabhi、Kathy Rich、Mark Richwine、Craig Santelman、Viv Schupmann、Janet Stern、Carol Tagliaferri、Venkateshwaran Venkataramani、Douglas Williams

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Oracle Databaseのアップグレード処理の概要

- Oracle Databaseのアップグレードに関する最新情報の入手先

- Oracle Databaseのアップグレード・ツールおよびアップグレード処理の概要

- Oracle Databaseのアップグレード処理の主な手順

- Oracle Databaseのリリース番号の概要

- 『Oracle Databaseアップグレード・ガイド』のリリース番号を参照する際の規則に関する説明

- 複数のOracleリリースの実行の概要

- 同じコンピュータ上の複数のOracleホームに存在するデータベース

- 異なるコンピュータ上の複数のOracleホームに存在するデータベース

- 以前のOracle Databaseリリースおよび現行リリースへのアップグレードの概要

- Oracle Databaseの現行リリースへのクライアントのアップグレードの概要

- Oracle Databaseリリース間の互換性および相互運用性

- Oracle Databaseの互換性の概要

- Oracle DatabaseのCOMPATIBLE初期化パラメータ

- Oracleで使用するCOMPATIBLE初期化パラメータのデフォルト値、最小値および最大値

- Oracle Databaseのダウングレードおよび互換性に関する考慮点

- Oracle DatabaseでのCOMPATIBLE初期化パラメータの動作

- Oracle Databaseの互換性レベルの確認

- Oracle DatabaseでのCOMPATIBLE初期化パラメータ設定のタイミング

- Oracle Databaseの相互運用性の概要

- Oracle DatabaseのOptimal Flexible Architecture(OFA)

- 64ビットOracle Databaseソフトウェアへのデータベースの変換

- Oracle Databaseのローリング・アップグレードの概要

- Oracle Databaseのローリング・アップグレードの実行方法の概要

- Oracle DatabaseのStandard EditionからEnterprise Editionへの移行

- リリース11.2.0.4の削除ツールに関する既知の問題

- Oracle DatabaseのEnterprise EditionからStandard Editionへの移行の概要

- Oracle Database Express EditionからOracle Databaseへのアップグレードの概要

2 Oracle Databaseのアップグレードの準備

- Oracle Databaseのアップグレードを準備するための主な手順

- アップグレードする場合のOracle Databaseの新機能の理解

- Oracle Databaseをアップグレードする場合のアップグレード・パスの決定

- Oracle Databaseをアップグレードする場合のアップグレード方法の選択

- Database Upgrade Assistant(DBUA)

- 手動アップグレード

- Oracle Data Pump Export/ImportおよびOracle Databaseのアップグレード

- Oracle Databaseをアップグレードする場合の新しいOracleホームの場所の選択

- Oracle Databaseをアップグレードするためのテスト計画の作成

- Oracle Databaseのアップグレード・テスト

- Oracle Databaseをアップグレードする場合の最小テスト

- Oracle Databaseをアップグレードする場合の機能テスト

- Oracle Databaseをアップグレードする場合の高可用性テスト

- Oracle Databaseをアップグレードする場合の統合テスト

- Oracle Databaseをアップグレードする場合のパフォーマンス・テスト

- Oracle Databaseをアップグレードする場合のボリューム/ロード・ストレス・テスト

- Oracle Databaseをアップグレードする場合のバックアップ計画の準備

- Oracle Databaseのアップグレード処理のテスト

- アップグレードしたテスト用Oracle Databaseのテスト

3 新しいリリースのOracle Databaseへのアップグレード

- Oracle Databaseをアップグレードする場合のシステムの考慮点および要件

- 新しいOracle Database環境への既存のデータ・ファイルの再配置

- デフォルトでインストールされていないPL/SQLパッケージのアップグレードの概要

- Oracle Grid InfrastructureとともにインストールされるOracle ASMのアップグレードの概要

- Oracle ClusterwareおよびOracle ASMインスタンスのアップグレードに関する考慮点

- 現在のデータベース構成にOracle ASMが含まれているかどうかの確認

- Oracle Real Application Clusters(Oracle RAC)データベースのアップグレードの概要

- Oracle RACで時間の同期を行う場合の要件の概要

- Oracle ASMを使用するOracle RACおよびデータベースのアップグレードに関する考慮点

- Oracle ASMインスタンスのシステム認証のアップグレードの概要

- Oracle ASMインスタンスのアップグレードに関する考慮点

- 読取り専用およびオフラインの表領域を使用したアップグレードの概要

- スタンバイ・データベースを使用したアップグレードの概要

- オペレーティング・システムのアップグレードの概要

- 異なるオペレーティング・システムへのデータの移行

- Oracle Streamsのダウンストリーム取得を使用しているデータベースのアップグレードの概要

- Oracle Database Vaultを使用しているデータベースのアップグレードの概要

- アップグレードする場合の新しいOracle Databaseソフトウェアのインストール

- 最新のパッチ・セット更新および必須のパッチの概要

- アップグレード前情報ツールの使用

- アップグレード前情報ツールの各種の警告

- 以前のリリースからのCONNECTロールの更新

- アクセス制御リストおよびネットワーク・ユーティリティ・パッケージの管理と更新

- 依存性の評価およびネットワーク・ユーティリティ・パッケージのACLの追加

- 以前のリリースからのダウングレードおよびデータベース・リンクについて

- TIMESTAMP WITH TIME ZONEデータ型に関する警告の概要

- オプティマイザ統計を収集するための停止時間の短縮(オプション)

- 無効なオブジェクトの識別

- emdwgrdユーティリティを使用したデータベースの制御ファイルおよびデータの保存

- マテリアライズド・ビューのリフレッシュ完了の確認

- メディア・リカバリを必要とするファイルがないことの確認

- バックアップ・モードのファイルがないことの確認

- 未処理の分散トランザクションの解決

- スタンバイ・データベースとプライマリ・データベースの同期化

- データベースのごみ箱のパージ

- Oracle9iからアップグレードする場合のリスナーの構成

- Linux、UNIXおよびWindowsでのDatabase Upgrade Assistantを使用したアップグレード

- DBUAの使用に関する考慮点

- DBUAのGraphical User Interfaceの概要

- Oracle DBUAによって実行される確認

- Oracle DBUAによって起動されるアップグレード・スクリプト

- DBUAを使用したLinux、UNIXおよびWindowsシステムでのデータベースのアップグレード

- オプションでのインプレース・アップグレードの実行(同じOracleホームへ)

- Windowsでのインプレース・アップグレード

- WindowsプラットフォームでのOracle Databaseのインプレース・アップグレードに関する考慮点

- WindowsでのOracle Databaseのインプレース・アップグレードの実行

- サイレント・モードのDBUAを使用したOracle Databaseのアップグレード

- サイレント・モード時のOracle DBUAのコマンドライン・オプション

- サイレント・モード時のDBUAのコマンドライン構文

- Oracle Databaseの手動でのアップグレード

- 手動アップグレードを行う場合のOracle Databaseのバックアップ

- 手動アップグレードを行う場合の新しいOracleホームの準備

- Oracle Databaseの手動でのアップグレード

- アップグレード後の状態ツールの概要

- Oracle Databaseのアップグレードのトラブルシューティング

- Oracle RACでのアップグレード前のOracleホームの削除

- リソース制限およびOracle Databaseのアップグレード

- 未設定のCOMPATIBLEパラメータ

- エディション・セッションの起動エラー

- ORA-01408の手動の回避策

- アップグレード後にDBMS_DSTパッケージを実行した場合にORA-01822が発生する

- コンポーネントの状態の理解

- アップグレード全体が完了する前にDBUAにより無効なコンポーネントにXマークを付けることが可能

- Oracle Databaseのアップグレードの再実行

- Oracle Databaseのアップグレードの取消し

- Oracle ASMインスタンスのアップグレードの概要

4 Oracle Databaseのアップグレード後の作業

- Oracleデータ・ディクショナリの現在の状態の表示方法

- Oracle Databaseのアップグレード後のOPatchコマンドについて

- Oracle Databaseのアップグレード後に必要な作業

- 手動アップグレード後のLinuxおよびUNIXシステム上での環境変数の設定

- Oracle Databaseのアップグレード後のoratabおよびスクリプトが新しいOracleホームを指すようにする設定

- Oracle Databaseのアップグレード後のリカバリ・カタログのアップグレード

- Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード

- Oracle Databaseのアップグレード後のDBMS_STATSパッケージで作成された統計表のアップグレード

- Oracle Databaseのアップグレード後の外部認証されたSSLユーザーのアップグレード

- Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール

- Oracle Databaseのアップグレード後のOracle Application Expressの構成の更新

- Oracle Databaseのアップグレード後の外部ネットワーク・サービスへのファイングレイン・アクセスの構成

- Oracle Databaseのアップグレード後のOracle Database Vaultの有効化およびDV_PATCH_ADMINロールの取消

- Oracle Databaseのアップグレード後の推奨作業

- すべてのデータベースのアップグレード後の推奨作業

- データベースのバックアップ

- パスワードのリセットによる大/小文字区別の強制

- Oracle Grid Infrastructureでの変更の理解

- Oracle ASMとOracle Grid Infrastructureのインストールとアップグレードの理解

- 新機能の適宜追加

- 必要な新しい管理手順の作成

- 表領域アラートのしきい値の設定

- ロールバック・セグメントから自動UNDOモードへの移行

- Oracle Data Guard Brokerの構成

- LONGデータ型からLOBデータ型への表の移行

- アップグレードした本番データベースのテスト

- Oracle Database 10gリリース1(10.1)データベースのアップグレード後の推奨作業

- チェンジ・データ・キャプチャのアップグレード

- Secure HTTPの構成

- HTTPを介したXML DBリポジトリ・データへの匿名アクセスの提供

- Oracle Express Edition Databaseのアップグレード後の推奨作業

- Oracle RACデータベースのアップグレード後の推奨作業

- 手動によるOracle Databaseのアップグレード後にのみ行う作業

- オラクル社が提供するアカウント用のパスワードの変更

- ORAPWDによるパスワード・ファイルの作成

- サーバー・パラメータ・ファイルへの初期化パラメータ・ファイルの移行

- Oracle Textのアップグレード

- Oracle Clusterware構成のアップグレード

- 新しいリリース用の初期化パラメータ・ファイルの調整

- COMPATIBLE初期化パラメータの設定

- tnsnames.oraおよびリスナー・パラメータの構成

- Enterprise Managerの構成

- Oracle RACのCLUSTER_DATABASE初期化パラメータの設定

- Oracle Grid Infrastructureのアップグレード後に必要な作業

- Grid Infrastructureのインストールでの環境変数の使用

- Oracle ASMの以前のリリースのOracle Grid Infrastructureへのアップグレード

- Oracle ASMのアップグレードの準備

- Oracle ASMのアップグレード

- Oracle ASMのアップグレード後に必要な作業

- 環境変数の設定

- 単一インスタンスのOracle ASMのアップグレード

- クラスタOracle ASMのアップグレード

- Oracle ASMのアップグレード後の追加の考慮点

- Oracle ASMのアップグレード後のロール割当て済のソフトウェアの所有者およびデータベースのアップグレード

- Oracle ASMのオペレーティング・システム・ユーザーとしての既存ユーザーの保持

- 単一インスタンスのOracle ASMのオペレーティング・システム・ユーザーの変更

- Oracle RACデータベースのオペレーティング・システム・ユーザーの変更

- Oracle ASMのアップグレード後の推奨作業

- Oracle ASMパスワードのリセットによる大/小文字区別の強制

- Oracle ASMとOracle Databaseのディスク・グループの互換性の拡張

- Oracle ASMの優先読取りの障害グループの設定

5 Oracle Databaseのアップグレード後のアプリケーションのアップグレード

- アプリケーションのアップグレードの概要

- アップグレード時のアプリケーションの互換性の問題

- プリコンパイラおよびOCIアプリケーションのアップグレード

- ソフトウェアのアップグレードおよびクライアント/サーバー構成の理解

- Oracle Databaseのソフトウェア・アップグレードのタイプ

- 使用可能なクライアント/サーバー構成

- クライアント/サーバー・ソフトウェアをアップグレードする場合のアプリケーションの互換性規則

- Oracle Databaseサーバー・ソフトウェアのアップグレード

- Oracle Databaseクライアント・ソフトウェアのアップグレード

- プリコンパイラおよびOCIアプリケーションのアップグレード選択肢

- 選択肢1: アプリケーションを変更しない

- 選択肢2: 新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする

- 選択肢3: アプリケーション・コードを変更して、新しいOracle Database 11gの機能を使用する

- SQL*PlusスクリプトおよびPL/SQLのアップグレード

- 数値リテラルの評価への変更

- Oracle FormsまたはOracle Developerアプリケーションのアップグレード

6 以前のリリースへのOracle Databaseのダウングレード

- Oracle Databaseのダウングレードがサポートされているリリース

- Oracle Databaseリリース間の非互換性の確認

- サーバー・パラメータ・ファイル(SPFILE)からのサポート対象外パラメータの削除

- ダウングレード前のOracle Databaseの全体バックアップの実行

- 以前のリリースへのOracle Databaseのダウングレード

- Oracle Databaseのダウングレード後の作業

- Oracle Databaseリリース10.2または11.1にダウングレードする際のネットワーク・リスナーの再作成

- Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア

- Oracle Databaseのダウングレード後のOracle Database Vaultの再有効化

- ダウングレード後のOracle Clusterware構成のリストア

- 以前のリリースからのダウングレードおよびデータベース・リンク

- Oracle Databaseのダウングレードのトラブルシューティング

7 Oracle Data Pumpを使用したデータの移動

- Oracle Databaseのアップグレードに使用するデータ・ポンプ・エクスポートおよびインポートの概要

- オリジナルのEXPおよびIMPユーティリティを使用するタイミング

- Oracle Databaseをアップグレードする場合のエクスポート/インポートの要件

- エクスポート・ダンプ・ファイルおよびアップグレードの概要

- ダウングレードに必要なエクスポートおよびインポートの要件

- 以前のリリースと互換性がないデータでのエクスポート/インポートの使用方法

- データ・ポンプ・エクスポート/インポートを使用したデータベースのアップグレード

- ネットワーク・リンクを使用したデータベース全体のインポート

A Oracle Databaseのアップグレード後の動作の変更点

- Oracle Database 11gリリース2(11.2)で発生する互換性および相互運用性の問題

- Oracle Enterprise Manager Database Controlの非推奨

- Oracle Netリスナーで非推奨のSNMPサポート

- PL/SQLプロシージャの変更点

- JOB_QUEUE_PROCESSESパラメータおよびジョブのスケジューリング

- 非推奨のXML DB構造体

- Oracle DatabaseでのCursor_sharing=similarの廃止

- チェンジ・データ・キャプチャの計画されているサポート終了

- Oracle Database 11gリリース2(11.2)で非推奨の初期化パラメータ

- Oracle Database 11gリリース2(11.2)で廃止された初期化パラメータ

- Oracle Database 11gリリース2(11.2)で非推奨の静的データ・ディクショナリ・ビュー

- Oracle Database 11gリリース2(11.2)で非推奨の動的パフォーマンス・ビュー

- Oracle Database 11gリリース2(11.2)で非推奨となった機能

- LOG_ARCHIVE_DEST_nパラメータの変更

- QOSCTLサービスのクオリティ(QoS)コマンドの-checkpasswdの非推奨

- 削除ツールの-cleanupOBaseフラグのサポート終了

- DES、RC4およびMD5アルゴリズムのサポート終了

- Oracle Database 11gリリース1(11.1)で発生する互換性および相互運用性の問題

- Oracle Database 11gリリース1(11.1)で非推奨の初期化パラメータ

- Oracle Database 11gリリース1(11.1)で廃止された初期化パラメータ

- Oracle Database 11gリリース1(11.1)で列が削除された静的データ・ディクショナリ・ビュー

- Oracle Database 11gリリース1(11.1)で非推奨となった機能

- 自動メンテナンス・タスク管理

- ASM管理用の新しいSYSASM権限およびOSASMグループ

- ASMディスク・グループの互換性

- COMPUTE STATISTICS句とESTIMATE STATISTICS句

- Oracle Data MiningモデルおよびDMSYSスキーマ・オブジェクト

- Oracle Data Miningスコアリング・エンジン

- SQL計画管理とSQL計画ベースラインの制御

- Oracle XML DatabaseでのバイナリのXMLのサポート

- Oracle Database 11gリリース1(11.1)へのアップグレード時

- PL/SQLのネイティブ・コンパイルとネットワーク・ユーティリティ・パッケージのアクセス制御

- PL/SQLネイティブ・コンパイル

- ネットワーク・ユーティリティ・パッケージのアクセス制御

- PL/SQLの制御パラメータ

- Oracle XML DBにおけるWebDAV ACL評価ルールの変更

- サマリー管理とSQLアクセス・アドバイザ

- SQLアクセス・アドバイザのタスク

- Standard Editionの初期データベース

- コア・ダンプの位置

- UNDO_MANAGEMENTの新規デフォルト値

- LOG_ARCHIVE_DEST_nパラメータ

- SHARED_POOL_SIZEパラメータ

- JOB_QUEUE_PROCESSESパラメータの新しいデフォルト設定

- 自動診断リポジトリ

- Oracle Database 10gリリース2(10.2)で発生する互換性および相互運用性の問題

- Oracle Database 10gリリース2(10.2)で非推奨の初期化パラメータ

- Oracle Database 10gリリース2(10.2)で廃止された初期化パラメータ

- Oracle Database 10gリリース2(10.2)で列が削除された静的データ・ディクショナリ・ビュー

- SQL

- CONNECTロール

- タイムゾーン・ファイル

- FAILED_LOGIN_ATTEMPTSに対する新しい制限

- Oracle Database 10gリリース1(10.1)で発生する互換性および相互運用性の問題

- Oracle Database 10gリリース1(10.1)で非推奨の初期化パラメータ

- Oracle Database 10gリリース1(10.1)で廃止された初期化パラメータ

- Oracle Database 10gリリース1(10.1)で非推奨の静的データ・ディクショナリ・ビュー

- Oracle Database 10gリリース1(10.1)で廃止された静的データ・ディクショナリ・ビュー

- Oracle Database 10gリリース1(10.1)で非推奨の動的パフォーマンス・ビュー

- Oracle Database 10gリリース1(10.1)で廃止された動的パフォーマンス・ビュー

- SQLオプティマイザ

- サポートされないルールベース・オプティマイザ

- オプティマイザ統計

- CREATE INDEXのCOMPUTE STATISTICS句

- SKIP_UNUSABLE_INDEXES

- SQLの変更

- アップグレード後の無効なシノニム

- 管理性

- トランザクションおよび領域

- リカバリおよびData Guard

- RMAN

- CREATE DATABASE

- Real Application Clusters

- マテリアライズド・ビュー

- チェンジ・データ・キャプチャ

- リモートのアーカイブ先に対するデフォルトのアーカイブ処理の変更

- NCHARデータ型の制限事項

- PL/SQLネイティブ・コンパイル

- 数値リテラルの評価

- SESSION_CACHED_CURSORSの動作変更

- DB_BLOCK_SIZEの新規デフォルト値

- OPTIMIZER_MAX_PERMUTATIONSおよびOPTIMIZER_FEATURES_ENABLE

- LOG_ARCHIVE_FORMATの動作変更

- PGA_AGGREGATE_TARGETの新規デフォルト値

- SHARED_POOL_SIZEの動作変更

- 共有サーバーのパラメータ

- DISPATCHERSの新規デフォルト値

- SHARED_SERVERSの新規デフォルト値

- MAX_SHARED_SERVERSの新規デフォルト値

- SHARED_SERVER_SESSIONSの新規デフォルト値

- CIRCUITSの新規デフォルト値

- MAX_DISPATCHERSの新規デフォルト値

B Oracle Databaseをアップグレードする場合のオプティマイザ統計の収集

- システム・コンポーネント・スキーマに対する統計の収集

- 統計表の作成

索引

はじめに

このマニュアルでは、Oracle Databaseのアップグレードの計画と実行の手引きを示します。また、このマニュアルでは互換性、アプリケーションのアップグレード、および初期化パラメータの変更やデータ・ディクショナリの変更などの新しいOracle Databaseリリースにおける重要な変更について説明します。

また、『Oracle Databaseアップグレード・ガイド』では、Oracle Database(Standard Editionともいう)およびOracle Database Enterprise Edition製品の様々な機能についても説明します。Oracle DatabaseおよびOracle Database Enterprise Editionには、同等の基本機能があります。ただし、いくつかの拡張機能はEnterprise Editionでのみ使用でき、その一部はオプションです。たとえば、アプリケーション・フェイルオーバーを使用するには、Oracle Real Application Clustersを備えたEnterprise Editionが必要です。

関連項目:
Oracle DatabaseとOracle Database Enterprise Editionの違い、および利用できる機能やオプションの詳細は、『Oracle Database新機能ガイド』を参照してください。

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Databaseアップグレード・ガイド』は、Oracle Databaseのアップグレードの計画および実行を担当する、データベース管理者(DBA)、アプリケーション開発者、セキュリティ管理者、システム・オペレータを対象としています。

このマニュアルを使用するには、次の内容について詳しく理解しておく必要があります。

- リレーショナル・データベースの概要

- ご使用のリリースのOracle Database

- ご使用のオペレーティング・システム環境

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- My Oracle Support(https://support.oracle.com)のNote ID 785351.1「Oracle Upgrade Companion」

- このマニュアルで使用される概念および用語の詳細は、『Oracle Database概要』を参照してください。

- Oracle Databaseの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle DatabaseのSQLコマンドおよびファンクションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Databaseにバンドルされるユーティリティ(データ・ポンプ、エクスポート、インポートおよびSQL*Loader)の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- Oracle Net Servicesの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

- Oracle Label Securityの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

- Oracle操作のベスト・プラクティスおよび停止時間を短縮するアップグレード方法の選択の詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

このガイドでは、サンプル・スキーマを例として多用していますが、これらのサンプル・スキーマは、Oracle Databaseのインストール時に「基本インストール」オプションを選択した場合に、デフォルトでインストールされています。これらのスキーマの作成方法およびその使用方法の詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Oracle Databaseのアップグレード処理の概要

Oracleでは、ご使用のデータベース環境に応じたアップグレード・オプションおよびOracle Databaseのアップグレード処理を自動化するツールが提供されます。

この章の内容は次のとおりです。

- Oracle Databaseのアップグレードに関する最新情報の入手先

- Oracle Databaseのアップグレード・ツールおよびアップグレード処理の概要

- Oracle Databaseのリリース番号の概要

- Oracle Databaseリリース間の互換性および相互運用性

- Oracle DatabaseのOptimal Flexible Architecture(OFA)

- 64ビットOracle Databaseソフトウェアへのデータベースの変換

- Oracle Databaseのローリング・アップグレードの概要

- Oracle DatabaseのStandard EditionからEnterprise Editionへの移行

- Oracle DatabaseのEnterprise EditionからStandard Editionへの移行の概要

- Oracle Database Express EditionからOracle Databaseへのアップグレードの概要

Oracle Databaseのアップグレードに関する最新情報の入手先

アップグレード前後の処理、互換性および相互運用性の最新情報、ディスカッション、ベスト・プラクティスについては、My Oracle Support Webサイト(https://support.oracle.com)を参照してください。Note IDまたは「データベース・アップグレード」などのキーワードで検索できます。

- パッチ・セットに関するすべてのナレッジ・ベースおよび最新情報については、My Oracle Support(https://support.oracle.com)にアクセスして、検索基準を入力してください。

- Oracle Database 11gリリース2へのアップグレードについては、My Oracle Support(https://support.oracle.com)のID 785351.1「Oracle Upgrade Companion」を参照してください。以前のリリースへのアップグレードに関するその他のUpgrade Companionも利用できます。

- アップグレード前情報ツールのダウンロードと実行については、My Oracle Support(https://support.oracle.com)のID 884522.1「Oracle Database Pre-Upgrade Utility」を参照してください。

Oracle Databaseのアップグレード・ツールおよびアップグレード処理の概要

これらのアップグレード手順によって、関連アプリケーションを含む既存のOracle Databaseシステムが、Oracle Database 11gリリース2(11.2)システムに変換されます。アップグレード手順はすべてのオペレーティング・システムに適用されますが、例外として一部のオペレーティング・システム固有の詳細項目があります。それについては、オペレーティング・システム固有のOracleマニュアルを参照してください。

Oracle Database 11gリリース2(11.2)は、新しいリリースにデータベースをアップグレードするための次のツールおよび方法をサポートしています。

- Database Upgrade Assistant(DBUA)
Graphical User Interfaceによる指示に従ってデータベースをアップグレードできます。DBUAは、インストール中にOracle Universal Installerから起動することもできますが、後からいつでもスタンドアロン・ツールとして起動することができます。

注意:
メジャー・リリースのアップグレードまたはパッチ・リリースのアップグレードには、DBUAを使用する方法が推奨されています。

- SQLスクリプトおよびユーティリティを使用した手動アップグレード
SQLスクリプトとユーティリティを使用して、アップグレードをコマンドラインで実行できます。

- エクスポート/インポート・ユーティリティ
Oracle Data PumpユーティリティまたはOracle Database内の固有のエクスポートおよびインポート機能を使用します。これらのユーティリティでは、データベースの全体または一部をエクスポートし、それを新しいOracle Database 11gにインポートします。エクスポート/インポートは、データベースを変更することなく、データベース内のデータのサブセットをコピーすることができます。

- CREATE TABLE AS SQL文
データベースから新しいOracle Database 11gデータベースにデータをコピーします。データのコピーによって、データベースを変更することなく、データのサブセットをコピーできます。

関連項目:
アップグレード・ツールおよびアップグレード方法の詳細は、「Oracle Databaseをアップグレードする場合のアップグレード方法の選択」を参照してください。

Oracle Databaseのアップグレード処理の主な手順

既存のOracle Databaseを新しいOracle Database 11gリリースにアップグレードする手順の詳細は、『Oracle Databaseアップグレード・ガイド』の該当する章を参照してください。

次の手順に、アップグレード処理で実行する主な手順の概要を示します。

- 手順1: アップグレードの準備

- 手順2: アップグレード処理のテスト

- 手順3: アップグレードしたテスト・データベースのテスト

- 手順4: 本番データベースの準備および保存

- 手順5: 本番データベースのアップグレード

- 手順6: 新しい本番データベースのチューニングおよび調整

手順1: アップグレードの準備

- 新しいOracle Database 11gリリースの機能を理解します。

- 新しいリリースへのアップグレード・パスを決定します。

- アップグレード方法を選択します。

- 新しいリリースのOracleホーム・ディレクトリを選択します。

- テスト計画を作成します。

- バックアップ計画を準備します。

注意:
アップグレード中、新しいリリースをテストしている間、既存のリリースを本番環境として使用するために複数のリリースのデータベース・ソフトウェアを実行することを検討してください。「複数のOracleリリースの実行の概要」を参照してください。

手順2: アップグレード処理のテスト

- テスト・データベースを使用して、アップグレードのテストを実行します。アップグレードのテストは、テスト用に作成した環境で行う必要があり、実際の本番データベースに影響しないようにします。

手順3: アップグレードしたテスト・データベースのテスト

- テスト・データベースおよび新しいOracle Database 11gリリースにアップグレードされたテスト・データベースに対して、手順1で計画したテストを実行します。

- 結果を比較して、テスト・データベースに対するテスト結果と、アップグレードされたデータベースに対するテスト結果の相違点を記録します。

- 発見した相違点を解決する方法を調べて、その解決方法を実装します。

- アップグレードのテストが問題なく完了し、必要なアプリケーションで正常に動作するまで、必要に応じて手順1、手順2、および手順3の最初の部分を繰り返します。

第2章「Oracle Databaseのアップグレードの準備」では、手順1から3までを詳しく説明します。

手順4: 本番データベースの準備および保存

- 新しいOracle Database 11gリリースへのアップグレードが正しく行われるように、現行の本番データベースを準備します。

- 本番データベースのバックアップ処理とアップグレード処理に必要な停止時間をスケジューリングします。

- 現行の本番データベースのバックアップを作成します。データベースのデータが失われないように、必要に応じて、全体または増分バックアップを作成します。

手順5: 本番データベースのアップグレード

- 新しいOracle Database 11gリリースへ本番データベースをアップグレードします。

- アップグレードの後、本番データベースの全体バックアップおよびその他のアップグレード後の処理を行います。

第3章「新しいリリースのOracle Databaseへのアップグレード」では、手順4および手順5でのDBUAの使用方法または手動アップグレードの実行方法について説明します。第4章「Oracle Databaseのアップグレード後の作業」では、アップグレード後の手順5のバックアップ手順および手順6のその他のアップグレード後の処理について説明します。

手順6: 新しい本番データベースのチューニングおよび調整

- 新しいOracle Database 11gの本番データベースをチューニングします。新しい本番データベースのパフォーマンスは、アップグレード前のデータベースと同等以上にする必要があります。
第4章「Oracle Databaseのアップグレード後の作業」では、これらの調整について説明します。

- 新しいOracle Database 11gリリースのどの機能を使用するかを決定し、それに応じてアプリケーションを更新します。

- 必要に応じて、新しいデータベース管理の手順を作成します。

- すべてのアプリケーションがテストされ、適切に動作するまでは、本番ユーザーを新しいリリースにアップグレードしないでください。
第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」では、アプリケーションを更新する際の考慮点について説明します。

図1-1は、アップグレード処理の主な手順を示しています。

図1-1 アップグレード手順

Oracle Databaseのリリース番号の概要

『Oracle Databaseアップグレード・ガイド』では、Oracle Databaseの異なるリリース間での移行について説明します。Oracle9iリリース2(9.2)以上では、リリース番号の2番目の数字が変更されて、Oracle Databaseのメンテナンス・リリースが示されます。以前のリリースでは、3番目の数字がメンテナンス・リリースを表していました。

図1-2に、リリース番号の各部分とその意味を示します。

図1-2 Oracleのリリース番号の例

リリース番号の詳細は、次の項で説明します。

- 『Oracle Databaseアップグレード・ガイド』のリリース番号を参照する際の規則に関する説明

- 複数のOracleリリースの実行の概要

関連項目:
Oracleのリリース番号の詳細は、『Oracle Database管理者ガイド』を参照してください。

『Oracle Databaseアップグレード・ガイド』のリリース番号を参照する際の規則に関する説明

『Oracle Databaseアップグレード・ガイド』にデータベースのメジャー・リリース番号に関する説明が記載されている場合、その説明は、そのデータベースのメジャー・リリースに含まれるすべてのリリースに適用されます。Oracle Database 11gに関する説明は、Oracle Database 11gリリース1(11.1)およびOracle Database 11gリリース2(11.2)に適用されます。Oracle Database 10gに関する説明は、Oracle Database 10gリリース1(10.1)およびOracle Database 10gリリース2(10.2)に適用され、Oracle9iに関する説明は、Oracle9iリリース1(9.0.1)およびOracle9iリリース2(9.2)などに適用されます。

同様に、『Oracle Databaseアップグレード・ガイド』にメンテナンス・リリースに関する説明が記載されている場合、その説明は、そのメンテナンス・リリースに含まれるすべてのコンポーネント固有のリリースおよびプラットフォーム固有のリリース(パッチ・セット・リリースとも呼ばれる)に適用されます。したがって、Oracle Database 11gリリース2(11.2)に関する説明は、リリース11.2.0.1、リリース11.2.0.2、リリース11.2.0.3およびOracle Database 11gリリース2(11.2)に含まれるその他すべてのプラットフォーム固有のリリースに適用されます。

複数のOracleリリースの実行の概要

同一のコンピュータ上で異なるリリースのOracle Databaseを同時に実行できます。ただし、複数のリリースを同時に使用する場合は次の条件を考慮する必要があります。

- Oracle Databaseは、以前のリリースとは別の新しいOracleホームにインストールする必要があります。
1つのOracleホームに複数のリリースをインストールすることはできません。複数のOracleホームを作成する場合、OFAを採用することをお薦めします。

関連項目:
「Oracle DatabaseのOptimal Flexible Architecture(OFA)」

- それぞれのデータベース・サーバーは、そのリリース番号に対応するデータベースにのみアクセスできます。
たとえば、Oracle9iおよびOracle Database 11gを同一のコンピュータにインストールしている場合は、Oracle9iのデータベース・サーバーはOracle9iデータベースにはアクセスできますが、Oracle Database 11gのデータベースにはアクセスできません。また、Oracle Database 11gのデータベース・サーバーはOracle Database 11gのデータベースにはアクセスできますが、Oracle9iデータベースにはアクセスできません。

関連項目:
ご使用のオペレーティング・システムで複数のリリースのOracle Databaseを実行する方法および適用される可能性のある制限の詳細は、各オペレーティング・システム固有のOracleマニュアルを参照してください。

次の項では、複数のリリースのOracle Databaseを実行する際の概要を説明します。

- 同じコンピュータ上の複数のOracleホームに存在するデータベース

- 異なるコンピュータ上の複数のOracleホームに存在するデータベース

- 以前のOracle Databaseリリースおよび現行リリースへのアップグレードの概要

- Oracle Databaseの現行リリースへのクライアントのアップグレードの概要

同じコンピュータ上の複数のOracleホームに存在するデータベース

同じコンピュータ・システムに以前のリリースのOracle Databaseをインストールして、それらのデータベースにクライアントから接続できない場合があります。たとえば、同じコンピュータ上の複数の(異なる)OracleホームにOracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gデータベースをインストールし、Oracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gクライアントから、いずれかまたはすべてのデータベースに接続することはできません。1つのシステム上にいくつかのリリースの組合せを配置できる場合があります。ただし、必ず互換性とサポートされている構成に関する最新情報を参照してください。

関連項目:
My Oracle Support(https://support.oracle.com)のNote 207303.1「Client / Server / Interoperability Support Between Different Oracle Versions」

異なるコンピュータ上の複数のOracleホームに存在するデータベース

異なるコンピュータ上の複数の(異なる)OracleホームにOracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gデータベースをインストールし、Oracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gクライアントから、いずれかまたはすべてのデータベースに接続できます。

以前のOracle Databaseリリースおよび現行リリースへのアップグレードの概要

Oracle8i、Oracle9i、Oracle Database 10gまたはOracle Database 11gのデータベースを、新しいOracle Database 11gリリースにアップグレードして、Oracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gクライアントから、アップグレードされたデータベースに接続できます。必ず互換性とサポートされている構成に関する最新情報を参照してください。

Oracle Databaseの現行リリースへのクライアントのアップグレードの概要

Oracle8i、Oracle9i、Oracle Database 10gまたはOracle Database 11gのクライアントのいずれかまたはすべてを、新しいOracle Database 11gリリースにアップグレードできます。新しいOracle Database 11gリリースのクライアントから、Oracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gのデータベースにアクセスできます。

Oracle Databaseリリース間の互換性および相互運用性

Oracle Databaseリリース間の相違点が原因で、互換性の問題や相互運用性の問題が発生する可能性があります。これらの違いは、一般的なデータベース管理および既存のアプリケーションに影響する可能性があります。

次の項で、互換性および相互運用性について説明します。

- Oracle Databaseの互換性の概要

- Oracle Databaseの相互運用性の概要

関連項目:
特定のリリースの互換性および相互運用性の詳細は、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

Oracle Databaseの互換性の概要

異なるリリースのOracle Databaseソフトウェアで同じ機能がサポートされており、その機能が同様に動作する場合は、リリースが異なってもデータベースには互換性があります。新しいリリースのOracle Databaseへアップグレードする場合、一部の新機能が原因で以前のリリースとの互換性が失われることがあります。

アップグレードしたデータベースで以前のリリースとの互換性が失われるのは、次の場合です。

- 新機能によってディスクに格納されるデータ(データ・ディクショナリの変更を含む)が、以前のリリースでは処理できない場合。

- 既存の機能の動作が、以前の環境と新しい環境とで異なる場合。

次の項目には、互換性の詳細が記載されています。

- Oracle DatabaseのCOMPATIBLE初期化パラメータ

- Oracleで使用するCOMPATIBLE初期化パラメータのデフォルト値、最小値および最大値

- Oracle Databaseのダウングレードおよび互換性に関する考慮点

- Oracle DatabaseでのCOMPATIBLE初期化パラメータの動作

- Oracle Databaseの互換性レベルの確認

- Oracle DatabaseでのCOMPATIBLE初期化パラメータ設定のタイミング

Oracle DatabaseのCOMPATIBLE初期化パラメータ

Oracle Databaseでは、COMPATIBLE初期化パラメータを使用して、データベースの互換性を制御できます。COMPATIBLE初期化パラメータがパラメータ・ファイルに設定されていない場合、Oracle Database 11gリリース2(11.2)では11.2.0がデフォルトで設定されます。アップグレードしたデータベースの互換性を失わせる可能性のあるOracle Database 11gリリース2(11.2)の新機能は、COMPATIBLE初期化パラメータをこの値に設定しないかぎり使用できません。

注意:

- Oracle Database 11gリリース2(11.2)にアップグレードする前に、COMPATIBLE初期化パラメータを10.0.0(Oracle Database 11gリリース2(11.2)で設定可能な最小値)以上に設定する必要があります。

- COMPATIBLEパラメータの設定値は、アップグレードしたデータベースの完全なテストを実行した後に大きくすることをお薦めします。

関連項目:
初期化パラメータの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracleで使用するCOMPATIBLE初期化パラメータのデフォルト値、最小値および最大値

表1-1に、Oracle Database 11gリリース2(11.2)、およびOracle Database 11gリリース2(11.2)へのアップグレードがサポートされている各リリースのCOMPATIBLE初期化パラメータのデフォルト値、最小値、最大値を示します。

表1-1 COMPATIBLE初期化パラメータ

Oracle Databaseのリリース

デフォルト値

最小値

最大値

Oracle9iリリース2(9.2)

8.1.0

8.1.0.0.0

9.2.0.n.n

Oracle Database 10gリリース1(10.1)

10.0.0

9.2.0.0.0

10.1.0.n.n

Oracle Database 10gリリース2(10.2)

10.2.0

9.2.0.0.0

10.2.0.n.n

Oracle Database 11gリリース1(11.1)

11.0.0

10.0.0.0.0

11.1.0.n.n

Oracle Database 11gリリース2(11.2)

11.2.0

10.0.0.0.0

11.2.0.n.n

Oracle Databaseのダウングレードおよび互換性に関する考慮点

Oracle Database 11gリリース2(11.2)にアップグレードする前に、COMPATIBLE初期化パラメータを10.0.0以上に設定する必要があります。COMPATIBLE初期化パラメータがこの値に設定されている間は、Oracle Database 11gリリース2(11.2)のサブセットの機能のみが使用できます。

Oracle Database 11gリリース2(11.2)にアップグレードしたら、COMPATIBLE初期化パラメータを新しいリリースのリリース番号と一致するように設定できます。このように設定すると、新しいリリースのすべての機能を使用できますが、以前のリリースにダウングレードすることはできません。

アップグレード後にダウングレードする場合は、アップグレード後も、COMPATIBLE初期化パラメータを次のように設定する必要があります。

- Oracle Database 10gリリース1(10.1)からアップグレードした場合は設定を10.1.0に維持

- Oracle Database 10gリリース2(10.2)からアップグレードした場合は10.2.0または10.1.0に設定

- Oracle Database 11gリリース1(11.1)からアップグレードした場合は11.1.0、10.2.0または10.1.0に設定

重要:
COMPATIBLEパラメータを増やした後、データベースを互換性のために設定されたリリースより前のリリースにダウングレードすることはできません。

関連項目:
ダウングレードの詳細は、第6章「以前のリリースへのOracle Databaseのダウングレード」を参照してください。

Oracle DatabaseでのCOMPATIBLE初期化パラメータの動作

COMPATIBLE初期化パラメータは、次のように動作します。

- データベースの動作を制御します。たとえば、COMPATIBLE初期化パラメータを10.1.0に設定してOracle Database 11gリリース2(11.2)のデータベースを実行すると、Oracle Database 10gリリース1(10.1)と互換性のあるデータベース構造がディスクに生成されます。つまり、COMPATIBLE初期化パラメータの設定によって、新機能を有効または無効にできます。データベースの互換性を損なう新機能をCOMPATIBLE初期化パラメータの操作によって使用しようとすると、エラーが表示されます。ただし、互換性を損なう変更をディスクに行わない新機能はすべて使用できます。

- これが、そのデータベースのCOMPATIBLEの設定と互換性があることを確認します。データベースがその設定と互換性がない場合、データベースは起動せず、エラーを戻して終了します。この場合、COMPATIBLE初期化パラメータを、データベースに対する適切な値に設定する必要があります。

関連項目:
データベース構造の詳細は、『Oracle Database概要』を参照してください。

Oracle Databaseの互換性レベルの確認

データベースの互換性レベルは、COMPATIBLE初期化パラメータの値に対応します。たとえば、COMPATIBLE初期化パラメータを11.2.0に設定すると、データベースはリリース11.2.0の互換性レベルで実行されます。

COMPATIBLE初期化パラメータの現在の値を確認するには、次の手順を実行します。

- 次のSQL文を入力します。

SQL> SELECT name, value FROM v$parameter
WHERE name = 'compatible';

Oracle DatabaseでのCOMPATIBLE初期化パラメータ設定のタイミング

COMPATIBLEパラメータは、アップグレードしたデータベースの完全なテストを実行した後でのみ増やすことをお薦めします。アップグレードが完了したら、COMPATIBLE初期化パラメータの設定を新しいOracle Database 11gリリースの最大レベルまで増加できます。ただし、COMPATIBLEパラメータを増やすと、後でデータベースをダウングレードできません。

Oracle Databaseの相互運用性の概要

Oracle Databaseにおける相互運用性とは、異なるリリースのOracle Database間での通信および連動が分散環境において可能である状態を指します。分散データベース・システムには異なるリリースのOracle Databaseを配置することができ、サポート対象すべてのリリースのOracle Databaseを分散データベース・システムに参加させることができます。ただし、分散データベースと連動するアプリケーションでは、システム内の各ノードで使用できる機能やファンクションとも相互運用できる必要があります。

新しいOracle Database 11gリリースの最小要件によって一部またはすべてのホストのオペレーティング・システムをアップグレードする必要がある場合があるため、特にローリング・アップグレード時には、異なるオペレーティング・システムおよびオペレーティング・システム・バージョン間での相互運用性が問題となる可能性があります。そのため、ローリング・アップグレード中のシステムのすべての中間的な状態において、ドライバ、ネットワークおよびストレージ間の互換性を確認する必要があります。

注意:
『Oracle Databaseアップグレード・ガイド』では、異なるリリースのOracle Database間で実行されるアップグレードおよびダウングレードについて説明しているため、相互運用性の定義はOracle Databaseリリース用です。他のOracleのマニュアルでは、さらに幅広い定義で相互運用性という言葉を使用している場合があります。たとえば、異なるハードウェア・プラットフォームおよびオペレーティング・システム間の通信を相互運用性という場合があります。

関連項目:
My Oracle Support(https://support.oracle.com)のNote ID 207303.1「Client / Server / Interoperability Support Between Different Oracle Versions」

Oracle DatabaseのOptimal Flexible Architecture(OFA)

Oracle Databaseのインストールには、Optimal Flexible Architecture(OFA)規格をお薦めします。OFA規格とは、効率的で信頼性のあるOracle Database用の構成ガイドラインであり、メンテナンスが簡素化されます。

OFAには、次のメリットがあります。

- ディスク上の大量の複雑なソフトウェアおよびデータを、デバイスのボトルネックまたはパフォーマンスの低下を避けながら構成する。

- ソフトウェアやデータのバックアップ機能など、データ破損の危険性のある日常業務を簡単にする。

- 複数のOracle Database間での切替えを軽減する。

- データベースの成長を処理および管理できる。

- データ・ディクショナリにおける空き領域の断片化を排除し、その他の断片化を特定し、リソース競合を最小限に抑える。

現在、OFA規格を使用していない場合、OFA規格への切替えには、ディレクトリ構造の修正とデータベース・ファイルの再配置が伴います。

関連項目:

- OFAの詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

- ディレクトリ構造の変更およびデータベース・ファイルの再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。

64ビットOracle Databaseソフトウェアへのデータベースの変換

以前は32ビットOracle Databaseをインストールしていた環境に64ビットOracle Database 11gソフトウェアをインストールすると、新しいOracle Database 11gリリースへのパッチ・リリースまたはメジャー・リリースのアップグレード中にデータベースは自動的に64ビットに変換されます。

変換を完了するには、次のアップグレード後の処理を手動で実行する必要があります。

- 64ビットの操作をサポートするために、システム・グローバル領域に影響を与える初期化パラメータ(SGA_TARGET、SHARED_POOL_SIZEなど)を増やします。

- 適切な64ビット用の初期化パラメータで新しいセッションを作成するために、データベースの起動後に再接続します。次に例を示します。

CONNECT  AS SYSDBA
STARTUP UPGRADE
CONNECT  AS SYSDBA
SPOOL UPGRADE.LOG
@catupgrd.sql

関連項目:

- 64ビット・ソフトウェアのインストールに関するプラットフォーム固有情報については、『Oracle Databaseインストレーション・ガイド」を参照してください。

- My Oracle Support (http://support.oracle.com)のNote ID 341880.1「How to convert a 32-bit database to a 64-bit database on Linux」

Oracle Databaseの32ビットから64ビットへの変換のトラブルシューティング

32ビットのデータベースを64ビットに移行する場合、utlrp.sqlスクリプトを実行すると、既知のエラーORA-07445が発生します。

ORA-07445: 例外が検出されました: コア・ダンプ [_intel_new_memcpy()+2132] [ACCESS_VIOLATION] [ADDR:0x11D1F0F67] [PC:0x621BEA4] [UNABLE_TO_READ] []

utlrp.sqlスクリプトはORACLE_HOME/rdbms/adminディレクトリにあり、ストアドPL/SQLおよびJavaコードを再コンパイルするために使用されます。このエラーおよび回避策については、My Oracle Support (http://support.oracle.com)のNote ID 341880.1「How to convert a 32-bit database to a 64-bit database on Linux」を参照してください。

Oracle Databaseのローリング・アップグレードの概要

ローリング・アップグレード処理では、データベースを停止することなく、Oracle Real Application Clusters(Oracle RAC)環境のOracle Automatic Storage Management(Oracle ASM)インスタンスを一度に1つずつアップグレードできます。選択したローリング・アップグレード方法に応じて、データベースをほとんどまたはまったく停止することなく、Oracle DatabaseソフトウェアやOracle ASMインスタンスのアップグレード、パッチ・セットの適用、または個々のパッチの適用(個別パッチとも呼ばれる)を実行できます。Databaseインスタンスのローリング・アップグレードはサポートされません。

関連項目:

- データベースのアップグレード方法の選択については、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

- 「Oracle Databaseのローリング・アップグレードの実行方法の概要」

Oracle Databaseのローリング・アップグレードの実行方法の概要

Oracleでは、ご使用の環境およびアプリケーションに応じて、ローリング・アップグレードを実行するための様々な方法とオプションを提供します。表1-2は、ローリング・アップグレードの様々な実行方法の概要と適切なドキュメントへの相互参照を示しています。

表1-2 Oracle Databaseのローリング・アップグレードの実行方法

方法

説明

参照

Oracle Data Guard SQL Apply

SQL Applyおよびロジカル・スタンバイ・データベースを使用して、Oracle Databaseソフトウェアおよびパッチ・セットをアップグレードします。

「スタンバイ・データベースを使用したアップグレードの概要」

Oracle Data Guardフィジカル・スタンバイ・データベース

既存のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換して、データベースのローリング・アップグレードを実行します。

「スタンバイ・データベースを使用したアップグレードの概要」

Oracle Streams

Oracle Streamsのソースと宛先データベースを使用すると、新しいリリースのOracle Databaseソフトウェアへのアップグレード、異なるオペレーティング・システムまたはキャラクタ・セット(あるいはその両方)へのOracle Databaseの移行、ユーザー作成アプリケーションのアップグレード、Oracle Databaseへのパッチの適用を行うことができます。

『Oracle Streams概要および管理』

OPatchユーティリティを使用したOracle RAC

OPatchユーティリティを使用して、Oracle RACのパッチのローリング・アップグレードを実行します。OPatchユーティリティは個々のパッチを適用する場合にのみ使用でき、パッチ・セット・リリースには使用できません。

この方法では、パッチのアップグレード中も使用できるようOracle RACの一部のインスタンスは使用可能です。停止する必要があるOracle RACインスタンスは、パッチが適用されているもののみで、他のインスタンスは使用可能にしておくことができます。OPatchユーティリティでは、Oracle RACの異なるインスタンスに対し、連続してパッチを適用できます。

『Oracle Universal InstallerおよびOPatchユーザーズ・ガイド』

『Oracle Database高可用性ベスト・プラクティス』

Oracle ClusterwareおよびOracle Universal Installer(OUI)

OUIおよびOracle Clusterwareを使用してローリング・アップグレードを実行し、Oracle Clusterwareのパッチ・セット・リリースを適用します。この方法では、パッチ・セットのアップグレード中も使用できるようOracle RACの一部のインスタンスを有効化します。停止する必要があるノードは、パッチが適用されているもののみで、他のインスタンスは使用可能にしておきます。OUIでは、クラスタの異なるインスタンスに対し、連続してパッチ・セットを適用できます。

『Oracle Grid Infrastructureインストレーション・ガイド』

『Oracle Universal InstallerおよびOPatchユーザーズ・ガイド』

Oracle Automatic Storage Management(Oracle ASM)

Oracle ASMを使用して、クラスタOracle ASMインスタンスに対して個別にアップグレードやパッチの適用を行います。この方法を使用すると、1つ以上のOracle ASMインスタンスが異なるバージョンのソフトウェアを実行していても、クラスタOracle ASM環境のすべての機能の使用を続けることができます。

注意: Oracle Database 11gリリース2(11.2)へのOracle ASMのローリング・アップグレードを使用すると、Oracle ASMインスタンスはOracle Grid Infrastructureホームに移動されます。

『Oracle Grid Infrastructureインストレーション・ガイド』

『Oracle Databaseストレージ管理者ガイド』のOracle ASMのローリング・アップグレードの使用に関する説明

Oracle DatabaseのStandard EditionからEnterprise Editionへの移行

新しいOracle Database 11gリリースより前のリリースのOracle Database Standard Editionを使用している場合は、Oracle Enterprise Editionソフトウェアをインストールし、第3章「新しいリリースのOracle Databaseへアップグレード」で説明する通常のアップグレード手順を実行して、Oracle Database Enterprise Editionに変更することができます。

注意:

この手順を実行すると、Standard Editionソフトウェアが削除され、その結果としてOracleホーム下に存在するデータベース・ファイルが削除されます。したがって、保持する必要のある現在のOracleホーム下のデータベース・ファイルはすべてバックアップする必要があります。これについては、手順4および5で説明しています。「リリース11.2.0.4の削除ツールに関する既知の問題」も参照してください。

既存のStandard EditionデータベースをEnterprise Editionデータベースに変更するには、次の手順を実行します。

1. Standard Editionサーバー・ソフトウェアとEnterprise Editionサーバー・ソフトウェアのリリース番号が同じかどうかを確認します。
たとえば、Standard Editionサーバー・ソフトウェアがリリース11.1.0.6の場合、Enterprise Editionサーバー・ソフトウェアもリリース11.1.0.6にアップグレードする必要があります。

2. データベースを停止します。

3. オペレーティング・システムがWindowsの場合、OracleServiceSID(SIDはインスタンス名)を含むすべてのOracleサービスを停止します。

4. $Oracle_Home/network/admin下のファイルのバックアップ・コピーを作成します。こうすることにより、これら一連の手順の完了後にリスナーが構成されます。

5. 保持する必要のある現在のOracleホーム下のデータベース・ファイルおよびデータをすべてバックアップします。

- Linuxの場合は、$Oracle_Home/dbs/をバックアップします。

- Windowsの場合は、$Oracle_Home/database/をバックアップします。

6. Oracle_Home/utlディレクトリにあるorabase_cleanup.lstファイルを編集し、「oradata」および「admin」エントリを削除します。「以前のリリースのOracle DatabaseのOracleホームを削除したことにより、そのOracleホームに関連付けられていた古いOracleベースが削除される可能性がある」を参照してください。

7. Standard Editionサーバー・ソフトウェアを削除します。
Oracleホームからdeinstallツールを実行します。削除ツールは、UNIXプラットフォームの場合$ORACLE_HOME/deinstallディレクトリに、Windowsプラットフォームの場合ORACLE_HOME\deinstallディレクトリにあります。

重要:

削除ツールでは、データベースのデータも含めてOracleホームにある既存のデータベース・ファイルがすべて削除されます。したがって、データの現在のバックアップを保持することをお薦めします。

8. Oracle Universal Installer(OUI)を使用して、Enterprise Editionサーバー・ソフトウェアをインストールします。
削除したStandard Editionで使用されていたのと同じOracleホームを選択します。インストール中は、必ずEnterprise Editionを選択します。プロンプトが表示されたら、「データベース構成」画面から「ソフトウェアのみ」を選択します。

9. データベースを起動します。

これで、ご使用のデータベースがEnterprise Editionへアップグレードされました。

リリース11.2.0.4の削除ツールに関する既知の問題

以前のリリースのOracle DatabaseのOracleホームを削除したことにより、そのOracleホームに関連付けられていた古いOracleベースが削除される可能性がある

原因: Oracle Databaseリリース11.2.0.1または11.2.0.2からリリース11.2.0.4へのアップグレード後、以前のリリースのOracle DatabaseのOracleホームを削除したことにより、そのOracleホームに関連付けられていた古いOracleベースが削除される可能性があります。また、これにより、古いOracleベース下に保存されてるデータ・ファイルや監査ファイルなども削除される可能性があります。重要な注意: この問題は、リリース11.2.0.1または11.2.0.2から11.2.0.4へのアップグレードに適用され、リリース11.2.0.3から11.2.0.4へのアップグレードには適用されません。

対応策: 以前のリリースのOracleホームを削除する前に、$Oracle_Home/utlディレクトリにあるorabase_cleanup.lstファイルを編集し、「oradata」および「admin」エントリを削除します。その後、アンインストールを続行します。

Oracle DatabaseのEnterprise EditionからStandard Editionへの移行

Enterprise EditionデータベースからStandard Editionデータベースへの変換を適切に行うには、エクスポート/インポート操作を実行する必要があります。このデータのエクスポートには、Standard Editionの エクスポート・ユーティリティ を使用することをお薦めします。Standard Editionソフトウェアのインストールのみを実行した場合、一部のデータ・ディクショナリ・オブジェクトが無効になり、データベースのメンテナンス時に問題が発生します。

Enterprise Editionには、Standard Editionで使用できないデータ・ディクショナリ・オブジェクトが含まれています。エクスポート/インポート操作では、SYSスキーマ・オブジェクトはエクスポートされないため、Enterprise Edition固有のデータ・ディクショナリ・オブジェクトは対象となりません。Standard Editionデータベースへのインポート後に必要な作業は、Enterprise Edition機能に関連するユーザー・スキーマの削除のみです。

関連項目:
第7章「Oracle Data Pumpを使用したデータの移動」

Oracle Database Express EditionからOracle Databaseへのアップグレードの概要

Oracle Database 10g Express Edition(Oracle Database XE)をOracle Database 11gにアップグレードするには、Oracle Database XEと同じシステム上にOracle Database 11gをインストールし、DBUAを使用してアップグレードを実行する必要があります。

関連項目:

- 『Oracle Universal InstallerおよびOPatchユーザーズ・ガイド』

- 第3章「新しいリリースのOracle Databaseへアップグレード」

2 Oracle Databaseのアップグレードの準備

Oracle Databaseのアップグレード処理には、システムの考慮点および要件の理解と、実際にアップグレード手順を実行する前の様々な問題のトラブルシューティングが含まれます。Oracle Databaseをアップグレードする前に、新しい機能および動作の変更点について詳しく理解しておく必要があります。アップグレードに備えて、新しいOracleソフトウェアをインストールします。このリリースの新しいOracleソフトウェアでは、最新のアップグレード前情報ツールを提供していますので、簡単に要件を理解してアップグレード前の処理を完了できます。

この章の内容は次のとおりです。

- Oracle Databaseのアップグレードを準備するための主な手順

- Oracle Databaseのアップグレード処理のテスト

- アップグレードしたテスト用Oracle Databaseのテスト

Oracle Databaseのアップグレードを準備するための主な手順

Oracle Databaseのアップグレードに備えて、新しい機能を確認し、最適なアップグレード・パスおよびアップグレード方法を決定します。アップグレード処理をテストし、バックアップ計画を準備することをお薦めします。

アップグレードの準備として、次の作業を行います。

- アップグレードする場合のOracle Databaseの新機能の理解

- Oracle Databaseをアップグレードする場合のアップグレード・パスの決定

- Oracle Databaseをアップグレードする場合のアップグレード方法の選択

- Oracle Databaseをアップグレードする場合の新しいOracleホームの場所の選択

- Oracle Databaseをアップグレードするためのテスト計画の作成

- Oracle Databaseをアップグレードする場合のバックアップ計画の準備

アップグレードする場合のOracle Databaseの新機能の理解

アップグレード処理を計画する前に、新しいOracle Database 11gリリースの機能を理解します。Oracle Databaseのリリース間の相違点については、『Oracle Database新機能ガイド』を参照してください。特定のコンポーネントの新機能については、Oracle Database 11gのドキュメント・ライブラリにある固有のガイドを参照してください。たとえば、Oracle Real Application Clustersの変更点については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

注意:

- Oracle Databaseで使用可能な機能を活用する方法を習得するには、Oracle Databaseのトレーニング・クラスを受講することが最適です。詳細は、http://education.oracle.com/で説明されています。

- My Oracle Supportで、最新パッチの入手方法、およびライフサイクル管理と自動化パッチに使用するツールについて詳細に説明したノートが提供されています。My Oracle Supportの利用方法の詳細は、http://www.oracle.com/us/support/software/premier/my-oracle-support-068523.htmlにアクセスしてください。

関連項目:
My Oracle Support(https://support.oracle.com)のNote ID 854428.1「Patch Set Updates for Oracle Products」

Oracle Databaseをアップグレードする場合のアップグレード・パスの決定

新しいOracle Database 11gリリースへアップグレードするために必要なパスは、現行のデータベースのリリース番号によって異なります。現行のリリースのOracle Databaseから最新のリリースに直接アップグレードできない場合があります。現行のリリースによっては、新しいOracle Database 11gリリースへのアップグレードに、1つ以上の中間リリースを介したアップグレードが必要となる場合があります。

たとえば、現行のデータベースがリリース9iを実行している場合は、次の手順に従います。

1. リリース2(10.2)の『Oracle Databaseアップグレード・ガイド』の指示に従って、リリース9.0.1.4からリリース10.2.0.4へアップグレードします。

2. このマニュアルの指示に従って、リリース10.2.0.4から新しいOracle Database 11gリリースへアップグレードします。

表2-1に、Oracle Databaseのリリースごとに必要なアップグレード・パスを示します。ご使用のデータベースに固有のアップグレード・パスおよびドキュメントを使用してアップグレードします。

表2-1 Oracle Databaseのアップグレードに対してサポートされているアップグレード・パス

現行リリース

アップグレード・パス

9.0.1.3以下

直接のアップグレードはサポートされていません。次のように、新しいOracle Database 11gリリースへアップグレードする前に、中間リリースのOracle Databaseにアップグレードする必要があります。

- 9.0.1.3(以下)→ 9.0.1.4 → 10.2.0.4 → 11.2

Oracle Databaseの中間リリースのドキュメントの指示に従って、中間リリースへアップグレードします。次に、第3章「Oracle Databaseの新しいリリースへのアップグレード」の指示に従って、中間リリースのデータベースを新しいOracle Database 11gリリースにアップグレードします。

9.2.0.8

10.1.0.5

10.2.0.2

11.1.0.6

9.2.0.8以上、10.1.0.5以上、10.2.0.2以上および11.1.0.6以上から新しいOracle Database 11gリリースへの直接のアップグレードがサポートされています。Oracle Clusterwareリリース10.2.0.nは、リリース10.2.0.3以上にしてからOracle Clusterware 11gにアップグレードする必要があることに注意してください。「Oracle Real Application Clusters(Oracle RAC)Databaseのアップグレードの概要」を参照してください。

リリース9.2.0.3の場合は、次のように、まず中間リリースのOracle Databaseにアップグレードする必要があります。

9.2.0.3(以下)→ 9.2.0.8 → 11.2

第3章「Oracle Databaseの新しいリリースへのアップグレード」の指示に従って、新しいOracle Database 11gリリースにアップグレードします。

関連項目:
データベースのダウングレードの詳細は、「Oracle Databaseのダウングレードがサポートされているリリース」を参照してください。

Oracle Databaseをアップグレードする場合のアップグレード方法の選択

データベースを新しいOracle Database 11gリリースへアップグレードする際に使用できる方法は次のとおりです。

- Database Upgrade Assistant(DBUA)

- 手動アップグレード

- Oracle Data Pump Export/ImportおよびOracle Databaseのアップグレード

Database Upgrade Assistant(DBUA)

Database Upgrade Assistant(DBUA)は、対話形式でアップグレード処理の手順を実行し、新しいOracle Database 11gリリースのデータベースを構成します。DBUAを使用すると、通常は手動で実行するアップグレード処理のすべてのタスクが自動化されます。DBUAでは、表領域、REDOログなどの構成オプションの適切な推奨値が提供されます。ユーザーは、この推奨値を使用できます。

DBUAでは、Oracle Real Application Clusters(Oracle RAC)がサポートされています。Oracle RAC環境では、DBUAは、クラスタ内のすべてのノードにあるすべてのデータベースおよび構成ファイルをアップグレードします。

手動アップグレード

手動アップグレードでは、コマンドラインからSQLスクリプトおよびユーティリティを実行して、データベースを新しいOracle Database 11gリリースへアップグレードします。

手動アップグレードでは、アップグレード処理をより詳細に制御できますが、実行されなかったアップグレード手順またはアップグレード前の手順がある場合、または不適切な順序で実行された場合にエラーが発生する可能性がより高くなります。

アップグレード前

次のリストに、手動のアップグレード手順の概要を示します。

- アップグレード前情報ツールを使用して、データベースを分析します。アップグレード前情報ツールは、新しいOracle Database 11gリリースに付属するSQLスクリプトであり、DBUAでは、アップグレード処理の一部としてこのスクリプトが使用されます。アップグレードするデータベースでこのスクリプトを実行します。
アップグレード前情報ツールでは、データベースで発生する可能性のあるアップグレードの問題に関する警告が表示されます。また、新しいOracle Database 11gリリースで必要な初期化パラメータの情報が表示されます。

- 新しいOracleホームを準備します。

関連項目:
詳細は、「Oracle Databaseをアップグレードする場合の新しいOracleホームの場所の選択」を参照してください。

- データベースのバックアップを実行します。

アップグレードしているデータベースのリリースに応じて、次のような追加のアップグレード前の手順が必要な場合があります。

- アップグレードに向けたパラメータ・ファイルの調整

- 廃止された初期化パラメータの削除

- アップグレードの問題が発生する可能性のある初期化パラメータの調整

関連項目:
『Oracle Database管理者ガイド』および『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- COMPATIBLEパラメータが明示的に設定されていない場合は、このパラメータを設定します。

関連項目:
COMPATIBLE初期化パラメータの設定の詳細は、「COMPATIBLE初期化パラメータの設定」を参照してください。

アップグレード後

アップグレードのスプール・ログ・ファイルを確認し、アップグレード後の状態ツールを使用します。アップグレード後の状態ツールは、新しいOracle Database 11gリリースに付属するSQLスクリプトです。アップグレード後の状態ツールは、新しいリリースの環境で実行します。アップグレード後の状態ツールは、データベースのアップグレード後にいつでも実行できます。

関連項目:
「Oracle Databaseの手動でのアップグレード」

Oracle Data Pump Export/ImportおよびOracle Databaseのアップグレード

DBUAまたは手動アップグレードとは異なり、Oracle Data Pump Export/Importユーティリティは、現行のデータベースのデータを新しいデータベースに物理的にコピーします。Oracle Database 10gリリース1(10.1)以上からアップグレードする場合は、パフォーマンス向上および新しいデータ型サポートの点から、データ・ポンプ・エクスポート/インポートを使用することをお薦めします。

現行のデータベースのエクスポート・ユーティリティは、データベースの特定部分をエクスポート・ダンプ・ファイルにコピーします。次に、新しいOracle Database 11gリリースのインポート・ユーティリティが、このエクスポートされたデータを新しいデータベースにロードします。ただし、エクスポート・ダンプ・ファイルからロードする前に、新しいOracle Database 11gのデータベースを準備しておく必要があります。

以前のリリースからデータをインポートする場合、新しいOracle Database 11gリリースのインポート・ユーティリティでは、以前のリリースのエクスポート・ダンプ・ファイルを読み込む際に、データ定義に適切な変更を加えます。

次の項では、データベースのアップグレードにエクスポート/インポートを使用するかどうかを決定する際に有効な、エクスポート/インポートの特長について説明します。

注意:

- データベースがOracle Databaseリリース10.1より前のリリースの場合、オリジナルのエクスポート/インポート・ユーティリティを使用してデータベースの全体または一部をエクスポートし、それを新しいOracle Database 11gデータベースにインポートします。エクスポート/インポートによって、元のデータベースを変更することなく、データベース内のデータのサブセットをコピーすることができます。

- オリジナルのエクスポート・ユーティリティは、新しいデータ型をサポートするように更新されなくなりました。

エクスポート/インポートによってアップグレードされたデータベースへの影響

エクスポート/インポートによるアップグレード方法では、現行のデータベースが変更されないため、データベースはアップグレード処理を通して常に使用可能な状態です。ただし、一貫性のあるデータベースのスナップショットが必要な場合(データの整合性保持またはその他の目的のため)、データベースは、制限モードで実行するか、またはエクスポート手順の実行中は変更禁止にする必要があります。現行のデータベースを使用可能な状態にしておくことができるため、たとえば、既存の本番データベースを実行しながら、エクスポート/インポートによる新しいOracle Database 11gデータベースの作成を同時に行うことができます。このアップグレード処理中にデータベースの完全な一貫性を維持するには、データベースのデータを変更する場合に、新しいOracle Database 11gデータベースにも同じ変更を加える必要があります。

最も重要なことは、エクスポート/インポート操作の結果として、新しいデータベースが作成されることです。現行のデータベースには最終的に指定したデータのコピーが含まれますが、アップグレードしたデータベースは、元のデータベースとは異なる方法で運用される場合があります。たとえば、エクスポート/インポート操作によってデータベースと同一のコピーを作成しても、データのディスク配置やチューニング・パラメータの解除など、その他の要素が予期しないパフォーマンスの劣化につながることがあります。

エクスポート/インポートのメリット

データ・ポンプ・エクスポート/インポートを使用したアップグレード:

- データの断片化を解消できます。インポートされたデータを圧縮することによって、パフォーマンスを向上できます。

- データベースを再構築できます。新しい表領域を作成するか、または既存の表や表領域、インポートによってデータがロードされる先のパーティションを変更できます。

- 完全に新しいデータベースが作成されるため、Oracle Databaseの新旧バージョンの比較テストを行うことができます。

- 指定されたデータベース・オブジェクトまたはユーザーをコピーできます。オブジェクト、ユーザーおよびその他の必要な項目のみをインポートすると、本番データのサブセットにのみ新規ソフトウェアのテスト環境を確立する場合に役に立ちます。データ・ポンプ・エクスポート/インポートでは、データのサブセット化機能を柔軟に使用できます。

- バックアップ・アーカイブとして機能します。データベースの全体エクスポートを現行のデータベースのアーカイブとして使用できます。

- アップグレードするデータベースをサポートしていないオペレーティング・システムまたはハードウェア・プラットフォーム上に、アップグレードしたデータベースを確立できます。ネットワーク・ベースのデータ・ポンプ・インポートにより、新規Oracle Databaseは、アップグレード対象の古いデータベースからネットワークを介して直接ロードできます。したがって、ダンプ・ファイルが介在する必要はありません。

エクスポート/インポートの時間要件

エクスポート/インポートを使用するデータベース全体のアップグレードは、DBUAを使用する場合または手動アップグレードを実行する場合と比較して、時間が長くかかる場合があります。したがって、ピーク時を外してアップグレードするようにスケジュールするか、またはアップグレード中に現行のデータベースに対して行われた変更を新しいデータベースに反映させる準備が必要です。

関連項目:
第7章「Oracle Data Pumpを使用したデータの移動」

Oracle Databaseをアップグレードする場合の新しいOracleホームの場所の選択

新しいOracle Database 11gリリースに、現行のリリースのOracleホームとは別のOracleホームの場所を選択する必要があります。Oracle Database 11gのパッチ・セット・リリースをインストールしないかぎり、新しいソフトウェアを現行のリリースと同じOracleホームの場所にインストールすることはできません。パッチ・セット・リリースの場合、Oracle Database 11gと同じOracleホームを使用できます。

別のインストール・ディレクトリを使用すると、既存のソフトウェアをインストールしたままで、新しいソフトウェアを使用できます。この方法によって、本番環境全体を置き換える前にテスト・データベース上でアップグレード処理をテストできます。

Oracle Databaseをアップグレードするためのテスト計画の作成

アップグレード処理のすべての段階を検証するために、一連のテストを慎重に設計する必要があります。緻密なテストを正常に完了できれば、本番データベースのアップグレード処理を十分に理解し、予測できるようになり、アップグレード処理の成功が確実になります。本番データベースをアップグレードする前に、できるだけ多くのテストを実行してください。完全で反復可能なテスト処理は、非常に重要です。

データベース・リプレイやSQLパフォーマンス・アナライザなどのReal Applicationのテスト機能を使用するか、または手動でテストを実行するかに関係なく、実行するテストのタイプは同じです。

テスト計画には次のタイプのテストを含める必要があります。

- Oracle Databaseのアップグレード・テスト

- Oracle Databaseをアップグレードする場合の最小テスト

- Oracle Databaseをアップグレードする場合の機能テスト

- Oracle Databaseをアップグレードする場合の高可用性テスト

- Oracle Databaseをアップグレードする場合の統合テスト

- Oracle Databaseをアップグレードする場合のパフォーマンス・テスト

- Oracle Databaseをアップグレードする場合のボリューム/ロード・ストレス・テスト

Oracle Databaseのアップグレード・テスト

アップグレード・テストでは、DBUAの使用、手動アップグレードの実行、エクスポート/インポートまたはその他のデータのコピー方法を使用するかに関係なく、現行のソフトウェアから新しいOracle Database 11gリリースへのアップグレード・パスを計画およびテストする必要があります。どのアップグレード方法を選択する場合でも、アップグレード計画を作成、テストおよび検証する必要があります。

Oracle Databaseをアップグレードする場合の最小テスト

最小テストでは、現行のデータベースからアプリケーションの全部または一部を新しいデータベースに移動し、データベースの新機能を使用可能にしないでアプリケーションを実行します。最小テストでは、実際の本番環境で発生するような問題が検出されない場合があります。ただし、アプリケーションの起動または呼出しに関する問題がある場合は、すぐに検出されます。

Oracle Databaseをアップグレードする場合の機能テスト

機能テストとは、システムの新機能と既存機能をアップグレード後にテストする一連のテストです。機能テストには、すべてのデータベース、ネットワーキングおよびアプリケーション・コンポーネントのテストが含まれます。機能テストの目的は、システムの各コンポーネントがアップグレード前と同様に機能し、新機能が正常に動作していることを検証することです。

Oracle Databaseをアップグレードする場合の高可用性テスト

高可用性テストでは、次が行われます。

- アップグレードしたシステムが、引き続きRecovery Time Objective(RTO)およびRecovery Point Objective(RPO)のビジネス要件を満たしていることを確認します。たとえばOracle RAC環境において、ストレス・テスト中にノードまたはインスタンスの挿入に失敗した場合、この事実からOracle RACのリカバリ可能性が変化したかどうかを評価することができます。

- フォールバック計画および手順をテストします。

- データベースのパフォーマンスおよび安定性を確認し、パフォーマンスの問題を解決します。

関連項目:
『Oracle Database高可用性概要』およびMy Oracle Support(http://support.oracle.com/)のNote 785351.1で参照可能な「The Upgrade Companion」Webサイト。

Oracle Databaseをアップグレードする場合の統合テスト

統合テストでは、システムのコンポーネント間で相互作用をテストします。統合テストを計画するときは、次のことを考慮する必要があります。

- 新しいOracle Database 11gのインスタンスで稼働するPro*C/C++アプリケーションは、新しいソフトウェアで問題がないことを確認するためにテストする必要があります。

- Graphical User Interfaceを他のコンポーネントでテストする必要があります。

- 新しいOracle Database 11gのインスタンスにアプリケーションが直接接続されるかどうかに関係なく、データ型やデータ・ディクショナリのデータの変更(データ・ディクショナリへの行の追加、オブジェクト型の変更)などの新しいOracle Database 11gリリースのわずかな変更でも、フロントエンド・アプリケーションにまで影響することがあります。

- 2つのコンポーネントがOracle NetまたはOracle Net Servicesを使用して接続されている場合は、ストレス・テストとともにその接続のテストも行う必要があります。

Oracle Databaseをアップグレードする場合のパフォーマンス・テスト

新しいデータベースのパフォーマンス・テストでは、新しいデータベースでの様々なSQL文のパフォーマンスを、現行データベースでの同じ文のパフォーマンスと比較します。アップグレードする前に、現行データベースでのアプリケーションのパフォーマンス・プロファイルを理解する必要があります。特に、アプリケーションがデータベース・サーバーに対して実行するコールを理解する必要があります。

この項では、次のようなパフォーマンス・テストについて説明します。

- データベース・リプレイ

- SQLパフォーマンス・アナライザ

- SQL計画管理

データベース・リプレイ

Oracle Database 11gリリース1(11.1)以上では、新しいデータベース・リプレイ機能を使用して、本番データベースを実際にアップグレードする前に、ユーザーのサイトの本番ワークロード上でデータベースをアップグレードする現実的なテストを実行できるようになりました。この機能は、本番システム上で実際のデータベースのワークロードを取得して、これをテスト・システム上でリプレイします。また、潜在的な問題(エラーの発生やパフォーマンスの相違など)を示す分析とレポート作成も提供されます。さらに、自動データベース診断モニター、自動ワークロード・リポジトリ(AWR)およびアクティビティ・セッション履歴など、定期的なEnterprise Managerパフォーマンスの監視およびレポート作成ツールをすべて使用して、問題に対処します。

注意:
データベース内のストアド・プロシージャのロジックは変更できますが、アプリケーション・ロジックを実装しているストアドPL/SQLプロシージャでは、アップグレード前と同じインスターフェースを維持する必要があります。アプリケーションのストアド・プロシージャがアップグレードによって影響を受ける場合は、ワークロードをリプレイできない場合があります。このようにデータベース・リプレイ・ツールを使用すると、サーバー内の新しいアプリケーション・ロジックがアップグレード後にも期待どおりに動作するかどうかを確認でき、有効な診断が行えます。

関連項目:
ワークロードの取得およびリプレイの方法については、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。

SQLパフォーマンス・アナライザ

Oracle Database 11gリリース1(11.1)より、SQLパフォーマンス・アナライザを使用して、システムの変更がSQLワークロードに及ぼす影響を予測できるようになりました。SQLパフォーマンス・アナライザでは、アップグレードによって影響を受けたSQL文を識別してパフォーマンスの相違を測定することで、データベースのアップグレードなどの変更による影響を予測できます。分析により、アップグレードによるSQLパフォーマンスに対する全体的な影響を評価し、悪い結果をユーザーが影響を受ける前に回避できます。

関連項目:
潜在的なデータベース変更のWhat-if分析にSQLパフォーマンス・アナライザを使用した詳細および例は、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。

SQL計画管理

SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。SQL計画管理は、一定期間におけるSQL文の実行計画を記録および評価する予防的メカニズムであり、効率的であることが確認されている既存の計画で構成されたSQL計画のベースラインを構築します。SQL計画のベースラインは、システムで発生している変更に関係なく、対応するSQL文のパフォーマンスを保持するために使用されます。

新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、通常、SQL文に対して若干の計画変更がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。

SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、SQL文に対して若干の計画変更がある場合がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。

SQL計画管理を使用すると、オプティマイザによって実行計画が自動的に管理され、既知の計画または検証済の計画のみが使用されます。SQL文に対する新しい計画が検出されても、その計画が現行の計画と同等かそれ以上のパフォーマンスであることがデータベースによって確認されるまでは使用されません。そのため、SQL計画管理を現行(Oracle Database 11gよりも前)の実行計画でシードすると、これらは各文のSQL計画のベースラインになり、これらの計画は、アップグレード後に使用されます。異なる計画を使用する必要があるとOracle Database 11gオプティマイザが判断した場合でも、新しい計画は検証のためにキューに格納され、現行の計画と同等かそれ以上のパフォーマンスを実現できる計画であることが確認されるまでは、使用されません。

SQL管理ベース(SMB)を実行計画にシードまたは移入するには、次の2つの方法があります。

- 実行計画の自動取得(Oracle Database 11g以上で使用可能)

- 実行計画または既存のSQL計画ベースラインのバルク・ロード

実行計画またはSQL計画ベースラインのバルク・ロードは、データベースを以前のリリースからOracle Database 11gにアップグレードする場合に特に役立ちます。バルク・ロードされるSQL計画は、自動的にそのまま使用され、SQL計画ベースラインとして既存または新規の計画履歴に追加されます。

アップグレードの一部としてSQL管理ベースをバルク・ロードするには、次の操作を実行します。

- 特定のSQLチューニング・セット(STS)に対して実行計画を移入する(「SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード」を参照)。
または、

- ステージング表からの既存のSQL計画ベースラインを展開する(「ステージング表からの既存のOracle DatabaseのSQL計画ベースラインの展開」を参照)。

SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード

STSから実行計画を使用してSQL管理ベースをバルク・ロードするには、次の手順を実行します。

1. Oracle Database 10gリリース2(10.2)で、各SQL文の実行計画を含むSTSを作成します。

2. STSをステージング表にロードし、ステージング表をダンプ・ファイルにエクスポートします。

3. ステージング表をダンプ・ファイルからOracle Database 11gにインポートし、STSをアンロードします。

4. Oracle Enterprise ManagerまたはDBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。

ステージング表からの既存のOracle DatabaseのSQL計画ベースラインの展開

次の一連の手順を実行し、すべての重要なSQL問合せをOracle Database 11gのテスト環境でテストおよびチューニングしてから、その正確なSQL実行計画をOracle Database 11gの本番環境に移動します。

Oracle Database 11gのテスト環境で、重要なSQL問合せをテストおよびチューニングするには、次の手順を実行します。

1. Oracle Database 11gのテスト環境で、すべてのテストとチューニングを完了してから、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはEnterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。

2. DBMS_SPM.CREATE_STGTAB_BASELINEプロシージャを使用して、ステージング表を作成します。

3. DBMS_SPM.PACK_STGTAB_BASELINEファンクションを使用して、手順1で作成したSQL計画ベースラインをステージング表に格納します。

4. エクスポート・コマンドまたはデータ・ポンプを使用して、ステージング表をフラット・ファイルにエクスポートします。

5. このフラット・ファイルをターゲット・システムに転送します。

6. インポート・コマンドまたはデータ・ポンプを使用して、フラット・ファイルからステージング表をインポートします。

7. DBMS_SPM.UNPACK_STGTAB_BASELINEファンクションを使用して、ステージング表からターゲット・システムのSQL管理ベースにSQL計画ベースラインを展開します。

関連項目:
SQL計画管理の使用の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Oracle Databaseをアップグレードする場合のボリューム/ロード・ストレス・テスト

ボリューム/ロード・ストレス・テストでは、アップグレードしたデータベース全体を、大きいボリュームとロードでテストします。ボリュームとは、操作されるデータの量を表します。ロードとは、システム上の同時要求のレベルを表します。ボリューム/ロード・ストレス・テストの目的は、様々なボリュームとロードでの本番システムの動作をエミュレートすることです。

ボリューム/ロード・ストレス・テストは非常に重要ですが、一般に見過ごされがちです。ユーザーは、どのようなボリューム/ロード・ストレス・テストも実行しないことが多いようです。そのかわりに、ビジネス・アプリケーションを特に考慮しているわけではないベンチマークが広く利用されています。アプリケーションのベンチマークは、機能、パフォーマンスおよび統合に関する問題点を検証するために使用するものであり、ボリューム/ロード・ストレス・テストのかわりになるものではありません。

ロード・テストには、本番稼働時に発生する可能性のあるロード条件で新しいエラーやパフォーマンス上の問題などがアプリケーションに発生しないことを確認するため、新リリースのデータベースに対するアプリケーション・ロードの実行を含みます。多くの場合、問題は特定のロード条件で明らかになるため、通常、機能テストでは見つかりません。データベース・リプレイ機能は、本番環境のシステム・ワークロードを取得し、テスト・システム上で同一形式でリプレイできるため、このようなロード・テストに最適です。

Oracle Databaseをアップグレードする場合のバックアップ計画の準備

アップグレードが最終的に成功するかどうかは、適切なバックアップ計画の立案と実行で決まります。

バックアップ計画を展開するには、次のような問題について考慮する必要があります。

- 業務上、本番データベースの実行不可能状態の許容範囲がどの程度の期間か。

- 可用性要件を満たすには、どのバックアップ計画が必要か。

- サイトから離れた安全な場所にバックアップをアーカイブする必要があるか。

- どのくらいの時間でバックアップをリストアできるか(オフサイト記憶域でのバックアップを含む)。

- リカバリ手順は正常にテストされているか。

バックアップ計画は、これらの問題のすべてに答え、データベースを正常にバックアップおよびリカバリするための手順を備えている必要があります。

関連項目:
データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

Oracle Databaseのアップグレード処理のテスト

現行の本番データベースに影響しないテスト環境を作成します。

テスト環境は、選択したアップグレード方法によって異なります。

- DBUAを使用する場合または手動アップグレードを実行する場合は、現行の本番データベースのテスト・バージョン(通常はサブセット)を作成してアップグレードをテストします。

- エクスポート/インポートを使用する場合は、現行の本番データベースからほんの一部分をテストとしてエクスポート/インポートします。

テスト環境を使用してデータベースのアップグレードを行います。最良のアップグレード・テスト(作成が可能な場合)とは、ダウンサイズしたコピーまたはテスト・データに対してではなく、アップグレードするデータベースの正確なコピーに対して実行することです。なんらかの理由で正確なコピーを実行できない場合は、データの代表的なサブセットを慎重に選択してテスト環境に移動し、そのデータでアップグレードをテストします。

新しいOracle Databaseで使用するOCIとプリコンパイラ・アプリケーションを、必ずアップグレードしてください。それによって、現行の本番データベースをアップグレードする前に、それらのアプリケーションをサンプルのデータベースでテストできます。

関連項目:
詳細は、「プリコンパイラおよびOCIアプリケーションのアップグレード」を参照してください。

アップグレードしたテスト用Oracle Databaseのテスト

現行のデータベースおよび新しいOracle Database 11gリリースへアップグレードされたテスト・データベースに対して、計画したテストを実行します。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。

新しいOracle Databaseで既存のアプリケーションが正常に動作するかを確認するために、この新しくアップグレードされたテスト・データベースをテストします。また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションが現行のデータベースの場合と同様に動作するかを最初に確認してください。

関連項目:
Oracle Databaseでのアプリケーションの使用方法の詳細は、第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」を参照してください。

3 新しいリリースのOracle Databaseへのアップグレード

新しいリリースのOracle Databaseへのアップグレードは、データベースのメンテナンスおよび管理の基本部分です。Oracleでは、Database Upgrade Assistant、専用スクリプトおよび専用ツールを提供することで、アップグレード処理を支援し、多くの手順を自動化しています。この章では、重要な情報と要件について説明し、データベースをOracle Database 11gリリース2(11.2)にアップグレードする処理の手引きを示します。

この章の内容は次のとおりです。

- Oracle Databaseをアップグレードする場合のシステムの考慮点および要件

- アップグレードする場合の新しいOracle Databaseソフトウェアのインストール

- 最新のパッチ・セット更新および必須のパッチの概要

- アップグレード前情報ツールの使用

- Oracle9iからアップグレードする場合のリスナーの構成

- Linux、UNIXおよびWindowsでのDatabase Upgrade Assistantを使用したアップグレード

- オプションでのインプレース・アップグレードの実行(同じOracleホームへ)

- Oracle Databaseの手動でのアップグレード

- Oracle Databaseのアップグレードのトラブルシューティング

- Oracle Databaseのアップグレードの再実行

- Oracle Databaseのアップグレードの取消し

- Oracle ASMインスタンスのアップグレードの概要

注意:

古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。

Oracle Databaseをアップグレードする場合のシステムの考慮点および要件

新しいリリースのOracle Databaseにアップグレードする場合は、通常、新しいシステム要件または変更されたシステム要件があります。次の項では、Oracle Databaseのアップグレードを開始する前に実行する各種チェックや考慮点について説明します。

- 新しいOracle Database環境への既存のデータ・ファイルの再配置

- デフォルトでインストールされていないPL/SQLパッケージのアップグレードの概要

- Oracle Grid InfrastructureとともにインストールされるOracle ASMのアップグレードの概要

- Oracle ClusterwareおよびOracle ASMインスタンスのアップグレードに関する考慮点

- 読取り専用およびオフラインの表領域を使用したアップグレードの概要

- スタンバイ・データベースを使用したアップグレードの概要

- オペレーティング・システムのアップグレードの概要

- 異なるオペレーティング・システムへのデータの移行

- Oracle Streamsのダウンストリーム取得を使用しているデータベースのアップグレードの概要

- Oracle Database Vaultを使用しているデータベースのアップグレードの概要

重要:
このリリースにアップグレードするには、既存のOracleホームにパッチ・セットを適用するのではなく、新しいOracleホームにOracle Grid InfrastructureとOracle Databaseソフトウェアをインストールする必要があります。これはアウトオブプレース・アップグレードと呼ばれ、パッチ・セットが常にインプレースでインストールされるOracle Databaseの以前のリリースのパッチ・セット・リリースとは異なります、

注意:
Oracle Grid Infrastructureではインプレース・アップグレードがサポートされていません。新しいGrid Infrastructureホームへのアウトオブプレース・アップグレードのみがサポートされています。

関連項目:

- Oracle Net Servicesのアップグレードに関する考慮点については、『Oracle Database Net Services管理者ガイド』を参照してください。

- アップグレードの準備の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

- ローリング・アップグレードの詳細は、「Oracle Databaseのローリング・アップグレードの概要」を参照してください。

新しいOracle Database環境への既存のデータ・ファイルの再配置

古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置する必要があります。

データ・ファイルを新しいOracle Database環境に再配置するには、次の手順を実行します。

- Database Upgrade Assistant(DBUA)を使用し、アップグレード中に「データベース・ファイルの移動」オプションを選択します。

関連項目:

詳細は、「Linux、UNIXおよびWindowsでのDatabase Upgrade Assistantを使用したアップグレード」を参照してください。

手動でアップグレードを行う場合は、『Oracle Database管理者ガイド』でデータ・ファイルの再配置の詳細を参照してください。

デフォルトでインストールされていないPL/SQLパッケージのアップグレードの概要

現在のリリースにアップグレードしようとしているデータベース上にすでにインストールされているパッケージは、自動的にアップグレードされない場合があります。パッケージが現在のリリースで使用可能かどうかを個別に確認し、そのパッケージを再インストールして最新バージョンにする必要があります。

関連項目:
「アクセス制御リストおよびネットワーク・ユーティリティ・パッケージの管理と更新」

Oracle Grid InfrastructureとともにインストールされるOracle ASMのアップグレードの概要

Oracle ASMは、Oracle Grid Infrastructureのアップグレードの一部としてアップグレードされます。Oracle Grid Infrastuctureをアップグレードしないと、Oracle ASMはアップグレードできません。

関連項目:

- 「Oracle ASMインスタンスのアップグレードの概要」

- 『Oracle Grid Infrastructureインストレーション・ガイド』

Oracle ClusterwareおよびOracle ASMインスタンスのアップグレードに関する考慮点

Oracle Database 11gリリース2(11.2.0.1)以上では、Oracle ClusterwareとOracle Real Application Clusters(Oracle RAC)を既存のインストールとは別の新しいホームにインストールする必要があります。これにより、クラスタ内のノードのアップグレードに必要な停止時間が短縮され、企業内のクラスタのプロビジョニングが容易になります。クラスタのアップグレードに必要な計画停止時間を短縮することで、可用性サービス・レベルを満たし、企業全体への標準インストールを簡単に行うことができます。

Oracle ClusterwareとOracle ASMインスタンスのアップグレードに関する考慮点を次に示します。

- Oracle Database 11gより前のリリースでは、Oracleユーザー(通常、oracle)がすべてのOracleソフトウェア・インストールを所有しているか、またはOracle Databaseソフトウェアはoracleが所有し、Oracle Clusterwareソフトウェアは別のユーザー(通常、crsuser)が所有していました。

- Oracle Database 11g以上では、リリース10gのCluster Ready Services(CRS)ソフトウェアの所有者として指定されたユーザー・アカウントがOracle Clusterware 11gのアップグレードを実行する必要があります。このアップグレードを実行するユーザー・アカウントは、以前のリリース(つまり、リリース11.2より前のリリース)のASMホームを所有するユーザーでもある必要があります。11.2より前のASMホームの所有者が異なる場合、アップグレードを実行する前に所有者アカウントを変更する必要があります。

- Oracle Database 11gリリース2(11.2)では、Oracle Clusterwareソフトウェアは、Oracle Grid Infrastructureホーム内の新しいホームの場所にアップグレードする必要があります。また、同じOracle Grid InfrastructureホームでOracle ASMおよびOracle Clusterware(単一インスタンス・データベースの場合はOracle Restart)を実行する必要があります。Oracle Clusterwareをリリース11.2にアップグレードするとき、OUIによって自動的にOracle ASM Cluster Assistant(ASMCA)がコールされ、Oracle Grid Infrastructureホームへのアップグレードが実行されます。

- Oracle Databaseリリース11.2.0.3にアップグレードするには、既存のOracleホームではなく、新しいOracleホームにOracle Grid InfrastructureとOracle Databaseソフトウェアをインストールする必要があります。

- 単一インスタンス構成の場合は、Oracle Grid InfrastructureホームからOracle ASMおよびOracle Restartを実行し、同じホームからCluster Synchronization Services(CSS)デーモンを実行します。このため、Oracle ASMおよびCSSは、Oracle Database 11gリリース2(11.2)に同時にアップグレードされます。

- Oracle Databaseリリース11.1以前のリリースでは、構成にOracle ASMが含まれていない場合は、CSSデーモンを停止し、deleteオプションを指定してlocalconfigコマンドを実行することによって、システムからCSSサービスを削除する必要があります。次に例を示します。

ORACLE_HOME/bin/localconfig delete

- Oracle ASMディスク・グループのデータベース互換性属性が、init.oraで設定されている互換性パラメータと同じであることを確認する必要があります。

現在のデータベース構成にOracle ASMが含まれているかどうかの確認

構成にOracle ASMが含まれているかどうかが不明な場合は、データベース・インスタンスで次のSQL文を発行します。

select count(*) from v$asm_client where status = 'CONNECTED';

この文によって1つ以上の行が戻された場合は、現在データベースでOracle ASMディスク・グループが使用されています。

Oracle Real Application Clusters(Oracle RAC)データベースのアップグレードの概要

Database Upgrade Assistant(DBUA)を使用して、既存のOracle RACデータベースをOracle Databaseの現行リリースにアップグレードできます。DBUAの指示に従ってアップグレード処理を実行し、新しいリリースのデータベースを構成します。DBUAでは、アップグレード処理が自動化され、表領域、オンラインREDOログ・ファイルなどの構成オプションの適切な推奨値が提供されます。

手動でOracle RACデータベースをアップグレードする場合、ほとんどの処理はシステムの1つのノードのみで実行する必要があります。複数のノードで実行する必要がある処理については、該当する手順で示されます。

Oracle RACで時間の同期を行う場合の要件の概要

Oracle Clusterware 11gリリース2(11.2)では、Oracle RACのデプロイ時にクラスタ内のすべてのノードで時間の同期を行う必要があります。

時間の同期を行う場合は、次のオプションのいずれかを使用できます。

- オペレーティング・システムで構成されたネットワーク・タイム・プロトコル(NTP)

- Oracleクラスタ時刻同期化サービス

関連項目:
NTPおよびOracleクラスタ時刻同期化サービスの構成の詳細は、オペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

Oracle ASMを使用するOracle RACおよびデータベースのアップグレードに関する考慮点

データ・ファイルのストレージにOracle ASMを使用しているOracle RACおよびデータベースをアップグレードしている場合は、追加の制限と要件を考慮する必要があります。

- 以前のリリースから11.2.0.3へアップグレードする場合は、ノードのサブセットを選択できません。
新しいデータベース・リリース11.2.0.3のソフトウェアがシステム上にインストールされる前に、Oracle Grid InfrastructureをアップグレードするためのrootスクリプトによってASMCAが起動され、Oracle ASMがリリース11.2.0.3にアップグレードされます。

- Oracle Clusterwareソフトウェアがリリース11.2.0.1にアップグレードされ、Oracle ASMで以前のリリースが実行されている場合、Oracle ASMクラスタがアップグレードされなかったことを示すエラーがDBUAにより表示されます。この場合、Oracle Databaseリリース11.2.0.3のソフトウェアがシステム上にインストールされる前に、rootスクリプトによってOracle ASM Cluster Assistant(ASMCA)が起動され、Oracle ASMがリリース11.2.0.1にアップグレードされます。

- リリース11.2.0.1を11.2.0.3にアップグレードする場合、DBUAでは、Oracle Clusterwareスタックが起動状態である必要があります。DBUAによってOracle Clusterwareスタックがローカル・ノードで停止状態であると認識されると、ローカル・ノードでスタックを起動するためにコマンドを実行する必要があることを示すエラー・メッセージが表示されます。

- DBUAでは、11.2.0.1クラスタへの単一インスタンス・データベース(SIDB)リリース11.2.0.3のインストールは許可されません。

- DBUAによってOracle Restartが検出されると、データベースをOracle Restartに登録するかどうかを確認するページが表示されます。Oracle Restartへの登録を選択した場合、まずOracle Grid Infrastructureをリリース11.2.0.3にアップグレードするよう求めるメッセージがDBUAにより表示されます。

注意:
Oracle Restartは、以前はOracle単一インスタンスの高可用性(SIHA)と呼ばれていました。

Oracle ASMインスタンスのシステム認証のアップグレードの概要

Oracle Database 11gリリース1(11.1)以上では、SYSASM権限を使用してデータベース管理の職責とストレージ管理の職責を分離することが必要になりました。さらに、Oracle ASMおよび各データベースに対して異なるオペレーティング・システム資格証明を作成することもできるようになっています。これにより、データベース管理の職責とストレージ管理の職責をさらに厳重に分離することが可能になります。たとえば、あるノード上のOracle ASMを使用しているデータベースがn個ある場合、SYS権限を持つメンバーのオペレーティング・システム資格証明グループをn+1セット構成できます(つまり、各データベース用のSYSDBA権限を持つOSDBAグループが1つずつと、Oracle ASMインスタンス用のSYSASM権限を持つOSASMグループが1つです)。

Oracle ASMインスタンスのアップグレードに関する考慮点

Oracle ASMインスタンスを新しいOracle Database 11gリリースにアップグレードする前に、ノードのOracle ASMインスタンスに対してローカルなパスワード・ファイルに、ユーザーとパスワードの組合せを追加する必要があります。この操作には、次のSQL*Plus CREATE USER文を使用します。

CREATE USER user_name IDENTIFIED BY password;

- Oracle ASMインスタンスのアップグレードを行っている場合にのみ、パスワード・ファイルにユーザーとパスワードの組合せを追加する必要があります。Oracle ASMをアップグレードせずに、新しいOracle Database 11gリリースにデータベースをアップグレードする場合、この手順は必要ありません。

- Oracle Database 11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。

関連項目:

- Oracle ASMインスタンスへのアクセスの認証の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

- CREATE USERの構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- パスワード管理のガイドラインおよびセキュリティ上のその他の推奨事項については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

読取り専用およびオフラインの表領域を使用したアップグレードの概要

Oracle Database 11gリリース1(11.1)以上のリリースでは前のリリースで作成されたファイル・ヘッダーを読み取ることができるため、アップグレード時にそれらに対して処理を行う必要はありません。Oracle Database 11gリリース1(11.1)より前に作成された表領域を別のプラットフォームに転送する場合は例外です。この場合は、転送前のある時点でファイル・ヘッダーを読取り/書込み両用にする必要があります。ただし、アップグレード時にこれらに対して特別な処理を行う必要はありません。

オフラインのデータ・ファイルのファイル・ヘッダーは、後でオンラインにしたときに更新され、読取り専用の表領域のファイル・ヘッダーは、アップグレード後のある時点で読取り/書込みにしたときに更新されます。他のすべての状況では、読取り専用の表領域を読取り/書込みにする必要はありません。

関連項目:
読取り専用の表領域、およびデータベース間で表領域を転送する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

スタンバイ・データベースを使用したアップグレードの概要

Oracle Data Guard構成にスタンバイ・データベースが存在する場合にOracle Databaseソフトウェアをアップグレードする方法は、『Oracle Data Guard概要および管理』を参照してください。Oracle Data Guardブローカ構成でOracle DatabaseおよびOracle Enterprise Managerソフトウェアをアップグレードまたはダウングレードする方法は、『Oracle Data Guard Broker』を参照してください。

ローリング・アップグレード時に、プライマリ・データベースおよびスタンバイ・データベースで異なるリリースのOracle Databaseソフトウェアを実行して、一度に1つずつアップグレードし、プライマリ・データベースでの停止時間を最小にすることができます。次のいずれかの方法を使用します。

- SQL Applyおよびロジカル・スタンバイ・データベース
Oracle Database 10gリリース1(10.1.0.3)以上では、ロジカル・スタンバイ・データベースでOracle Data Guard SQL Applyを使用して新しいOracle Database 11gリリースへのローリング・アップグレードを実行できます。たとえば、Oracle Databaseソフトウェアをリリース10.1.0.nのパッチ・セットから次のリリース10.1.0.(n+1)にアップグレードしたり、Oracle Database 10gリリース1(10.1)からOracle Database 11gリリース2(11.2)にアップグレードすることができます。

- ローリング・アップグレード用のフィジカル・スタンバイ・データベースの使用
このリリースから、フィジカル・スタンバイ・データベースは、ロジカル・スタンバイにより提供されるローリング・アップグレード機能を利用できるようになります。SQLのALTER DATABASE RECOVER TO LOGICAL STANDBY文で新しいKEEP IDENTITY句オプションを使用することにより、ローリング・アップグレードのためにフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換してから、アップグレードの終了後、プライマリ・データベースとフィジカル・スタンバイ・データベースを元の構成に戻すことができます。

関連項目:

- 『Oracle Database高可用性ベスト・プラクティス』

- 次に示すOracle Maximum Availability Architecture(MAA)のホワイト・ペーパー(http://www.oracle.com/technetwork/database/features/availability/maa-090890.html)
『Rolling Database Upgrades for Physical Standby Databases Using Transient Logical Standby 11g』

『Rolling Database Upgrades using Data Guard SQL Apply』

オペレーティング・システムのアップグレードの概要

新しいリリースのOracleソフトウェアにアップグレードする場合、オペレーティング・システム要件が変更されている可能性があります。必要に応じて、Oracle Databaseをアップグレードする前にオペレーティング・システムをアップグレードします。

関連項目:

- サポートされているオペレーティング・システムの一覧を取得するには、ご使用のプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。

- オペレーティング・システムのアップグレードを実行する方法については、ご使用のオペレーティング・システム固有のマニュアルを参照してください。

異なるオペレーティング・システムへのデータの移行

DBUAを使用している場合または手動でアップグレードを実行している場合は、オペレーティング・システム間でデータベースのデータは移行できません。たとえば、DBUAを使用して、Solaris上のOracle9iデータベースのデータをWindows上のOracle 11gデータベースには移行できません。

Oracle Databaseソフトウェアを異なるオペレーティング・システムに移行するには、次の手順を実行します。

1. このマニュアルの指示に従って、現行のオペレーティング・システム・プラットフォームで、新しいOracle Database 11gリリースにアップグレードします。

2. アップグレードしたデータベースを現行のオペレーティング・システム・プラットフォーム上でテストします。

3. Oracle Data Guardおよびフィジカル・スタンバイ・データベースを使用して、オペレーティング・システム間での移行を行います。

関連項目:
同一のOracle Data Guard構成での異機種間のプライマリ・システムおよびスタンバイ・システムに対するOracle Data Guardサポートの詳細は、https://support.oracle.com/にあるMy Oracle Support(以前のOracleMetaLink)のNote 413484.1を参照してください。

4. 移行するプラットフォームの組合せでクロス・プラットフォームのフィジカル・スタンバイ・データベースを使用できない場合は、Oracle Database 11gのクロス・プラットフォームのトランスポータブル表領域機能またはOracle Data Pump Export/Importユーティリティを使用して、アップグレードされたデータベースを異なるオペレーティング・システムに移行することができます。

注意:
トランスポータブル表領域では、SYSTEM表領域またはSYSAUX表領域の移行はサポートされていません。ロール、トリガー、ビュー、プロシージャなどのすべての非セグメント・ユーザー・データは、スクリプトまたはエクスポート/インポートを使用して新しいオペレーティング・システムに移動する必要があります。

5. 2つのオペレーティング・システムが同じエンディアンのグループに属している場合は、Oracle Database 11gのクロス・プラットフォームのトランスポータブル表領域機能を使用して、データベース全体を移行することができます。

6. Oracle Streamsを使用してオペレーティングシステム間でデータを移行することもできます。Oracle Streamsには、アドバンスト・キューやオブジェクト型などに対するデータ型の制限があり、追加の管理作業が必要となります。

関連項目:

- トランスポータブル表領域の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Data Guardまたはトランスポータブル・データベースを使用した移行の詳細は、『Oracle Database高可用性概要』を参照してください。

- Oracle Streamsを使用した移行の詳細は、『Oracle Streams概要および管理』を参照してください。

- 第7章「Oracle Data Pumpを使用したデータの移動」

Oracle Streamsのダウンストリーム取得を使用しているデータベースのアップグレードの概要

Oracle Streamsレプリケーション環境では、ソース・データベース以外のデータベースで取得プロセスを実行することをダウンストリーム取得といいます。このような環境にあるデータベースをアップグレードする場合は、ソース・データベースをアップグレードする前に、ダウンストリーム取得を使用しているデータベースをアップグレードします。この順番でデータベースをアップグレードすることにより、ソース・データベースをアップグレードした後もダウンストリーム取得データベースを引き続き機能させることができます。

関連項目:
ダウンストリーム取得の詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Database Vaultを使用しているデータベースのアップグレードの概要

Oracle Databaseリリース10.2または11.1からアップグレードするとき、現在のOracleホームでOracle Database Vaultを有効にしている場合は、新しいリリース11.2ソフトウェアがインストールされるターゲットのOracleホームでOracle Database Vaultを無効にする必要があります。データベースをアップグレードする前に、これを実行する必要があります。アップグレードが完了してから、再度Oracle Database Vaultを有効にします。

Database Upgrade Assistant (DBUA)を使用するとき、「次のOracleホームのDatabase Vaultオプションが有効です: C:\oracle\cdctest\product\11.2.0\dbhome_1。アップグレードの前にこのオプションを無効にする必要があります。」などの警告が表示される場合は、新しく11.2ソフトウェアをインストールするターゲットOracleホームでOracle Database Vaultを無効にする必要があります。

関連項目:
Oracle Database Vaultを無効にする手順は、『Oracle Database Vault管理者ガイド』を参照してください。

アップグレードする場合の新しいOracle Databaseソフトウェアのインストール

Oracle Databaseのアップグレードを実行する前に、新しいOracle Databaseリリースのソフトウェアをインストールする必要があります。新しいOracle Database 11gリリース2(11.2)のインストール手順を実行すると、Oracleソフトウェアが新しいOracleホームにインストールされます。これはアウトオブプレース・アップグレードと呼ばれ、パッチ・セットが常にインプレースでインストールされるOracle Databaseの以前のリリースのパッチ・セット・リリースとは異なります、アップグレード処理の停止時間を最小限に抑え、新しいバイナリとソフトウェア・ライブラリの整合性を保証するために、この一連の手順に従うことを強くお薦めします。

重要:
ソースおよびターゲットのOracleホームが別のユーザーによって所有されているときは、DBUAを使用してデータベースをアップグレードすることはできません。これを行うと、エラーPRKH-1014が返されます。ソースおよびターゲットのデータベースの所有者が同じであることを確認するか、または「Oracle Databaseの手動でのアップグレード」で説明されている手動の手順を実行します。

このリリースの新しいOracle Databaseソフトウェアをインストールするには、次の手順を実行します。

1. Oracle RACデータベースをアップグレードする場合は、記述されている順番で次の手順を実行する必要があります。

1. 「Oracle ClusterwareおよびOracle ASMインスタンスのアップグレードに関する考慮点」の説明に従って、最初にOracle Clusterwareをアップグレードします。

注意:
Oracle RAC以外のデータベースをアップグレードする場合は、DBUAを実行する前にOracle Net Configuration Assistant(NETCA)を実行する必要があります。「Oracle9iからアップグレードする場合のリスナーの構成」を参照してください。Oracle RACデータベースをOracle Clusterwareアップグレードの一部としてアップグレードする場合は、OUIによって自動的にNETCAが実行され、ネットワーク・リスナーがアップグレードされます。したがって、NETCAを手動で実行する必要はありません。

2. Oracle Grid Infrastructureのインストール・メディアをマウントします。

3. アップグレードを行う各ノードでオペレーティング・システムの前提条件チェックを実行し、ノードがOracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)に必要なシステムの前提条件を満たしていることを確認します。

4. 必要に応じて、旧リリースのOracle ClusterwareまたはOracle Cluster Ready Servicesソフトウェアが最新のパッチ・バージョンになるように、パッチのアップグレードを実行します。

5. Oracle Grid Infrastructureインストールの所有者にするユーザーでログインしていることを確認し、Oracle Grid Infrastructureのインストールを実行します。インストーラの要求に応じて情報を入力します。

6. プロンプトが表示されたら、別のターミナル・セッションを開き、rootでログインしてroot.shを実行します。

関連項目:

- 『Oracle Grid Infrastructureインストレーション・ガイド』

- 『Oracle Real Application Clustersインストレーション・ガイド』

2. Oracle Clusterwareをアップグレードした後、Oracleのオペレーティング・システム固有のマニュアルを参照して、Oracle Databaseソフトウェアのインストールの準備を行い、Oracle Universal Installerを起動します。

- DBUAを使用してアップグレードを行う前に、アップグレード前情報ツールを実行して、DBUAでチェックされる項目のタイプを確認しておくことをお薦めします。(「アップグレード前情報ツールの使用」を参照してください。)インストールの完了後、単独でDBUAを実行できます。

- Oracle Label Security、Oracle Database Vault、またはこれらの両方を使用する場合、「データベース・エディションの選択」ページで「Enterprise Edition」を選択し、「オプションの選択」をクリックして、コンポーネント・リストから一方または両方のコンポーネントを有効にします。詳細は、『Oracle Label Security管理者ガイド』および『Oracle Database Vault管理者ガイド』を参照してください。

Oracle Databaseソフトウェアのインストールが正常に完了したら、「終了」ボタンをクリックしてOracle Universal Installerを閉じます。

関連項目:

- 「Oracle9iからアップグレードする場合のリスナーの構成」

- 「Linux、UNIXおよびWindowsでのDatabase Upgrade Assistantを使用したアップグレード」

- 「単一インスタンスOracle Databaseのインプレース・アップグレードの実行」

- 「Oracle RACデータベースのインプレース・アップグレードの実行」

最新のパッチ・セット更新および必須のパッチの概要

Oracle Database 11gリリース2(11.2)のソフトウェアには、Oracle Databaseのすべての最新パッチと更新を含む完全なリリースが含まれます。このリリースのアップグレード処理に進む前に、パッチ・セットの更新を確認する必要はありません。ただし、データベース管理の一部として、パッチおよびパッチ・セットの更新を定期的に確認することをお薦めします。

関連項目:

- 『Oracle Universal InstallerおよびOPatchユーザーズ・ガイド』

- My Oracle Support(https://support.oracle.com)のNote ID 730365.1「Oracle Database Upgrade Path Reference List」(ダウンロード情報、パッチ番号および他のノートへのリンクが示された、最も入手しやすいOracle Databaseリリースのアップグレード・リファレンス・リストが含まれています)

アップグレード前情報ツールの使用

Oracle Database 11gリリース2(11.2)のソフトウェアおよび必須パッチをインストールした後、新しいリリースにアップグレードする前にデータベースを分析することをお薦めします。これは、アップグレード対象のデータベースの環境からアップグレード前情報ツールを実行することによって行います。アップグレード前情報ツールは、Oracle Database 11gリリース2(11.2)ソフトウェアに付属するSQLスクリプトです。これは手動でアップグレードを行う際に必要な手順であり、この手順を実行しないと、catupgrd.sqlスクリプトはエラーを発生して終了します。DBUAを使用してアップグレードを行う場合も、アップグレード前情報ツールを実行して、DBUAでチェックされる項目を確認しておくことをお薦めします。

次の項では、アップグレード前情報ツールに関する追加情報を説明します。

- アップグレード前情報ツールの出力の概要

- アップグレード前情報ツールの各種の警告

関連項目:
My Oracle Support(https://support.oracle.com)で参照可能なNote 884522.1「How to Download and Run Oracle's Database Pre-Upgrade Utility」(アップグレード前情報ツールの最新バージョンが含まれます)Note 884522.1で入手可能なこのスクリプトの最新バージョンを使用することを強くお薦めします。

アップグレード前情報ツールを実行するには、次の手順を実行します。

1. アップグレード対象データベースの環境の所有者としてシステムにログインします。

重要:
アップグレード対象のデータベースの環境にアップグレード前情報ツールをコピーして、その環境から実行する必要があります。

2. SQL*Plusを起動します。

3. SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

4. 後で分析するために、結果をログ・ファイルにスプールするようにシステムを設定します。

SQL> SPOOL upgrade_info.log

5. アップグレード前情報ツールの実行

SQL> @$11g_ORACLE_HOME/rdbms/admin/utlu112i.sql

6. スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

アップグレード前情報ツールの出力内容を、upgrade_info.logで確認します。

注意:
Oracle interMediaは、Oracle Database 11gリリース1(11.1)ではOracle Multimediaになりました。

アップグレード前情報ツールの出力の概要

アップグレード前情報ツールでは、データベースで発生する可能性のあるアップグレードの問題に関する警告が表示されます。例3-1の出力は、Oracle Database 11gリリース2(11.2)のソフトウェアをインストールした後にアップグレード前情報ツールの実行によって生成されたレポートを示しています。ツールによって表示される警告以外に、アップグレードの実行前にアップグレード前情報ツールの出力に示されているエラーに対処する必要があります。

無効なオブジェクトおよび無効なコンポーネントについては、WARNINGでマーキングされる無効なオブジェクトおよびコンポーネントの数を最小限に抑える手段として、アップグレードを開始する前にutlrp.sqlを実行することをお薦めします。

次の項では、アップグレード前情報ツールの出力例を示し、出力の各セクションについて説明します。

- Databaseセクションの内容

- Tablespacesセクションの内容

- Rollback Segmentsセクションの内容

- Flashbackセクションの内容

- Update Parametersセクションの内容

- Renamed Parametersセクションの内容

- Obsolete/Deprecated Parametersセクションの内容

- Componentsセクションの内容

- Miscellaneous Warningsセクションの内容

- Recommendationsセクションの内容

重要:

データベースにリリース10gのDMSYSスキーマが存在することに関する警告が表示された場合、アップグレードに進む前にDMSYSスキーマを削除する必要があります。手順については、『Oracle Data Mining管理者ガイド』を参照してください。

例3-1 アップグレード前情報ツールの出力例

Oracle Database 11.2 Pre-Upgrade Information Tool 07-12-2011 12:51:34
Script Version: 11.2.0.3.0 Build: 001
.
**********************************************************************
Database:
**********************************************************************
--> name:          O112
--> version:       11.2.0.1.0
--> compatible:    11.2.0.0.0
--> blocksize:     8192
--> platform:      Linux x86 64-bit
--> timezone file: V11
.
**********************************************************************
Tablespaces: [make adjustments in the current environment]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
.... minimum required size: 701 MB
--> SYSAUX tablespace is adequate for the upgrade.
.... minimum required size: 453 MB
--> UNDOTBS1 tablespace is adequate for the upgrade.
.... minimum required size: 400 MB
--> TEMP tablespace is adequate for the upgrade.
.... minimum required size: 60 MB
--> EXAMPLE tablespace is adequate for the upgrade.
.... minimum required size: 78 MB
.
**********************************************************************
Flashback: OFF
**********************************************************************
**********************************************************************
Update Parameters: [Update Oracle Database 11.2 init.ora or spfile]
Note: Pre-upgrade tool was run on a lower version 64-bit database.
**********************************************************************
--> If Target Oracle is 32-Bit, refer here for Update Parameters:
-- No update parameter changes are required.
.

--> If Target Oracle is 64-Bit, refer here for Update Parameters:
-- No update parameter changes are required.
.
**********************************************************************
Renamed Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
-- No renamed parameters found. No changes are required.
.
**********************************************************************
Obsolete/Deprecated Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
-- No obsolete parameters found. No changes are required
.

**********************************************************************
Components: [The following database components will be upgraded or installed]
**********************************************************************
--> Oracle Catalog Views         [upgrade]  VALID
--> Oracle Packages and Types    [upgrade]  VALID
--> JServer JAVA Virtual Machine [upgrade]  VALID
--> Oracle XDK for Java          [upgrade]  VALID
--> Oracle Workspace Manager     [upgrade]  VALID
--> OLAP Analytic Workspace      [upgrade]  VALID
--> OLAP Catalog                 [upgrade]  VALID
--> Oracle Label Security        [upgrade]  VALID
--> Oracle Database Vault        [upgrade]  VALID
... To successfully upgrade Oracle Database Vault, choose
... 'Select Options' in Oracle installer and then select
... Oracle Label Security.
--> EM Repository                [upgrade]  VALID
--> Oracle Text                  [upgrade]  VALID
--> Oracle XML Database          [upgrade]  VALID
--> Oracle Java Packages         [upgrade]  VALID
--> Oracle interMedia            [upgrade]  VALID
--> Spatial                      [upgrade]  VALID
--> Expression Filter            [upgrade]  VALID
--> Rule Manager                 [upgrade]  VALID
--> Oracle Application Express   [upgrade]  VALID
... APEX will only be upgraded if the version of APEX in
... the target Oracle home is higher than the current one.
--> Oracle OLAP API              [upgrade]  VALID
.
**********************************************************************
Miscellaneous Warnings
**********************************************************************
WARNING: --> Database is using a timezone file older than version 14.
.... After the release migration, it is recommended that DBMS_DST package
.... be used to upgrade the 11.2.0.1.0 database timezone version
.... to the latest version which comes with the new release.
WARNING: --> Database contains schemas with objects dependent on DBMS_LDAP package.
.... Refer to the 11g Upgrade Guide for instructions to configure Network ACLs.
.... USER APEX_030200 has dependent objects.
.
**********************************************************************
Recommendations
**********************************************************************
Oracle recommends gathering dictionary statistics prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:

EXECUTE dbms_stats.gather_dictionary_stats;

**********************************************************************
Oracle recommends reviewing any defined events prior to upgrading.

To view existing non-default events execute the following commands
while connected AS SYSDBA:
Events:
SELECT (translate(value,chr(13)||chr(10),' ')) FROM sys.v$parameter2
WHERE  UPPER(name) ='EVENT' AND  isdefault='FALSE'

Trace Events:
SELECT (translate(value,chr(13)||chr(10),' ')) from sys.v$parameter2
WHERE UPPER(name) = '_TRACE_EVENTS' AND isdefault='FALSE'

Changes will need to be made in the init.ora or spfile.

**********************************************************************

Databaseセクションの内容

Databaseセクションには、データベース名、リリース番号(バージョン)、互換性レベル、ブロックサイズ、OSプラットフォーム、タイムゾーン・ファイルなど、現行のデータベースに関するグローバル・データベース情報が表示されます。データベースをアップグレードする前にCOMPATIBLE初期化パラメータを調整する必要がある場合は、警告が表示されます。

関連項目:
COMPATIBLE初期化パラメータの設定の詳細は、「COMPATIBLE初期化パラメータの設定」を参照してください。

Tablespacesセクションの内容

Tablespacesセクションには、現行のデータベース内の表領域のリストが表示されます。各表領域に対して、表領域名および最低限必要なサイズが表示されます。また、表領域がアップグレードに適切かどうかを示すメッセージが各表領域の横に表示されます。最低限必要なサイズを満たしていない場合は、ツールによって推奨される調整を行う必要があります。

SQLスクリプトおよびユーティリティを使用して手動でアップグレードする場合は、現行のデータベース内の十分な空き領域のない表領域に領域を追加する必要があります。この表領域の調整は、データベースをアップグレードする前に行う必要があります。これらの作業の一部は、DBUAによって自動的に実行されます。

Rollback Segmentsセクションの内容

Rollback Segmentsセクションには、SYSTEM表領域のロールバック・セグメントのステータスおよびアップグレードの実行前に行う必要がある調整に関する警告が表示されます。このセクションは、ロールバック・セグメントが存在する場合のみ表示されます。

Flashbackセクションの内容

Flashbackセクションには、フラッシュバックがオンまたはオフのどちらであるか、および増やす必要があるプール・サイズとキャッシュ・サイズに関する警告が表示されます。調整が必要なundo_managementのステータスも表示されます。ALTER SYSTEM SETコマンドを実行すると、プール・サイズとデータベース・キャッシュ・サイズを変更できます。

たとえば、次のコマンドを実行して、java_pool_sizeを推奨サイズに設定します。

SQL> ALTER SYSTEM SET java_pool_size='nnnM' SCOPE=spfile;

他の設定の変更も同様に行うことができます。

Update Parametersセクションの内容

Update Parametersセクションには、データベースのアップグレード前に調整する必要がある、現行のデータベースのパラメータ・ファイル(init.oraまたはspfile)内にある初期化パラメータのリストが表示されます。パラメータ・ファイルの調整は、ファイルを新しいOracle Database 11gリリースにコピーした後に行う必要があります。

Oracle ASMディスク・グループを使用している場合は、ディスク・グループのデータベース互換性属性が、init.oraで設定されている互換性パラメータと同じであることを確認する必要があります。

関連項目:
このOracle Database 11gリリースでの初期化パラメータの変更に関する詳細は、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

Renamed Parametersセクションの内容

Renamed Parametersセクションには、現行のデータベースのパラメータ・ファイル内の初期化パラメータのうち、新しいOracle Database 11gリリースで名前が変更された初期化パラメータのリストが表示されます。新しいデフォルト値も表示されます。

関連項目:
新しいOracle Database 11gリリースで名前が変更された初期化パラメータについては、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

Obsolete/Deprecated Parametersセクションの内容

Obsolete/Deprecated Parametersセクションには、現行のデータベースのパラメータ・ファイル内の初期化パラメータのうち、新しいOracle Database 11gリリースで廃止または非推奨になった初期化パラメータのリストが表示されます。廃止された初期化パラメータは、データベースをアップグレードする前にパラメータ・ファイルから削除する必要があります。

関連項目:
新しいOracle Database 11gリリースで廃止および非推奨になった初期化パラメータのリストは、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

Componentsセクションの内容

Componentsセクションには、現行のデータベースを新しいOracle Database 11gリリースにアップグレードするときに、アップグレードまたはインストールされるデータベース・コンポーネントのリストが表示されます。ソフトウェア・コンポーネントは、特定のデータベース機能(Oracle Text、Oracle Javaパッケージ、Oracle RACなど)を提供する構築済のコード・ライブラリです。

Miscellaneous Warningsセクションの内容

Miscellaneous Warningsセクションには、アップグレード前またはアップグレード後に注意する必要がある特定の状況に関する警告が表示されます。たとえば、データベースでアップグレードに必要なバージョンより古いバージョンのタイムゾーン・ファイルが使用されている場合、必要な処理を示す警告が表示されます。

関連項目:
「アップグレード前情報ツールの各種の警告」

Recommendationsセクションの内容

Recommendationsセクションには、新しいOracle Database 11gリリースにアップグレードする前に実行する必要がある推奨SQL文やコマンドなどのOracle推奨事項が表示されます。

アップグレード前情報ツールの各種の警告

新しいOracle Database 11gリリースへのアップグレードを行う前に、アップグレード前情報ツールによって表示された情報および警告の分析を行うことをお薦めします。次の項では、警告および適切な対処法について説明します。

- 以前のリリースからのCONNECTロールの更新

- アクセス制御リストおよびネットワーク・ユーティリティ・パッケージの管理と更新

- 以前のリリースからのダウングレードおよびデータベース・リンクについて

- TIMESTAMP WITH TIME ZONEデータ型に関する警告の概要

- オプティマイザ統計を収集するための停止時間の短縮(オプション)

- 無効なオブジェクトの識別

- emdwgrdユーティリティを使用したデータベースの制御ファイルおよびデータの保存

- マテリアライズド・ビューのリフレッシュ完了の確認

- メディア・リカバリを必要とするファイルがないことの確認

- バックアップ・モードのファイルがないことの確認

- 未処理の分散トランザクションの解決

- スタンバイ・データベースとプライマリ・データベースの同期化

- データベースのごみ箱のパージ

以前のリリースからのCONNECTロールの更新

Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)から新しいOracle Database 11gリリースにアップグレードすると、CONNECTロールに含まれる権限はCREATE SESSION権限のみになります。以前のリリースでCONNECTロールに付与された他の権限は、アップグレード時に取り消されます。

データベース内でCONNECTロールを付与されているユーザーおよびロールを識別するには、次の手順を実行します。

1. 次の問合せを実行します。

SELECT grantee FROM dba_role_privs
WHERE granted_role = 'CONNECT' and
grantee NOT IN (
'SYS', 'OUTLN', 'SYSTEM', 'CTXSYS', 'DBSNMP',
'LOGSTDBY_ADMINISTRATOR', 'ORDSYS',
'ORDPLUGINS',  'OEM_MONITOR', 'WKSYS', 'WKPROXY',
'WK_TEST', 'WKUSER', 'MDSYS', 'LBACSYS', 'DMSYS',
'WMSYS', 'EXFSYS', 'SYSMAN', 'MDDATA',
'SI_INFORMTN_SCHEMA', 'XDB', 'ODM');

2. ユーザーまたはロールにCREATE SESSION以外の権限が必要な場合は、アップグレード前に特定の必要な権限を付与します。
Oracle提供のアップグレード・スクリプトによって、Oracleで指定されたユーザーの権限が調整されます。

アクセス制御リストおよびネットワーク・ユーティリティ・パッケージの管理と更新

新しいOracle Database 11gリリースには、Oracle XML DBを使用するUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。これらのパッケージのいずれかを使用するアプリケーションがある場合は、Oracle XML DBが現在インストールされていなければインストールする必要があります。

ACLおよびネットワーク・ユーティリティ・パッケージを更新するには、次の手順を実行します。

1. Oracle XML DBが現在インストールされていない場合は、これをインストールします。

関連項目:
『Oracle XML DB開発者ガイド』

2. DBMS_LDAP PL/SQLパッケージおよびHttpUriType型の新しい動作が有効になるには、新しいOracle Databaseリリース11.2にアップグレードした後にアクセス制御リスト(ACL)を作成または更新する必要があります。
たとえば、アプリケーションがDBMS_LDAPパッケージに依存している場合は、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」が発生する可能性があります。ログイン中のユーザーは、DBMS_LDAP.initで指定されたホストおよびポートのconnect権限を持っている必要があります。

3. Oracle XML DBがアップグレード対象のデータベースにインストールされているためにUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびUTL_INADDRパッケージのいずれかまたはすべてがインストールされている場合は、これらのパッケージが新しいリリースに対応した最新バージョンになるように、アップグレードの実行後にこれらのパッケージを再インストールする必要がある場合があります。

関連項目:
『Oracle Databaseセキュリティ・ガイド』のPL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理に関する説明および「依存性の評価およびネットワーク・ユーティリティ・パッケージのACLの追加」

依存性の評価およびネットワーク・ユーティリティ・パッケージのACLの追加

新しいOracle Database 11gリリースにアップグレードした後は、ネットワーク・ユーティリティ・パッケージの依存性を評価し、適切なアクセス制御リスト(ACL)を追加することによってアクセスを提供する必要がある場合があります。

アクセスのステータスを確認し、ネットワーク・ユーティリティ・パッケージのACLを追加するには、次の手順を実行します。

1. 「アップグレード前情報ツールの使用」の説明に従って、アップグレード前情報ツールを実行します。

2. アップグレード前情報ツールの出力(upgrade_info.log)で、次のようなメッセージがないかを確認します。

WARNING: --> Database contains schemas with objects dependent on network packages.
.... Refer to the 11g Upgrade Guide for instructions to configure Network ACLs.
.... USER WKSYS has dependent objects.
.... USER SYSMAN has dependent objects.
.... USER FLOWS_010600 has dependent objects.
.

3. DBA_DEPENDENCIESビューを問い合せて、依存性の詳細を取得します。次に例を示します。

SELECT * FROM DBA_DEPENDENCIES
WHERE referenced_name IN ('UTL_TCP','UTL_SMTP','UTL_MAIL','UTL_HTTP','UTL_INADDR','DBMS_LDAP')
AND owner NOT IN ('SYS','PUBLIC','ORDPLUGINS');

4. テスト環境で使用できるようにアップグレード後のスクリプトを準備します。これによって、新しいアクセス制御がアップグレード・テストの一部に含まれます。
これらのパッケージが以前のリリースと同様に動作するようにデータベースのネットワーク・アクセス制御リスト(ACL)を構成する場合は、「Oracle Databaseのアップグレード後の外部ネットワーク・サービスへのファイングレイン・アクセスの構成」に示されているスクリプトの例を参照してください。このスクリプトには、DBMS_NETWORK_ACL_ADMINパッケージを使用してアクセス制御リストに対して権限の作成、割当ておよび追加を行う方法が示されています。

5. アップグレードが完了した後、特定の必要な権限を付与する必要があります。アクセス権は、元のデータベースでの使用方法に基づいて決定します。

以前のリリースからのダウングレードおよびデータベース・リンクについて

この情報は、アップグレードの実行後に元のデータベース・リリースにダウングレードする必要がある場合にのみ重要となります。Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)から新しいOracle Database 11gリリースにアップグレードするときに、データベース・リンクのすべてのパスワードが暗号化されます。

- 元のリリースにダウングレードするには、ダウングレードする前に、暗号化されたパスワードが指定されたすべてのデータベース・リンクを削除する必要があります。したがって、ダウングレードしたデータベースにはデータベース・リンクは存在しません。

- Oracle Data Pumpのデータベースの全体エクスポートをINCLUDE=DBLINKとともに使用して、ダウングレードするデータベースへのインポートに適したダンプ・ファイルに、すべてのデータベース・リンクをエクスポートします。その後、このダンプ・ファイルは、ダウングレード後にデータベース・リンクを置き換えるために使用できます。

- 新しく作成するデータベース・リンク(新しいリリースを実行中に作成する可能性があるデータベース・リンク)のパスワードを確認します。以前のリリース11.1にダウングレードした後でデータベース・リンク・パスワードをリセットする必要があるため、データベース・リンク・パスワードが必要です。

TIMESTAMP WITH TIME ZONEデータ型に関する警告の概要

Oracle Database 11gリリース2(11.2)に付属のタイムゾーン・ファイルは更新され、一部のタイムゾーン地域の変換ルールに対して行われた変更が反映されています。これらの変更は、TIMESTAMP WITH TIME ZONEデータ型の既存のデータに影響する場合があります。

Oracle Database 11gリリース2(11.2)では、以前のリリースと比較してタイムゾーンの動作が大きく変更されました。データベースをアップグレードする前に、最新のタイムゾーン・ファイルを取得する必要があります。アップグレード中のデータベースのタイムゾーン・ファイルのバージョンが、新しい11.2リリースに対して使用可能なタイムゾーン・ファイルの最新バージョンではない場合は、アップグレード前情報ツールによって、警告が表示されて続行方法が説明されます。表3-1は、警告と、タイムゾーン・ファイルのバージョンの不一致を解決する方法の概要を示しています。

注意:

タイムゾーン・ファイルのバージョンが一致していない場合、データベースに格納されているTIMESTAMP WITH TIME ZONE型のデータは、アップグレード中に破損する可能性があります。

表3-1 タイムゾーン・ファイルのバージョンの修正を行う場合の選択肢

アップグレード中のデータベースのタイムゾーン・バージョン

タイムゾーン・ファイルの修正方法

新しいデータベース・リリースに含まれている最新バージョンより前のバージョンの場合、アップグレード前情報ツールには「Database is using a time zone file older than version n」と表示されます。

データベースのアップグレードの完了後

DBMS_DST PL/SQLパッケージを使用して、『Oracle Databaseグローバリゼーション・サポート・ガイド』のタイムゾーン・ファイルおよびTIMESTAMP WITH TIME ZONEデータのアップグレード手順に関する説明に従ってください。

新しいデータベース・リリースに含まれているバージョンより新しいバージョンの場合、アップグレード前情報ツールには、「Database is using a time zone file greater than version n.」と表示されます。

データベースのアップグレードの開始前

アップグレード対象のデータベースで現在使用されているタイムゾーン・ファイルと同じバージョンを使用して、新しいOracleホームにパッチ(RDBMS DSTパッチ)を適用する必要があります。適用しない場合、アップグレードは失敗します。

使用しているタイムゾーン・ファイルのバージョンに適したパッチをOracleホームに適用する必要があります。アップグレードする各データベースにパッチを適用します。適用しない場合、データベースをアップグレードすることなくアップグレード・スクリプトが終了します。

関連項目:

- My Oracle Support(https://support.oracle.com)のSupport Note「Updated DST Transitions and New Time Zones in Oracle Time Zone File Patches」(ID 412160.1)

- タイムゾーンのアップグレードの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

オプティマイザ統計を収集するための停止時間の短縮(オプション)

統計が存在しないディクショナリ表のオプティマイザ統計は、新しいOracle Database 11gリリースへのアップグレード時に収集されます。この統計収集処理は、多数のディクショナリ表が含まれているデータベースでは時間がかかる場合がありますが、統計が存在しないか、またはアップグレード時に大きく変更されるディクショナリ表に対してのみ行われます。

統計の収集時に発生する停止時間を短縮するには、次の手順を実行します。

- データベースを実際にアップグレードする前に統計を収集します。これらの統計の収集にはDBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用することをお薦めします。たとえば、次のSQL文を入力できます。

EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

注意:
Oracle9iリリース2(9.2)を使用している場合は、DBMS_STATS.GATHER_SCHEMA_STATSプロシージャを使用して統計を収集する必要があります。これは、このマニュアルの付録Bに示すスクリプトを実行して行うことができます。

オプティマイザ統計に使用されるシステム・コンポーネントおよびスキーマ

表3-2に、アップグレード時に統計収集で確認されるシステム・コンポーネントおよびスキーマを示します。

表3-2 システム・コンポーネントおよびスキーマに対する統計収集

コンポーネント名

スキーマ

JServer JAVA Virtual Machine

SYS

OLAPアナリティック・ワークスペース

SYS

Oracle Database Catalog Views

SYS

Oracle Database JAVA Packages

SYS

Oracle Database Packages and Types

SYS、DBSNMP、OUTLN、SYSTEM、DIP

Oracle Database Vault

DVSYS

Oracle Enterprise Manager

SYSMAN

Oracle Expression Filter

EXFSYS

Oracle Multimedia

ORDSYS、ORDPLUGINS、SI_INFORMTN_SCHEMA

Oracle Label Security

LBACSYS

Oracle OLAP API

SYS

Oracle Spatial

MDSYS、MDDATA

Oracle Text

CTXSYS

Oracle Workspace Manager

WMSYS

Oracle XDK

SYS

Oracle XML Database

XDB

無効なオブジェクトの識別

データベースのアップグレード前に検出された無効なSYS/SYSTEMオブジェクトは、registry$sys_inv_objsという名前の表に格納されます。データベースのアップグレード前に検出されたSYS/SYSTEM以外の無効なオブジェクトは、registry$nonsys_inv_objsに格納されます。

アップグレードが原因で新しく無効になったオブジェクトを識別するには、次の手順を実行します。

- アップグレード後に、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行します。

emdwgrdユーティリティを使用したデータベースの制御ファイルおよびデータの保存

新しいOracle Database 11gリリースにアップグレードした後でOracle Enterprise Manager Database Controlをダウングレードする場合は、データベースをアップグレードする前にデータベースの制御ファイルおよびデータを保存する必要があります。データベースをアップグレードする前にデータベースの制御ファイルとデータのコピーを保存するためのemdwgrdユーティリティが提供されています。

emdwgrdユーティリティは、新しいOracle Database 11gリリースのORACLE_HOME/binディレクトリにあります。emdwgrdユーティリティは、LinuxとUNIX用のemdwgrdとemdwgrd.plおよびWindows用のemdwgrd.batとemdwgrd.plで構成されています。ユーティリティを実行する前に、新しいOracle Database 11gリリースのソフトウェアをインストールして、新しいOracleホームからスクリプトを起動する必要があります。ただし、emdwgrdユーティリティでは、ORACLE_HOMEを古いOracleホームに設定する必要があります。

emdwgrdを使用してデータベースの制御ファイルとデータを保存するには、次の手順を実行します。

1. 新しいOracle Database 11gリリースのソフトウェアをインストールします。(インプレース・パッチ・セット・アップグレードでは、この手順は必要ありません。)

関連項目:
「アップグレードする場合の新しいOracle Databaseソフトウェアのインストール」

2. ORACLE_HOMEを古いOracleホームに設定します。(インプレース・パッチ・セット・アップグレードでは、この手順は必要ありません。)

3. ORACLE_SIDを、アップグレードするデータベースのSIDに設定します。

4. PATH、LD_LIBRARY_PATHおよびSHLIB_PATHが、アップグレードするデータベースのOracleホームを指すように設定します。

5. 新しいOracle Database 11gリリースのOracleホームに移動します。

6. 次のコマンドのいずれかを実行します。

- 単一インスタンスのデータベースの場合は、次のコマンドを実行します。このとき、old_SIDはアップグレードするデータベースのSIDで、save_directoryはデータベースの制御ファイルとデータの格納場所として選択した場所へのパスです。

emdwgrd -save -sid old_SID -path save_directory

注意:
このスクリプトは、LinuxおよびUNIXプラットフォーム場合、emdwgrd.shにあります。Windowsの場合、このスクリプトはemdwgrd.batにあります。

- データベースがOracle RACデータベースの場合は、クラスタ・ノード間のリモート・コピーが必要です。構成済のリモート・コピーを示す環境変数を定義します。次に例を示します。

setenv EM_REMCP /usr/bin/scp

続いて、次のsaveコマンドを実行します。

emdwgrd -save -cluster -sid old_SID -path save_directory

リリース10gのOracleホームが共有デバイス上にある場合は、前述のコマンドラインに-sharedを追加します。

7. アップグレードするデータベースのSYSパスワードを入力します。

注意:
データベースをアップグレードした後に、DBUAバックアップおよびリストアを使用して以前のOracle Enterprise Manager Database Control環境に戻すことも可能です。ただし、アップグレードしてからリストアするまでの間に蓄積されたユーザー・データは、すべて失われます。データベースの制御ファイルおよびデータを保存しておくことで、データベースとDatabase Controlの両方をダウングレードできるようになります。アップグレードしてからダウングレードするまでの間に蓄積されたデータベースの制御データはすべて失われますが、すべてのユーザー・データが保持されます。

マテリアライズド・ビューのリフレッシュ完了の確認

アップグレードする前に、すべてのマテリアライズド・ビューが完了するまで待機する必要があります。システムに問い合せて、進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを判断することができます。

進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを判断するには、次の手順を実行します。

- 次の問合せを実行します。

SQL> SELECT * FROM sys.obj$ o, sys.user$ u, sys.sum$ s
WHERE o.type# = 42 AND bitand(s.mflags, 8) = 8;

メディア・リカバリを必要とするファイルがないことの確認

データベースをアップグレードする前に、メディア・リカバリを必要とするファイルがないことを確認する必要があります。システムに問い合せてファイルのリストを取得し、必要に応じてこれらのファイルのリカバリを行うことができます。

メディア・リカバリを必要とするファイルのリストを取得するには、次の手順を実行します。

- 次の文を発行します。

SQL> SELECT * FROM v$recover_file;

関連項目:

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

- 『Oracle Databaseバックアップおよびリカバリ・リファレンス』の「ブロック・メディア・リカバリの実行」

バックアップ・モードのファイルがないことの確認

アップグレードの実行時にバックアップ・モードのファイルがあってはいけないため、バックアップが完了するまで待機する必要があります。システムに問い合せてバックアップ・モードのファイルのリストを表示してから、適切な対処(バックアップが完了するまで待機する、または必要のないバックアップを中止する)を行うことができます。

バックアップ・モードのファイルのリストを取得するには、次の手順を実行します。

- 次の文を発行します。

SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

未処理の分散トランザクションの解決

アップグレードを実行する前に、未処理の分散トランザクションを解決する必要があります。これを行うには、最初に問合せによって保留中のトランザクションを確認してから、トランザクションをコミットします。保留中のすべての分散トランザクションがコミットされるまで待機する必要があります。

未処理の分散トランザクションを解決するには、次の手順を実行します。

1. 次の文を発行します。

SQL> SELECT * FROM dba_2pc_pending;

2. 前の手順の問合せによって行が戻された場合は、次の文を発行します。

SQL> SELECT local_tran_id FROM dba_2pc_pending;
SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');
SQL> COMMIT;

スタンバイ・データベースとプライマリ・データベースの同期化

スタンバイ・データベースが存在する場合は、スタンバイ・データベースとプライマリ・データベースを同期化する必要があります。

スタンバイ・データベースが存在するかどうかを確認して同期化するには、次の手順を実行します。

1. 次の問合せを発行します。

SQL> SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1)
FROM v$parameter
WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';

2. 前の手順の問合せによって行が戻された場合は、スタンバイ・データベースとプライマリ・データベースを同期化します。

- プライマリ・データベースでの最後のログ・スイッチの後のすべてのログがスタンバイ・サーバーに転送されていることを確認します。

- NODELAYオプションを使用して、スタンバイ・データベースのリカバリを開始します。

データベースのごみ箱のパージ

アップグレード処理を開始する前に、データベースのごみ箱を空にしておく必要があります。PURGE文を使用すると、ごみ箱からアイテムおよびその関連オブジェクトを削除して、記憶域の領域を解放することができます。

データベースのごみ箱を空にするには、次の手順を実行します。

- 次のコマンドを発行します。

SQL> PURGE dba_recyclebin

注意:

アップグレード処理を行う際は、ORA-00600エラーの発生の回避とアップグレード時間の短縮のために、ごみ箱を空にしておく必要があります。

Oracle9iからアップグレードする場合のリスナーの構成

Oracle9iからのアップグレードで、Oracle9i リポジトリにリスナーが設定されていない場合は、DBUAを実行する前にOracle Net Configuration Assistantを実行し、listener.oraファイルを含む新しいOracle Database 11gデータベースのリスニング・プロトコルのアドレスおよびサービス情報を構成します。Oracle Database 11gデータベースには、新しいバージョンのリスナーが必要です。以前のバージョンのリスナーは、Oracle Database 11gデータベースでは使用できません。ただし、新しいバージョンのリスナーを以前のバージョンのOracle Databaseで使用することは可能です。

Oracle RACデータベースをアップグレードするには、次のアップグレード方法があります。

- DBUAを使用してOracle RACデータベースをアップグレードします(この方法では、古いOracleホームから、新しいOracle Grid Infrastructure 11gリリース2のホームに、自動的にリスナーが移行されます)。

注意:
Oracle Database 11gリリース2以上では、Oracle Grid Infrastructureホームでlsnrctlコマンドを使用してリスナーを管理する必要があります。以前のリリースのOracleホームの場所からlsnrctlコマンドを使用しないでください。

- Oracle9iからアップグレードする場合、またはDBUAを使用せずに手動でアップグレードする場合は、Oracle RACデータベースをアップグレードする前に、Oracle Net Configuration Assistantを実行します。
この方法には2つの手順が含まれます。まず、古いOracleホームからOracle Net Configuration Assistantを実行して、古いリスナーを削除します。次に、再度、新しいOracle Database 11gリリースのOracleホームからOracle Net Configuration Assistantを実行して、新しいリスナーを作成する必要があります。

古いリスナーは、新しいリスナーを作成する前に削除する必要があります。先に新しいOracleホームから新しいリスナーを作成しようとした場合に、古いリスナーのものと同じ名前およびポートを使用すると、Oracle Net Configuration Assistantからエラーが戻されます。

関連項目:
Oracle Net Configuration Assistantの使用方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

Linux、UNIXおよびWindowsでのDatabase Upgrade Assistantを使用したアップグレード

DBUA提供のGraphical User Interface(GUI)による指示に従ってデータベースをアップグレードすることも、ユーザー・インタフェースを表示しないサイレント・モードでDBUAを起動することもできます。次の項では、Database Upgrade Assistant(DBUA)を使用したデータベースのアップグレード処理について説明します。

- DBUAの使用に関する考慮点

- DBUAのGraphical User Interfaceの概要

- DBUAを使用したLinux、UNIXおよびWindowsシステムでのデータベースのアップグレード

- サイレント・モードのDBUAを使用したOracle Databaseのアップグレード

DBUAの使用に関する考慮点

- 重要: アップグレードを停止しても、データベースをリストアしない場合は、DBUAを再起動できません。そのかわりに、「Oracle Databaseの手動でのアップグレード」.の説明に従って、手動(コマンドライン)によるアップグレードを続行する必要があります。

- DBUAは、以前のOracle Database 11gパッチ・リリースからのアップグレードに加えて、Oracle RACデータベースおよびOracle Database単一インスタンス・データベースの両方のOracle Databaseメジャー・リリースからのアップグレードにも使用できます。パッチ・リリースをアップグレードする手順は、通常のアップグレードの手順と異なる点はありません。

- Oracle Net Configuration Assistantは、DBUAより前に実行する必要があります。「Oracle9iからアップグレードする場合のリスナーの構成」を参照してください。
既存のOracle Enterprise Manager Database Controlをアップグレードする場合、または新しいOracle Database 11gリリース用の新しいOracle Enterprise Manager Database Controlを構成する場合は、Oracle Enterprise Managerをアップグレードする前にリスナーを実行する必要があります。Oracle Enterprise Managerのアップグレードまたは構成が要求されていることがDBUAで検出されたものの、リスナーが実行中であることをDBUAで確認できない場合は、前述のいずれの場合でも、デフォルト・リスナーを起動するよう、DBUAから求められます。

- DBUAを使用してクラスタ・データベースをアップグレードする場合は、CLUSTER_DATABASE初期化パラメータがTRUEに設定されていることを確認する必要があります。

- データベース・インスタンスが実行されていない場合、DBUAでは、デフォルトの初期化パラメータ・ファイルを使用してインスタンスの起動が試行されます。これが失敗した場合、DBUAから正しい初期化パラメータ・ファイルの名前の指定またはインスタンスの起動を求められます。インスタンスが起動され、実行されている場合、DBUAはそのインスタンスに接続します。

- アップグレードを停止しても、データベースをリストアしない場合は、新しいOracle Database 11gのサーバーを使用してUPGRADEモードで既存のデータベースを起動するまで、DBUAを再起動できません。データベースをリストアしないかぎり、元のサーバーに戻ることはできません。
Oracle RACでは、アップグレードを終了したらDBUAを再実行できません。アップグレードを再実行する必要がある場合は、アップグレードするデータベースのリストアされたバックアップからDBUAを実行する必要があります。

- DBUAを使用せずに手動でデータベースをリストアする場合は、DBUAを起動する前にORACLE_HOME/cfgtoollogs/dbua/logs/ディレクトリにあるWelcome_SID.txtファイルを削除します。このファイルが存在すると、DBUAでは、この操作が再実行操作であると認識されます。

DBUAのGraphical User Interfaceの概要

Oracle Database 11gリリース2(11.2)のインストールで既存のデータベースのアップグレードを指定した場合は、自動的にDBUAが起動されます。ただし、既存のデータベースをアップグレードするように指定しなかった場合は、インストール完了後、DBUAを単独で起動できます。

アップグレードの実行中、DBUAによって、各コンポーネントのアップグレード処理の進行状況が表示されます。DBUAは、詳細なトレース・ログおよびログ・ファイルを書き込み、後で参照するための完全なHTMLレポートを作成します。セキュリティを強化するために、DBUAは、アップグレード後のデータベースで、新しいユーザー・アカウントを自動的にロックします。その後、DBUAは、新しいOracleホームへの新しい構成ファイル(パラメータ・ファイルおよびリスナー・ファイル)の作成へと進みます。

DBUAは、アップグレード前のこれらのすべての手順が完了するまで、アップグレードを開始しません。

関連項目:
「アップグレード前情報ツールの使用」

次の項では、DBUAに関する追加情報を説明しています。

- Oracle DBUAによって実行される確認

- Oracle DBUAによって起動されるアップグレード・スクリプト

Oracle DBUAによって実行される確認

DBUAでは、アップグレードの前に次の確認が行われます。

- 無効なユーザー・アカウントまたはロール

- 無効なデータ型または無効なオブジェクト

- サポートされないキャラクタ・セット

- ロールバック・セグメント、表領域、ディスクの空き領域などのリソースが十分にあること

- アップグレードに必要なSQLスクリプトの欠落

- リスナーが実行中であること(Oracle Enterprise Manager Database Controlのアップグレードまたは構成が要求された場合)

- Oracle DatabaseソフトウェアがDatabase Vaultオプションとリンクされているかどうか

注意:
Database Vaultが有効になっている場合は、アップグレードする前にDatabase Vaultを無効にするよう求めるエラーが、DBUAから戻されます。「Oracle Database Vaultを使用しているデータベースのアップグレードの概要」を参照してください。

Oracle DBUAによって起動されるアップグレード・スクリプト

アップグレード時、DBUAは、次に示すように、新しく必要な表領域を自動的に変更または作成し、適切なアップグレード・スクリプトを起動します。

- データファイルが自動拡張可能で、十分なディスク領域がある場合、DBUAはアップグレードを続行します。

- データファイルを自動拡張できない場合、ファイルの自動拡張を可能にするようにDBUAから求められます。

- 表領域が自動拡張可能で、MAXSIZE初期化パラメータに調整が必要な場合、DBUAは同じことを要求して、MAXSIZEパラメータを調整します。

- 拡張できるディスク容量がない場合、DBUAはユーザーに領域を作成(データファイルを追加)するよう要求します。DBUAは、ファイルの作成場所を指定できないため、新しいデータファイルの追加は行われません。

オプションで、DBUAは必要なすべてのファイルをバックアップします。

DBUAを使用したLinux、UNIXおよびWindowsシステムでのデータベースのアップグレード

DBUAのGraphical User Interfaceを使用してデータベースをアップグレードするには、次の手順を実行します。これらの手順は、「アップグレードする場合の新しいOracle Databaseソフトウェアのインストール」の説明に従って最新のデータベース・ソフトウェアがインストールされた新しいOracleホーム内から実行されます。

重要:

アップグレードを停止しても、データベースをリストアしない場合は、DBUAを再起動できません。そのかわりに、「Oracle Databaseの手動でのアップグレード」.の説明に従って、手動(コマンドライン)によるアップグレードを続行する必要があります。

Linux、UNIXおよびWindowsでDBUAを使用してデータベースをアップグレードするには、次の手順を実行します。

1. 新しいデータベース・ソフトウェアがインストールされたOracleホームからDBUAを起動します。

- LinuxまたはUNIXプラットフォームの場合は、Oracle Database 11gリリース2(11.2)のホームでシステム・プロンプトに次のコマンドを入力します。

dbua

注意:
通常、dbua実行可能ファイルは、ORACLE_HOME/binディレクトリにあります。

- Windowsオペレーティング・システムの場合は、「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Database Upgrade Assistant」の順に選択します。

DBUAの「ようこそ」画面が表示されます。

2. ヘルプが必要な場合、またはDBUAの詳細を参照する場合は、「ヘルプ」ボタンをクリックしてオンライン・ヘルプを開きます。
「次へ」をクリックします。

「データベースの選択」ページが表示され、アップグレード可能なデータベースがリストされます。

3. Oracle Database 11gリリース2(11.2)にアップグレードするデータベースを選択します。
一度に1つのデータベースのみを選択できます。アップグレードするデータベースが表示されない場合は、etcディレクトリにあるoratabファイルにそのデータベース名のエントリが存在することを確認してください。

SYSDBA権限を所有していないユーザー・アカウントからDBUAを実行している場合は、選択したデータベースに対するSYSDBA権限を有効にするユーザー名およびパスワードの接続情報を入力する必要があります。

「次へ」をクリックします。

DBUAによって、データベースの分析およびアップグレード前のチェックが実行され、必要に応じて警告が表示されます。次に、DBUAによるデータベースのチェックの例を示します。

- REDOログ・ファイルのサイズが4MB未満である。このようなファイルが検出された場合、DBUAでは、削除して新しいREDOログ・ファイルを作成するオプションが選択できます。

- 廃止されたか非推奨の初期化パラメータ。

DBUAでのチェックが終了すると、「アップグレード・オプション」画面が表示されます。

4. 「アップグレード・オプション」画面では、次のオプションを設定できます。
アップグレード終了時に無効なオブジェクトを再コンパイル

アップグレード完了後に、すべての無効なPL/SQLモジュールをDBUAで再コンパイルする場合は、「アップグレード終了時に無効なオブジェクトを再コンパイル」を選択します。

データベースをOracle Database 11gリリース2(11.2)にアップグレードすると、データベースの多くのPL/SQLモジュールが無効になります。その結果、INVALID状態のすべての既存のPL/SQLモジュール(パッケージ、プロシージャ、タイプなど)を再コンパイルする必要があります。

デフォルトでは、無効なPL/SQLモジュールは、使用時にOracle Databaseによって再コンパイルされます。モジュールの再コンパイルに時間がかかるため、新しくアップグレードしたデータベースを使用し始めたときに、パフォーマンスが低下する場合があります。

これらのパフォーマンスの問題を解決するには、アップグレードの終了時に「無効なオブジェクトの再コンパイル」を選択します。このオプションを選択すると、すべての無効なPL/SQLモジュールは、アップグレードの実行直後にDBUAによって再コンパイルされます。こうすることにより、新しくアップグレードしたデータベースを使用し始めたときにパフォーマンスの問題が発生することはなくなります。

注意:
「アップグレード終了時に無効なオブジェクトを再コンパイル」を選択すると、ORACLE_HOME/rdbms/adminディレクトリにあるutlrp.sqlスクリプトを実行した場合と同じ操作を行ったことになります。このスクリプトは、ストアドPL/SQLおよびJavaコードの再コンパイルに使用するスクリプトです。

データベースのすべての無効なPL/SQLモジュールを再コンパイルするタスクは非常に時間がかかり、データベースのアップグレードを完了する時間が長くなる場合があります。複数のCPUがある場合は、使用可能なCPUでパラレル処理を実行してこのタスクを行う時間を短縮できます。複数のCPUが使用可能な場合は、DBUAによって「無効なオブジェクトの再コンパイル」画面にセクションが自動的に追加され、使用可能なCPUの数が自動的に算出されます。

並列度

また、無効なPL/SQLモジュールの再コンパイルに使用されるパラレル・プロセスの数を示す、並列度の推奨値もDBUAにより提供されます。具体的には、DBUAにより並列度は使用可能なCPU数-1に設定されます。たとえば、3つのCPUが処理に使用できる場合、DBUAでは、「並列度」メニューから「2」を選択します。このデフォルト値は、「並列度」メニューから新規の値を選択して調整できます。

データベースのバックアップ

DBUAでデータベースをバックアップする場合は、「データベースのバックアップ」を選択します。

重要:

アップグレードを開始する前に、ご使用のデータベースをバックアップしてください。アップグレード中にエラーが発生した場合は、そのバックアップからデータベースをリストアすることが必要になる可能性があります。

DBUAを使用してデータベースのバックアップを作成する場合、「バックアップ・ディレクトリ」フィールドで指定したディレクトリにすべてのデータベース・ファイルのコピーが作成されます。このコールド・バックアップは、データベースの停止後、アップグレード・プロシージャの実行前にDBUAにより自動的に実行されます。コールド・バックアップではデータベース・ファイルを圧縮しません。また、バックアップ・ディレクトリは有効なファイル・システム・パスである必要があります。コールド・バックアップ・ファイルにはRAWデバイスは指定できません。

また、DBUAでは、指定したディレクトリにバッチ・ファイルが作成されます。このバッチ・ファイルは、データベース・ファイルのリストアに使用でき、名前は次のとおりです。

- Windowsオペレーティング・システムではdb_name_restore.bat

- LinuxまたはUNIXプラットフォームでは、db_name_restore.sh

DBUAをバックアップに使用しないことを選択した場合、Oracleでは、データベースは独自のバックアップ手順を使用してバックアップされていると想定されます。

注意:
DBUAではOracle ASMデータベースはバックアップされません。ユーザーが手動でバックアップする必要があります。

「次へ」をクリックします。

単一インスタンスのデータベースまたはOracle Express Edition(XE)をアップグレードする場合は、「データベース・ファイルの移動」画面が表示されます。Oracle Real Application Clustersのデータベースをアップグレードする場合は、「データベース・ファイルの移動」画面は表示されません。

5. 次のいずれかのオプションを選択します。

- 「アップグレードの一部としてデータベース・ファイルを移動しない」

- 「アップグレード中にデータベース・ファイルを移動」

データベース・ファイルの移動を選択した場合は、次のうちのいずれかを選択することも必要です。

- ファイル・システム
データベース・ファイルはホストのファイル・システムに移動されます。

- Oracle Automatic Storage Management(Oracle ASM)
データベース・ファイルはOracle ASMの記憶域に移動されますが、この記憶域は現在システム上に存在している必要があります。Oracle ASMインスタンスがない場合は、Oracle Grid InfrastructureホームからAutomatic Storage Management Configuration Assistant(ASMCA)を使用してインスタンスを作成し、DBUAを再起動できます。

関連項目:

- Oracle ASMのインストールおよび構成の詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

- 『Oracle Databaseストレージ管理者ガイド』のASM Configuration Assistantを使用したOracle ASMインスタンスの管理に関する説明

「次へ」をクリックします。

「リカバリおよび診断の場所」画面が表示されます。この画面では、データベースのフラッシュ・リカバリ領域を指定できます。

フラッシュ・リカバリ領域は、バックアップおよびリカバリに関連するファイルを格納するためのディスクの場所で、Oracleによって管理されます。フラッシュ・リカバリ領域を使用すると、データベース・リカバリ・プロセスのスピード、信頼性および管理性が大幅に向上するため、フラッシュ・リカバリ領域を構成することを強くお薦めします。「管理オプション」画面でローカル管理および日次バックアップを有効にした場合、フラッシュ・リカバリ領域の場所はEnterprise Managerでも使用されます。

手順5で「アップグレード中にデータベース・ファイルを移動」を選択した場合、またはOracle Express EditionデータベースをOracle Enterprise Editionにアップグレードしている場合は、フラッシュ・リカバリ領域を構成する必要があります。フラッシュ・リカバリ領域が現在構成されている場合は現在の設定が保持されますが、この値を上書きできる画面が表示されます。

6. 次のいずれかを実行します。

- デフォルトのフラッシュ・リカバリ領域の位置をそのまま使用する。

- 「フラッシュ・リカバリ領域」フィールドに、別の位置への完全なパスを入力する。

- 「参照」をクリックして、別のフラッシュ・リカバリ領域の位置を選択する。

次のいずれかを実行します。

- フラッシュ・リカバリ領域のデフォルト・サイズをそのまま使用する。

- 「フラッシュ・リカバリ領域のサイズ」フィールドに、別の値を入力する。

- 上向き矢印または下向き矢印をクリックして、フラッシュ・リカバリ領域のサイズを調整する。

関連項目:
フラッシュ・リカバリ領域の構成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

「次へ」をクリックします。

Enterprise Managerで監視中のデータベースが他にない場合は、「管理オプション」画面が表示されます。

「管理オプション」画面には、データベースをEnterprise Managerで管理できるように設定するオプションがあります。Enterprise Managerには、Oracle環境全体を管理するための集中管理ツールのみでなく、個々のデータベース・インスタンス(複数のデータベース、ホスト、アプリケーション・サーバー、その他のネットワーク・コンポーネントなど)を管理するためのWebベースの管理ツールが用意されています。

Oracle Enterprise Manager Grid Controlでデータベースを登録できるようにするには、ホスト・コンピュータ上で事前にOracle Enterprise Manager Agentを構成する必要があります。

7. Enterprise Managerを使用してデータベースを管理するように設定するには、「Enterprise Managerによるデータベースの構成」を選択してから次のいずれかのオプションを選択します。

- 集中管理用にGrid Controlに登録
このオプションを選択した場合は、「管理サービス」ドロップダウン・リストからOracle Management Serviceを選択することも必要です。DBUAを実行すると、ホスト・コンピュータにOracle Management Agentがインストールされているかどうかがチェックされます。Oracle Management Agentが見つからなかった場合、Grid Controlオプションは選択できません。

Oracle Databaseソフトウェアのインストールを終了すると、データベースは自動的にOracle Enterprise Manager Grid Control内の管理ターゲットとして使用可能になります。

- ローカル管理用にDatabase Controlを構成
Oracle環境を集中管理していない場合も、Enterprise Managerを使用してデータベースを管理できます。Oracle Databaseをインストールすると、Oracle Enterprise Manager Database Controlが自動的にインストールされ、インストール中の単一インスタンスまたはクラスタ・データベースを監視および管理するWebベース機能が提供されます。

指定した条件のメトリックがクリティカルしきい値または警告しきい値に達したときに、SYSMANユーザー(デフォルトのスーパー管理者およびManagement Repositoryのスキーマの所有者)で電子メール通知を受信するように設定する場合は、次の手順を実行します。

- 「アラート通知の有効化」を選択します。

- 通知に使用する電子メール・サーバーの名前を「送信メール(SMTP)サーバー」フィールドに入力します。

- SYSMANユーザーの電子メール・アドレスを「受信者の電子メール・アドレス」フィールドに入力します。

たとえば、Enterprise Managerは、ターゲットが停止した場合またはデータベースで領域使用率の問題が発生した場合に電子メールを送信できます。電子メール通知は、インストールするとすぐに有効になります。

最小の構成でデータベース全体をバックアップするためにOracle推奨のバックアップ計画を使用するには、次の手順を実行します。

- 「リカバリ領域への日次ディスク・バックアップの有効化」を選択します。

- 「バックアップ開始時間」フィールドに、開始時間を入力します。

- 「OSユーザー名」フィールドおよび「パスワード」フィールドに、ホスト資格証明を入力します。

「リカバリ領域への日次ディスク・バックアップの有効化」オプションを選択した場合は、Oracle Databaseのアップグレードが終了した直後にデータベースがバックアップされるように、Enterprise Managerが構成されます。Enterprise Managerでは、フラッシュ・リカバリ領域にデータベースがバックアップされます。後で、Enterprise Managerを使用してバックアップ計画をカスタマイズできます。

Windowsでは、バックアップ用に資格証明を入力する対象となるユーザーは、Windowsのローカル・セキュリティ・ポリシーでバッチ ジョブとしてログオン権限を付与されている必要があります。選択したユーザーがこの権限を持っていない場合、バックアップ・ジョブは失敗します。

「次へ」をクリックします。

「データベース資格証明」画面が表示されます。

8. 次のいずれかのオプションを選択します。

- 「別のパスワードを使用」
別のパスワードを使用することを選択した場合は、表内の各アカウントの「パスワード」および「パスワードの確認」列に、パスワードを入力する必要があります。

- 「すべてのアカウントに同じパスワードを使用」
同じパスワードを使用することを選択した場合は、「パスワード」および「パスワードの確認」フィールドにパスワードを入力する必要があります。

注意:
Oracle Database 11gリリース2(11.2)のデフォルトのセキュリティ設定が適用されている場合、新しいパスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

「次へ」をクリックします。

「サマリー」画面が表示されます。

9. アップグレードを開始する前に、アップグレードに関する次の情報が「サマリー」画面に表示されます。

- 名前、バージョン、および古いデータベースと新しいデータベースのOracleホーム

- データベースのバックアップ位置、使用可能な領域、および必要な領域

- 無視された警告

- アップグレード対象のデータベース・コンポーネント

- 初期化パラメータの変更

- データベース・ファイルの位置

- リスナー登録

関連項目:
アップグレード後のCOMPATIBLE初期化パラメータの設定の詳細は、「COMPATIBLE初期化パラメータの設定」を参照してください。

すべての指定内容を確認します。続いて、次のいずれかを実行します。

- 設定内容が間違っている場合は、その設定を修正できる画面が表示されるまで「戻る」をクリックします。

- すべて正しい場合は、「終了」をクリックします。

「進行」画面が表示され、DBUAでアップグレードが開始されます。

10. アップグレードが完了した後、「進行」画面に次のメッセージが表示されます。

Upgrade is complete. Click "OK" to see the results of the upgrade.

11. 「アップグレード結果」画面には、元のデータベースおよびアップグレードしたデータベースについての説明と、初期化パラメータに対して行われた変更が表示されます。この画面には、アップグレード後に様々なログ・ファイルが格納されるディレクトリも表示されます。これらのログ・ファイルを調べて、アップグレード処理の詳細を確認できます。

注意:
HTML版のアップグレード結果も、ログ・ファイル・ディレクトリに保存されます。

1. 「データベース・パスワードの構成」をクリックして、「パスワード管理」ダイアログ・ボックスを表示します。
「パスワード管理」ダイアログ・ボックスを使用して、データベースをアップグレードした後のユーザーのデフォルトのパスワードを変更できます。セキュリティ上の理由から、次のユーザーを除くすべてのユーザーがロックされます。

- SYS

- SYSTEM

Enterprise Managerで「ローカル管理」を有効にしている場合は、SYSMANおよびDBSNMPアカウントもロック解除されます。これらのアカウントによって、Enterprise Managerにデータベースへのアクセスが提供され、Enterprise Managerを使用して監視データを収集し、管理タスクを実行できるようになります。

Enterprise Managerで「集中管理」を有効にしている場合は、SYSおよびSYSTEMユーザー・アカウントに加えて、DBSNMPアカウントもロック解除されます。

注意:
データベースの不正な使用を防止するために、データベースをアップグレードした直後にすべてのユーザー・パスワードを変更することをお薦めします。
Oracle Database 11gリリース2(11.2)のデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

2. アップグレード結果に問題がある場合は、「データベースのリストア」をクリックします。
データベースのバックアップに使用した方法によって、「リストア」オプションでは、次のいずれかのタスクが実行されます。

- DBUAを使用してデータベースをバックアップした場合は、「リストア」をクリックすると、元のデータベースおよび元のデータベースの設定がバックアップからリストアされます。

- 独自のバックアップ・プロシージャを使用してデータベースをバックアップした場合は、元のデータベースの設定のみがリストアされます。データベース自体をリストアするには、独自のバックアップ・ユーティリティを使用して作成したバックアップをリストアする必要があります。

アップグレード結果に問題がない場合は、「終了」をクリックしてDBUAを終了し、新しくアップグレードしたデータベースを使用します。

1. DBUAによって、次のいずれかの方法でOracle Databaseのlistener.oraファイル内のアップグレードされたデータベースのSID_DESCエントリが変更されます。
単純な場合: 古いlistener.oraに次のSID_DESCエントリがあるとします。

...
(SID_DESC =
(SID_NAME = ORCL)
)
...

データベース名がSAL、ドメイン名がCOM、Oracleホームが/oracle/product/9.2の場合、次のエントリが追加されます。

...
(SID_DESC =
(GLOBAL_DBNAME = sal.com)
(ORACLE_HOME = /oracle/product/9.2)
(SID_NAME = SAL)
)
...

複雑な場合: 古いlistener.oraに次のSID_DESCエントリがあるとします。

...
(SID_DESC =
(GLOBAL_DBNAME = an_entry)
(SID_NAME = ORCL)
)
...

an_entryが移行されたデータベースのGLOBAL_DBNAMEと一致せず、データベース名がSAL、ドメイン名がCOM、Oracleホームが/oracle/product/9.2の場合、次のエントリが追加されます。

...
(SID_DESC =
(GLOBAL_DBNAME = sal.com)
(ORACLE_HOME = /oracle/product/9.2)
(SID_NAME = SAL)
)
...

このエントリは単純な場合のエントリと同じですが、DBUAでも初期化パラメータ・ファイルのSERVICE_NAMESパラメータにエントリan_entryが追加されます。したがって、DBUAでは次のようにSERVICE_NAMESパラメータが変更されます。

SERVICE_NAMES = sal.com, an_entry

2. DBUAによって、古いlistener.oraファイルからアップグレードされたデータベースのエントリが削除されます。

3. DBUAによって、新旧両方のOracle Database環境で、listener.oraファイルが再ロードされます。

12. >>2007年3月26日に行われたRavi PattabhiによるIOUGのプレゼンテーションのとおり、次の手順については、画面が表示されなくなったか、または同じ画面を説明する手順のリライト版に置き換えられたために削除されています。CBF(2007年3月30日)
作成するすべての新しいOracle Database 11gリリース1(11.1)データベースに自動的に追加されるSYSAUX表領域の属性を指定します。

関連項目:
SYSAUX表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

SYSAUX表領域の属性の多くは、自動的に設定され、変更できません。たとえば、SYSAUX表領域は、自動セグメント領域管理を使用するように設定されます。ただし、データ・ファイルの場所、SYSAUX表領域のデフォルト・サイズおよびその自動拡張属性を指定できます。

注意:
SYSAUX表領域の既存のデータ・ファイルを指定する場合、「既存ファイル名の再利用」を選択する必要があります。選択しない場合、DBUAからファイルが現在存在することが通知されます。

「次へ」をクリックします。

「無効なオブジェクトの再コンパイル」画面が表示されます。

13. Enterprise Managerアカウントのパスワードでデータベースを保護します。リストされたEnterprise Managerユーザー・アカウントのそれぞれに適用される単一のパスワードを設定するか、または各ユーザーに一意のパスワードを提供することによってアカウントのセキュリティを強化できます。
「次へ」をクリックします。

「リカバリ構成」画面が表示されます。

14. フラッシュ・リカバリ領域を指定し、アーカイブを有効にします。データベースを管理する場合、システム障害時にデータをリカバリできるようにデータベースを構成することが重要です。
フラッシュ・リカバリ領域を使用して、システム障害時に失われたデータをリカバリできます。「管理オプション」画面でローカル管理および日次バックアップを有効にした場合、この場所はEnterprise Managerでも使用されます。

「次へ」をクリックします。

「ネットワーク構成」画面が表示されます。

15. 「アップグレード操作」ページで、次のいずれかを実行します。

- Oracle ASMインスタンスのみをアップグレードするオプションを選択します。

- データベースをアップグレードするオプションを選択します。
データベースをアップグレードする方法を選択し、データベースでOracle ASMが使用されている場合は、DBUAからデータベースとともにOracle ASMインスタンスをアップグレードするかどうかを確認されます。データベースとOracle ASMは、別々のDBUAセッションで別々のOracleホームにアップグレードすることをお薦めします。

「次へ」をクリックします。

「データベース・インスタンスの選択」画面が表示されます。

16. 「デフォルトの動作の変更」画面に、以前のリリースからOracle Database 11gリリース1(11.1)で変更された動作がDBUAにより表示されます。初期化パラメータのデフォルト値が変更された場合もあります。その他の場合、現在のスクリプトまたはアプリケーションに影響を及ぼす可能性がある新しい動作や要件が導入されました。

17. 第4章「Oracle Databaseのアップグレード後の作業」に示す手順を実行します。

オプションでのインプレース・アップグレードの実行(同じOracleホームへ)

Oracle Database 11g R2(11.2)にアップグレードする場合は、新しいソフトウェアが新しいOracleホームにインストールされるアウトオブプレース・モードのアップグレードを実行することをお薦めします。つまり、新しいアップグレード用に別のOracleホームの場所を指定します。ただし、同じOracleホームを保持するインプレース・アップグレードを実行する必要がある場合もあります。この項では、既存のOracleホームを保持する方法について説明します。

インプレース・アップグレードを実行する場合の考慮点およびオプションについては、次の項で説明します。

- インプレース・アップグレードを開始する際の既知の問題

- 単一インスタンスOracle Databaseのインプレース・アップグレードの実行

- Oracle RACデータベースのインプレース・アップグレードの実行

- Windowsでのインプレース・アップグレード

インプレース・アップグレードを開始する際の既知の問題

同じOracleホームの場所を使用してインプレース・アップグレードを実行すると、指定された場所にOracle Databaseソフトウェアが含まれていることがインストーラによって検出されたことを知らせるエラー・メッセージが表示されます。

メッセージ: インストーラにより、指定されたソフトウェアの場所にOracle Databaseソフトウェア・リリース11.2.0.1が含まれていることが検出されました。アップグレードの際は、新規のOracleホームにソフトウェアのアウトオブプレース・インストールを行ってから、新しいソフトウェア・バイナリを使用してデータベースをアップグレードすることをお薦めします。

原因: インストーラにより、指定されたソフトウェアの場所にOracle Databaseソフトウェア・リリース11.2.0.1が含まれていることが検出されました。

対処: この項の説明に従ってインプレース・アップグレードを実行するか、または「アップグレードする場合の新しいOracle Databaseソフトウェアのインストール」の説明に従って新しいOracleホームへのアウトオブプレース・アップグレードを実行します。

単一インスタンスOracle Databaseのインプレース・アップグレードの実行

インプレース・アップグレードを実行する必要がある場合は、次の手順に従って、現在のインストールのバックアップを作成し、そのバックアップを別の場所に移動してから、古い場所に新しいソフトウェアをインストールします。

警告:

既存のOracleホームを使用してOracle Databaseをリリース11.2.0.2または11.2.0.3にアップグレードしないことを強くお薦めします。この手順は、何らかの理由で既存のOracleホームを使用する以外に選択の余地がない場合にのみ使用します。

単一インスタンスのデータベースのインプレース・アップグレードを実行するには、次の手順を実行します。

1. My Oracle Support(https://support.oracle.com/)からOracle Databaseリリース11.2ソフトウェアを入手します。

2. 次のディレクトリのバックアップを作成することによって、構成データをバックアップします。

- ORACLE_HOME/dbs

- ORACLE_HOME/network/admin

- ORACLE_HOME/owb/bin/admin

- ORACLE_HOME/hostname_dbname

- ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname

3. アップグレード元のリリースに応じて、リリース11.2.0.1または11.2.0.2ソフトウェアの場所から、次のコマンドでORACLE_HOMEをデタッチします。

ORACLE_HOME/oui/bin/runInstaller -detachHome ORACLE_HOME=11.2.x.x.x software location

4. このORACLE_HOMEソフトウェア・ディレクトリを一時的な名前に変更するか、または移動します。

mv ORACLE_HOME ORACLE_HOME.backup

5. OUIを起動し、リリース11.2.0.3を選択します。ソフトウェアのみです。

6. 「場所」で、アップグレード元のリリースに応じてリリース11.2.0.1または11.2.0.2に使用されているのと同じ場所を選択します。

7. インストールの完了後、古いOracleホームの構成データをリストアします。/dbsおよびnetwork/adminに対して作成したバックアップから、バックアップ済の構成データ・ファイルをリストアし、さらに/hostname_dbname、/owb/bin/adminおよび/oc4j/j2ee/OC4J_DBConsole_hostname_dbnameディレクトリもリストアします。hostname_dbnameには実際の名前を指定します(hostnameは実際のホスト名で、dbnameは実際のデータベース名です)。

8. ORACLE_HOME/binディレクトリからDBUAを実行し、11.2.0.1.0または11.2.0.2.0データベース・インスタンスを選択して11.2.0.3.0へのアップグレードを実行します。

関連項目:

- ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』

- 『Oracle Databaseインストレーション・ガイドfor Linux』

- 『Oracle Universal InstallerおよびOPatchユーザーズ・ガイド』

Oracle RACデータベースのインプレース・アップグレードの実行

Oracle RACデータベースのインプレース・アップグレードの実行は、「単一インスタンスOracle Databaseのインプレース・アップグレードの実行」で説明している手順に似ています。次の手順に従って、現在のOracleホームおよびインストールのバックアップを作成し、それらを別の場所に移動してから、古い場所に新しいソフトウェアをインストールします。

警告:

既存のOracleホームを使用してOracle Databaseをリリース11.2.0.2以降にアップグレードしないことを強くお薦めします。この手順は、何らかの理由で既存のOracleホームを使用する以外に選択の余地がない場合にのみ使用します。

Oracle RACデータベース・インスタンスのインプレース・アップグレードを実行するには、次の手順を実行します。

1. すべてのクラスタ・ノードで次のディレクトリのバックアップを作成することによって、構成データをバックアップします。

- ORACLE_HOME/dbs

- ORACLE_HOME/network/admin

- ORACLE_HOME/owb/bin/admin

- ORACLE_HOME/hostname_dbname

- ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname

2. 各ノードで次のコマンドを実行して、古いOracle RACのORACLE_HOMEをデタッチします。次に例を示します。

ORACLE_HOME/oui/bin/runInstaller -detachHome ORACLE_HOME=11.2 software location

3. すべてのノードでこのOracle RACのORACLE_HOMEディレクトリの名前を一時的な名前に変更します。

4. Oracle Databaseソフトウェアのみをすべてのノードにインストールします。

5. すべてのノードで、11.2.0.4ソフトウェアの場所ORACLE_HOMEに、/dbsおよびnetwork/adminに対して行ったバックアップからバックアップ済の構成データ・ファイルをリストアし、さらに/hostname_dbname、/owb/bin/adminおよび/oc4j/j2ee/OC4J_DBConsole_hostname_dbnameディレクトリもリストアします。hostname_dbnameに対しては実際の名前を指定します。

6. ローカル・ノードで11.2.0.4のORACLE_HOME/binディレクトリからDBUAを実行し、Oracle RACデータベース・インスタンスを選択してリリース11.2.0.4.0にアップグレードします。

Windowsでのインプレース・アップグレード

新しいOracleホームへのアウトオブプレース・アップグレードを実行することをお薦めします。この手順は、何らかの理由で古いOracleホームを使用する必要がある場合にのみ使用します。

次の項では、Windowsプラットフォーム上で既存のOracleホームへのアップグレードを実行する方法について説明します。

- WindowsプラットフォームでのOracle Databaseのインプレース・アップグレードに関する考慮点

- WindowsでのOracle Databaseのインプレース・アップグレードの実行

重要:

- 「Linux、UNIXおよびWindowsでのDatabase Upgrade Assistantを使用したアップグレード」の説明に従って、新しいOracleホームへのアウトオブプレース・アップグレードを実行することをお薦めします。

- Windows上のインストーラは、runInstallerではなくsetup.exeです。

WindowsプラットフォームでのOracle Databaseのインプレース・アップグレードに関する考慮点

Windowsでは、Oracleファイルを起動またはロックするすべてのサービスを停止する必要があります。そのためには、Windowsサービス・マネージャでそのサービスを無効に設定します。サービスを無効にした後に、ロックされている関連オブジェクトを解放するために再起動が必要になる場合もあります。Windowsプラットフォームでは、ORADIMがWindowsサービス(オペレーティング・システムのプロセス)を管理します。DBCAは、Oracle Databaseインスタンスおよびデータベース・サービスを管理します。

関連項目:
『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』

WindowsでのOracle Databaseのインプレース・アップグレードの実行

この手順は、新しいOracle Database 11gリリース2(11.2)にアップグレードする際に、古いOracleホームを使用する以外に選択の余地がない場合にのみ使用します。これは、Oracle Databaseをリリース11.2にアップグレードする場合の推奨方法ではありません。インプレース・アップグレードを実行する必要がある場合は、この項で示す手順を実行する必要があります。この手順では、現在のインストールをバックアップし、現在のインストールを新しい場所に移動してから、古い場所に新しいソフトウェアをインストールする方法を説明します。

警告:

既存のOracleホームを使用してOracle Databaseをリリース11.2.0.2以降にアップグレードしないことを強くお薦めします。この手順は、何らかの理由で既存のOracleホームを使用する以外に選択の余地がない場合にのみ使用します。

Windowsでインプレース・アップグレードを実行するには、次の手順を実行します。

1. 単一ノードまたはすべてのクラスタ・ノードで次のディレクトリをバックアップすることによって、構成データのバックアップを作成します。

- ORACLE_HOME/dbs

- ORACLE_HOME/database

- ORACLE_HOME/network/admin

- ORACLE_HOME/owb/bin/admin

- ORACLE_HOME/hostname_dbname

- ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname

2. 単一インスタンス・データベースをアップグレードする場合は、この手順をスキップします。Oracle RACデータベースをアップグレードする場合、Oracle Database 11gリリース2(11.2)のソフトウェアをインストールするには、まずOracle Clusterwareをアップグレードする必要があります。「Oracle ClusterwareおよびOracle ASMインスタンスのアップグレードに関する考慮点」を参照してください。

3. ORACLE_HOMEで実行されているインスタンスを停止します。

SQL> SHUTDOWN IMMEDIATE

注意:
Oracle RACデータベースでは、すべてのノードでデータベース・インスタンスを停止し、クラスタ内のすべてのノードで妨げになるすべてのサービスを停止する必要があります。

4. すべてのインスタンスで、NET STOPを使用して、このOracleホームに影響を与える可能性のあるOracleサービスを停止します。次に例を示します。

C:\> NET STOP OracleServiceORACLE_SID

ここで、OracleServiceはサービスの名前で、ORACLE_SIDはデータベース・インスタンスのSIDです。

停止を必要とする可能性のあるOracleサービスは次のとおりです。

- TNSListener

- HTTPサーバー

- Oracle Management Server

- OLAP Agent

- Intelligent Agent

関連項目:
My Oracle Support(https://support.oracle.com)

- 11.2.0.2および11.2.0.3に関する詳細は、Note ID 1291682.1「In-Place Upgrade to 11.2.0.2 on Windows Platform」を参照してください。

- 影響を与えるプロセスによってロックされるファイルの詳細は、Note ID 294350.1「Write Errors, or Files In Use, or NoServicesForProcessException During Patch Installation」を参照してください。

- ORADIMを使用したデータベース・インスタンスの管理の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

注意:
停止するサービスのリストは含まれていません。停止する必要があるWindows固有およびベンダー固有のサービスが存在する場合もあります。

5. 各ノードで次のコマンドを実行して、このOracle RACのORACLE_HOMEをデタッチします。

ORACLE_HOME/oui/bin/setup -detachHome ORACLE_HOME=this software location

6. すべてのノードでこのOracle RACのORACLE_HOMEディレクトリの名前を一時的な名前に変更します。

7. すべてのノードでリリース11.2.0.3のソフトウェアのみをインストールします。

8. 必要に応じて、ORADIMを使用して新しいインスタンスを作成します。

C:\oracle\bin\oradim –NEW -SID ORACLE_SID

ORACLE_SIDは、データベース・インスタンスのSIDです。これにより、アップグレードするインスタンスをDBUAでリストできるようになります。

関連項目:
ORADIMを使用したインスタンスの作成の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

9. すべてのノードで、このソフトウェアの場所ORACLE_HOMEに、/dbs、/databaseおよびnetwork/adminに対して行ったバックアップからバックアップ済の構成データ・ファイルをリストアし、さらに/hostname_dbname、/owb/bin/adminおよび/oc4j/j2ee/OC4J_DBConsole_hostname_dbnameディレクトリもリストアします。hostname_dbnameに対しては実際の名前を指定します。

10. ローカル・ノードでこのORACLE_HOME/binディレクトリからDBUAを実行します。Oracle RACデータベースをアップグレードする場合、11.2.0.1.0または11.2.0.2.0 Oracle RACデータベース・インスタンスを選択してリリース11.2.0.3.0にアップグレードします。

関連項目:
データベースのインストール後のタスクの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

サイレント・モードのDBUAを使用したOracle Databaseのアップグレード

-silentコマンドライン・オプションを使用してDBUAを起動すると、DBUAはサイレント・モードで動作します。サイレント・モードでは、DBUAのユーザー・インタフェースは表示されません。また、情報、エラー、警告を含むすべてのメッセージは、ORACLE_HOME/cfgtoollogs/dbua/SID/upgradenにあるログ・ファイルに書き込まれます(nは、このアップグレードの時点でDBUAが実行したアップグレードの回数です)。

サイレント・モードのDBUAを使用してデータベースをアップグレードするには、次の手順を実行します。

- 次のコマンドを発行します。

dbua -silent -sid ORCL &

この例では、データベースの名前はORCLです。

サイレント・モード時のOracle DBUAのコマンドライン・オプション

Database Upgrade Assistant(DBUA)では、サイレント・モードで実行する場合のコマンドライン・オプションがサポートされています。表3-3に、DBUAでサポートされている様々なオプションおよび対応するパラメータを示します。

注意:
Oracle Database 11gリリース2(11.2)のデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

表3-3 DBUAのコマンドライン・オプション

オプション

説明

-silent

DBUAがサイレント・モードで動作するように指定します。

-sid SID

アップグレードするデータベースのシステム識別子(SID)を指定します。

-oracleHome home_name

アップグレードするデータベースのOracle Databaseホーム・ディレクトリを指定します。

-oracleBase base_name

アップグレードするデータベースのOracle Databaseベース・ディレクトリを指定します。

-diagnosticDest diagnostic_destination

Oracleトレース・ファイルおよび診断ファイルを保存するデフォルトの場所を指定します。これにより、バックグラウンド・ダンプ保存先およびユーザー・ダンプ保存先の初期化パラメータ設定が、前のリリースの設定から置き換わります。

-sysDBAUserName SYSDBA_user

SYSDBA権限を持つユーザーを指定します。

-sysDBAPassword SYSDBA_pwd

SYSDBA_userのパスワードを指定します。

-autoextendFiles

アップグレード中にデータベース・ファイルの自動拡張を行います。データ・ファイルはアップグレードの後で元の自動拡張設定に戻ります。

-newGlobalDbName db_name

新しいグローバル・データベース名を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-newSid new_SID

アップグレードするデータベースの新しいシステム識別子(SID)を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-upgradeTimezone

データベースのタイムゾーン・ファイルのバージョンをアップグレードします。

-generateMapFile

データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。このオプションを指定した場合、DBUAではログの場所にデータベース・マップ・ファイルのみが生成されて、終了します。

-useASM

データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。アップグレードするデータベースにOracle ASMインスタンスがある場合、そのインスタンスを使用してアップグレードを実行するように、このオプションでDBUAに指定します。

-commonFileLocation common_files

データベース・ファイルを格納するための共通の位置を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-omfLocation omf_area

Oracle Managed Files用のデータベース領域を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-databaseMapFile map_file_name

データベース・ファイルをマップするためのマップ・ファイルの完全名を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-newRecoveryArea recover_area

アップグレード中に移動されるデータベース用のリカバリ領域を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-newRecoveryAreaSize recover_size

アップグレード中に移動されるデータベース用のリカバリ領域のサイズをMB単位で指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。

-apexAdminPassword apex_pwd

Application Express管理者のパスワードを指定します。

-disableUpgradeScriptLogging

アップグレード時に実行しているSQLスクリプトの詳細ログの生成を無効にします。このオプションは、デフォルトでは有効になっています。ログ生成を有効にする場合は、このオプションを指定しないでください。

-backupLocation directory

アップグレードを開始する前にデータベースをバックアップするディレクトリを指定します。

-sysauxTablespace

新しいSYSAUX表領域を作成します。

-datafileName name

新しいSYSAUX表領域を作成するデータ・ファイルの完全なパスを指定します。

-datafileSize size

新しいSYSAUX表領域を作成するデータ・ファイルのサイズを指定します(500MB、10GB)。

-datafileSizeNext size

データ・ファイルの次のエクステントを指定します。

-datafileSizeMax size

データ・ファイルの最大サイズを指定します。

-postUpgradeScripts script [, script ] ...

SQLスクリプトを、カンマで区切ったリストにして指定します。完全なパス名を指定します。このスクリプトはアップグレードの終了時に実行されます。

-initParam parameter=value [, parameter=value ] ...

name=valueという形式の初期化パラメータ値を、カンマで区切ったリストにして指定します。

-disableArchiveLogMode

アップグレード中のアーカイブおよびフラッシュバック・ロギングをオフにします。

-recompile_invalid_objects true|false

このオプションをTRUEにすると、すべての無効なPL/SQLモジュールが、アップグレードの実行直後にDBUAによって再コンパイルされます。

-degree_of_parallelism cpu_number

パラレル再コンパイルに使用するCPUの数を指定します。

-emConfiguration
{CENTRAL|LOCAL|ALL|NOBACKUP|
NOEMAIL|NONE}

Oracle Enterprise Managerの管理オプションを指定します。

- CENTRAL: データベースはOracle Enterprise Managerによって集中管理されます。

- LOCAL: データベースはOracle Enterprise Managerによってローカル管理されます。

- ALL: Oracle Enterprise Manager Database Controlの構成、日次バックアップの有効化、および電子メール通知の有効化を行うオプションです。

- NOBACKUP: データベースの自動日次バックアップは有効化されません。

- NOEMAIL: 電子メール通知が有効にされません。

- NONE: データベースの管理はEnterprise Managerで行われません。

-dbsnmpPassword password

DBSNMPユーザー・パスワードを指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-sysmanPassword password

SYSMANユーザー・パスワードを指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-asmPassword password

Oracle ASMインスタンス用のSYSパスワードを指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-hostUserName hostname

Oracle Enterprise Managerのバックアップ・ジョブ用のホスト・ユーザー名を指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-hostUserPassword password

Oracle Enterprise Managerのバックアップ・ジョブ用のホスト・ユーザーのパスワードを指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-backupSchedule hh:mm

hh:mm(時間および分)の形式で日次バックアップ・スケジュールを指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-smtpServer server_name

電子メール通知用の送信メール・サーバー(SMTP)を指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-emailAddress address

電子メール通知用の電子メール・アドレスを指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-centralAgent location

Oracle Enterprise Managerの中央エージェントの場所を指定します。このオプションは、Oracle Enterprise Managerを構成する場合にのみ適用されます。

-recoveryAreaDestination directory

すべてのリカバリ・ファイルの宛先ディレクトリを指定します。このオプションが適用されるのは、データ・ファイルを移動する場合、Oracle XEデータベースをアップグレードする、またはOracle Enterprise Managerを構成する場合のみです。

[-localRacSid SID

クラスタ・データベースがOracle Cluster Registryに登録されていない場合は、クラスタ・データベースのローカルSIDを指定します。

-h | -help

DBUAのヘルプを表示します。

サイレント・モード時のDBUAのコマンドライン構文

次の構文を使用して、すべての有効なオプションをコマンドラインから指定できます。

dbua [ -silent ] [ -sid SID ] [-oracleHome home_name] [-oracleBase base_name]
[-diagnosticDest diagnostic_destination]
[-sysDBAUserName SYSDBA_user] [-sysDBAPassword SYSDBA_pwd]
[-upgradeASM] [-autoextendFiles] [-newGlobalDbName db_name] [-newSid new_SID]
[-generateMapFile] [-useASM] [-commonFileLocation common_files]
[-omfLocation omf_area] [-databaseMapFile map_file_name]
[-newRecoveryArea recover_area] [-newRecoveryAreaSize recover_size]
[-apexAdminPassword apex_pwd] [-disableUpgradeScriptLogging ]
[-backupLocation directory]
[-sysauxTablespace -datafileName name -datafileSize size
-datafileSizeNext size -datafileSizeMax size]
[-postUpgradeScripts script [, script ] ... ]
[-initParam parameter=value [, parameter=value ] ... ]
[-disableArchiveLogMode] [-recompile_invalid_objects true | false]
[-degree_of_parallelism cpu_number]
[-emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE}
-dbsnmpPassword password -sysmanPassword password -asmPassword password
-hostUserName hostname -hostUserPassword password -backupSchedule hh:mm
[-smtpServer server_name -emailAddress address]
[-centralAgent location] [-localRacSid SID]]
[-recoveryAreaDestination directory] [-h|-help]

Oracle Databaseの手動でのアップグレード

DBUAを使用するかわりに手動でOracle Databaseをアップグレードする必要がある場合があります。「アップグレードする場合の新しいOracle Databaseソフトウェアのインストール」の説明に従って新しいOracle Databaseソフトウェアをインストールして、データベースのバックアップを作成し、新しいOracleホームを準備したら、手動アップグレードに進むことができます。データベースの手動アップグレードの手順では、「アップグレード前情報ツールの使用」で説明したアップグレード前情報ツールが前に実行されていることが前提となっています。

次の項では、手動でアップグレードを実行する手順について説明します。

- 手動アップグレードを行う場合のOracle Databaseのバックアップ

- 手動アップグレードを行う場合の新しいOracleホームの準備

- Oracle Databaseの手動でのアップグレード

手動アップグレードを行う場合のOracle Databaseのバックアップ

アップグレード前情報ツールを実行し、正常にインスタンスを停止した後、この項の説明に従ってデータベースをバックアップすることをお薦めします。アップグレードの問題が発生した場合、アップグレードをすべて中止するには、このバックアップからデータベースをリストアする必要があります。そのため、予防措置として、ここでデータベースをバックアップすることをお薦めします。

アップグレード対象のデータベースの全体バックアップを実行するには、次の手順を実行します。

1. RMANにサインオンします。

rman "target / nocatalog"

2. 次のRMANコマンドを発行します。

RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE FORMAT 'controlfile location and name';
}

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

手動アップグレードを行う場合の新しいOracleホームの準備

アップグレードするデータベースをバックアップした後、新しい場所に新しいOracleホームを準備します。データベースがリリース11.2以下であるかどうかに関係なく、アップグレードするOracle Databaseのすべてのリリースについて、この手順を行います。Oracle Database 11gリリース2(11.2.0.3)以上では、既存のOracleホームにパッチ・セットを適用するのではなく、新しいOracleホームにOracle Grid InfrastructureとOracle Databaseソフトウェアをインストールします。

関連項目:
「手動アップグレードを行う場合のOracle Databaseのバックアップ」

新しいOracleホームを準備するには、次の手順を実行します。

1. アップグレードするデータベースのOracleホームから新しいOracle Database 11gリリース2(11.2)のOracleホームへ構成ファイルをコピーします。

1. パラメータ・ファイルが古い環境のOracleホームに存在する場合は、新しいOracleホームへコピーします。パラメータ・ファイルを検索するデフォルトの場所は、LinuxまたはUNIXプラットフォームの場合はORACLE_HOME/dbsディレクトリで、Windowsオペレーティング・システムの場合はORACLE_HOME\databaseディレクトリです。パラメータ・ファイルは任意の場所に格納できますが、Oracle Database 11gリリース2(11.2)にアップグレードした後は、古い環境のOracleホームには格納しないでください。

注意:
初期化パラメータを編集する場合は、サーバー・パラメータ・ファイル(SPFILE)からテキストベースの初期化パラメータ・ファイル(PFILE)を作成する必要があります。

2. Oracle ASMインスタンス内にパラメータ・ファイルがある場合は、次のコマンドを使用してパラメータ・ファイルをバックアップしてください。

CREATE pfile FROM spfile;

SPFILEがOracle ASMにある環境のデータベースをダウングレードする必要がある場合は、ダウングレードする前にパラメータ・ファイルをリストアする必要があります。

3. パラメータ・ファイルがIFILE(インクルード・ファイル)エントリまたはSPFILE(サーバー・パラメータ・ファイル)エントリのいずれかを含むテキストベースの初期化パラメータ・ファイルであり、IFILEエントリまたはSPFILEエントリ内に指定されたファイルが古い環境のOracleホームに存在する場合、IFILEエントリまたはSPFILEエントリで指定されているファイルを新しいOracleホームへコピーします。IFILEエントリまたはSPFILEエントリ内に指定されたファイルには、追加の初期化パラメータがあります。

4. 古い環境のOracleホームに格納されたパスワード・ファイルがある場合は、そのパスワード・ファイルをOracle Database 11gリリース2(11.2)のOracleホームに移動またはコピーします。
パスワード・ファイルの名前と位置は、オペレーティング・システムによって異なります。LinuxまたはUNIXプラットフォームのデフォルトのパスワード・ファイルはorapwsidで、ORACLE_HOME/dbsディレクトリにあります。Windowsオペレーティング・システムのデフォルトのパスワード・ファイルはpwdsid.oraで、ORACLE_HOME\databaseディレクトリにあります。両方の場合とも、sidはOracleインスタンスのIDです。

5. クラスタ・データベースをアップグレードしている場合で、initdb_name.oraファイルが古い環境のOracleホームに存在する場合、initdb_name.oraファイルを新しいOracleホームに移動またはコピーします。

注意:
クラスタ・データベースをアップグレードしている場合は、このクラスタ・データベースのインスタンスが構成されているすべてのノードでこの手順を実行してください。

2. Oracle Enterprise Editionデータベースをアップグレードする場合は、古いOracleホームから新しいOracleホームにEnterprise Manager Databaseコンソールのディレクトリをコピーする必要があります。DBUAは、自動的にEnterprise Manager Databaseコンソールのディレクトリをコピーしてアップグレードすることに注意してください。

3. 次の手順を実行して、Oracle Database 11gリリース2(11.2)のパラメータ・ファイルを調整します。

1. 廃止された初期化パラメータを削除して、非推奨の初期化パラメータを調整します。一部のパラメータはOracle Database 11gリリース2(11.2)では廃止されており、他のパラメータは非推奨となっています。廃止されたすべてのパラメータを、Oracle Database 11gリリース2(11.2)インスタンスを起動するパラメータ・ファイルから削除します。廃止されたパラメータは、Oracle Database 11gリリース2(11.2)でエラーの原因となる可能性があります。また、新しいリリースで構文が変更になったパラメータも変更します。

アップグレード前情報ツールを使用すると、「Deprecated Parameters」および「Obsolete Parameters」の各セクションに非推奨および廃止されたパラメータが表示されます。

関連項目:
非推奨となったり、廃止された初期化パラメータのリスト、およびOracle Databaseソフトウェアの異なるリリース間で互換性の問題が発生するようような方法で変更された初期化パラメータの詳細については、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

2. COMPATIBLE初期化パラメータが、Oracle Database 11gリリース2(11.2)用に正しく設定されていることを確認します。COMPATIBLEが正しく設定されていない場合は、アップグレード前情報ツールによって「Database」セクションに警告が表示されます。

3. 初期化パラメータの値をアップグレード前情報ツールによって示された最小値以上に調整します。

4. パラメータ・ファイルのすべてのパス名が完全に指定されていることを確認します。パラメータ・ファイルには相対パス名を使用しないでください。

5. パラメータ・ファイルにIFILEエントリがある場合、パラメータ・ファイルのIFILEエントリを変更して、手順1のcで指定したインクルード・ファイルの新しい場所を指定するようにします。次に、手順aからdでパラメータ・ファイルを編集したときと同じ方法で、IFILEエントリに指定されているファイルを編集します。

6. クラスタ・データベースをアップグレードしている場合は、パラメータ・ファイルを変更したときと同じ方法でinitdb_name.oraファイルを変更します。

これらの調整後、変更したすべてのファイルを保存します。

注意:
クラスタ・データベースをアップグレードしている場合は、このクラスタ・データベースのインスタンスが構成されているすべてのノードでこの手順を実行してください。

4. クラスタ・データベースをアップグレードしている場合は、CLUSTER_DATABASE初期化パラメータをfalseに設定します。アップグレードが完了した後、この初期化パラメータの設定をTRUEに戻す必要があります。

Oracle Databaseの手動でのアップグレード

「アップグレードする場合の新しいOracle Databaseソフトウェアのインストール」の説明に従って新しいOracle Databaseソフトウェアをインストールし、「手動アップグレードを行う場合の新しいOracleホームの準備」の説明に従って新しいOracleホームを準備したら、手動アップグレードに進むことができます。

データベースを手動でアップグレードするには、次の手順を実行します。

1. インスタンスを停止します。

SQL> SHUTDOWN IMMEDIATE

2. ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。

1. アップグレードするデータベースのOracleサービスOracleServiceSIDを停止します(SIDはインスタンスの名前です)。たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。

C:\> NET STOP OracleServiceORCL

2. コマンド・プロンプトで、ORADIMを使用してOracleサービスを削除します。
SIDがORCLの場合、次のコマンドを入力します。

C:\> ORADIM -DELETE -SID ORCL

3. コマンド・プロンプトで新しいOracle DatabaseリリースのORADIMコマンドを使用して、Oracle Database 11gリリース2(11.2)のサービスを作成します。

C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS
-STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

この構文には次の変数が含まれます。

変数

説明

SID

アップグレードするデータベースのSIDと同じSID名。

PASSWORD

新しいOracle Database 11gリリース2(11.2)データベース・インスタンスのパスワード。SYSDBA権限で接続するユーザー用のパスワードです。-SYSPWDオプションは必須ではありません。これを指定しない場合、オペレーティング・システムの認証が使用され、パスワードは不要です。
Oracle Database 11gリリース2(11.2)のデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

USERS

SYSDBA権限およびSYSOPER権限を付与できるユーザーの最大数。

ORACLE_HOME

Oracle Database 11gリリース2(11.2)のOracleホーム・ディレクトリ。-PFILEオプションを使用して、(Oracleホーム・ディレクトリのドライブを含む)フルパス名を指定する必要があります。

たとえば、SIDがORCL、password(SYSPWD)がTWxy5791、ユーザーの最大数(MAXUSERS)が10、ORACLE_HOMEディレクトリがC:\ORACLE\PRODUCT\11.2.0\DBの場合、次のコマンドを入力します。

C:\> ORADIM -NEW -SID ORCL -SYSPWD TWxy5791 -MAXUSERS 10
-STARTMODE AUTO -PFILE C:\ORACLE\PRODUCT\11.2.0\DB\DATABASE\INITORCL.ORA

ORADIMによって、ORACLE_HOME\databaseディレクトリにログが書き込まれます。

3. ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の内容を確認します。

1. ORACLE_SIDが正しく設定されていること。

2. oratabファイルがOracle Database 11gリリース2(11.2)のOracleホームを指していること。

3. 次の環境変数がOracle Database 11gリリース2(11.2)のディレクトリを指していること。

- ORACLE_HOME

- PATH

4. ORACLE_HOME値を設定するためにクライアントで使用するすべてのスクリプトが、新しいOracleホームを指している必要があります。

注意:
クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。

関連項目:
ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関するオペレーティング・システム固有のOracle Databaseの手順については、『Oracle Databaseインストレーション・ガイド』を参照してください。

4. Grid InfrastructureおよびOracle Databaseに対して別のユーザーおよびグループが存在する場合は、新しいORACLE_HOME/bin/oracleディレクトリに対して、次の例に示すように-oオプションを指定してGRID_HOME/binディレクトリにあるsetasmgidwrapスクリプトを実行します。

$GRID_HOME/bin/setasmgidwrap o=ORACLE_HOME/bin/oracle

5. Oracle Database 11gリリース2(11.2)のOracleホーム・ディレクトリの所有者としてシステムにログインします。

6. システム・プロンプトで、ORACLE_HOME/rdbms/adminディレクトリに移動します。

7. SQL*Plusを起動します。

8. SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

9. 次のコマンドを発行して、インスタンスを起動します。

SQL> STARTUP UPGRADE

注意:
UPGRADEキーワードを使用すると、前のOracle Databaseリリースをベースとするデータベースをオープンできます。また、AS SYSDBAセッションへのログオンの制限、システム・トリガーの無効化、およびアップグレードの環境を準備するその他の操作も実行されます。

PFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。

いったんデータベースをアップグレード・モードで起動すると、catupgrd.sqlスクリプトを実行するまでは、固定ビューへの問合せのみ、エラーにならずに実行できます。catupgrd.sqlを実行する前は、他のビューに問い合せたりPL/SQLを実行すると、エラーが戻されます。

次に、新しいOracle Database 11gリリース2(11.2)データベースを起動しようとした場合に発生する一般的なエラーを示します。これらのエラーの一部はアラート・ログに記録され、セッションには表示されません。いずれかのエラーが表示された場合、 SHUTDOWN ABORTコマンドでデータベースを停止し、問題を修正します。

- ORA-00401: パラメータcompatibleの値はこのリリースではサポートされません。
COMPATIBLE初期化パラメータが10.0.0未満に設定されている場合。

- ORA-39701: データベースをUPGRADEまたはDOWNGRADE用にEXCLUSIVEでマウントしてください
CLUSTER_DATABASE初期化パラメータがFALSEではなく、TRUEに設定されている場合。

- ORA-39700: データベースは、UPGRADEオプションを使用してオープンしてください
UPGRADEキーワードを指定しないでSTARTUPコマンドを発行した場合。

- ORA-00336: ログ・ファイルのサイズxxxxが最小値8192より小さくなっています
REDOログのサイズが4MB未満の場合。

廃止された初期化パラメータを示すエラーが表示された場合は、その廃止された初期化パラメータを記録し、アップグレードを継続します。次にデータベースを停止するときに、廃止された初期化パラメータを削除します。

10. この手順は、Oracle9iリリース2(9.2)からアップグレードする場合のみ行ってください。そうでない場合、次の手順にスキップします。
SYSAUX表領域を作成します。以前のリリースでは複数の表領域に別々に存在していたデータが、新しいOracle Database 11gリリースではSYSAUX表領域を使用して統合されます。

SYSAUX表領域は、次の必須属性を指定して作成する必要があります。

- ONLINE

- PERMANENT

- READ WRITE

- EXTENT MANAGEMENT LOCAL

- SEGMENT SPACE MANAGEMENT AUTO

表3-4を使用して、SYSAUX表領域に最適なサイズを判断できます。また、アップグレード前情報ツールの「SYSAUX表領域」セクションに、SYSAUX表領域に最低限必要なサイズの見積りが表示されます。

表3-4 SYSAUX表領域のサイズ変更のためのガイドライン

要素

小

中

大

CPUの数

2

8

32

同時実行セッションの数

5

20

100

ユーザー・オブジェクト(表および索引)の数

500

5,000

50,000

定常状態でのデフォルト構成のSYSAUXの推定サイズ

500MB

2GB

5GB

次のSQL文では、データベースに500MBのSYSAUX表領域が作成されます。

SQL> CREATE TABLESPACE sysaux DATAFILE 'sysaux01.dbf'
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;

関連項目:
SYSAUX表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

11. 成功したかどうかを後で確認するために、結果をログ・ファイルにスプールするようにシステムを設定します。

SQL> SPOOL upgrade.log

12. catupgrd.sqlスクリプトを実行します。

SQL> @catupgrd.sql

catupgrd.sqlスクリプトでは、必要なアップグレード・スクリプトが特定されて実行された後、データベースが停止されます。Oracle Database 11gリリース2(11.2)の環境でスクリプトを実行する必要があります。

アップグレード・スクリプトを実行すると、特定のデータ・ディクショナリ表を作成して変更します。また、新しいOracle Database 11gリリース2(11.2)データベースの次のデータベース・コンポーネントも、アップグレードまたはインストールされます。

- Oracle Database Catalog Views

- Oracle Database Packages and Types

- JServer JAVA Virtual Machine

- Oracle Database Java Packages

- Oracle XDK

- Real Application Clusters

- Oracle Workspace Manager

- Oracle Multimedia

- Oracle XML Database

- OLAPアナリティック・ワークスペース

- Oracle OLAP API

- OLAPカタログ

- Oracle Text

- Spatial

- Oracle Data Mining

- Oracle Label Security

- Messaging Gateway

- Oracle Expression Filter

- Oracle Rules Manager

- Oracle Enterprise Manager Repository

- Oracle Database Vault

- Oracle Application Express

注意:
アップグレード前情報ツールを実行しなかった場合、catupgrd.sqlスクリプトは次のいずれかのエラーを戻して終了します。

ORA-00942: table or view does not exist
ORA-00904: "TZ_VERSION": invalid identifier
ORA-01722: invalid number

いずれかのエラーが表示された場合は、SHUTDOWN ABORT文を発行し、元のOracleホーム・ディレクトリに戻り、アップグレード前情報ツール(utlu112i.sql)を実行します。「アップグレード前情報ツールの使用」を参照してください。

13. インスタンスを再起動して、通常の操作用にシステム・パラメータを再初期化します。

SQL> STARTUP

catupgrd.sqlスクリプトの一部としてデータベースが停止された後のこの再起動では、すべてのキャッシュがフラッシュされ、バッファが消去されて、その他の内部的な不整合が解消されます。これらの操作は、新しくアップグレードしたOracle Databaseソフトウェアの整合性と一貫性を保証するための重要な最終手順です。

14. 手順9でデータベースを起動したときに、廃止された初期化パラメータをリストしたメッセージが表示された場合は、廃止された初期化パラメータを再起動前にパラメータ・ファイルから削除します。ファイルを編集してパラメータを削除するために、必要に応じてSPFILEをPFILEに変換します。『Oracle Database管理者ガイド』のサーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する章を参照してください。

15. アップグレード後の状態ツールutlu112s.sqlを実行します(これにより、スプール・ログの末尾にアップグレードのサマリーが表示されます)。アップグレードの完了後に、utlu112s.sqlをいつでも実行できます。詳細は、「アップグレード後の状態ツールの概要」を参照してください。
次のようにutlu112s.sqlを実行し、アップグレードの結果を表示します。

SQL> @utlu112s.sql

アップグレード後の状態ツールからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、「Oracle Databaseのアップグレードのトラブルシューティング」で詳細を参照してください。

16. catuppst.sqlを実行し、データベースをUPGRADEモードにする必要がないアップグレード操作を実行します。

SQL> @catuppst.sql

これにより、次の情報メッセージが生成される場合があります。

Generating apply and rollback scripts...
Check the following file for errors:
Apply script: .*
Rollback script: .*
Executing script file...
Updating registry...
Check the following log file for errors:

Generating apply and rollback scripts...
Check the following file for errors:
.../cfgtoollogs/catbundle/catbundle_PSU_*.log
Apply script:
.../rdbms/admin/catbundle_PSU_*_APPLY.sql
Rollback script:
.../rdbms/admin/catbundle_PSU_*_ROLLBACK.sql
Executing script file...

Updating registry...
Check the following log file for errors:
.../cfgtoollogs/catbundle/catbundle_PSU_*.log

17. utlrp.sqlを実行して、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。

SQL> @utlrp.sql

予測されるすべてのパッケージおよびクラスが有効であることを確認します。

SQL> SELECT count(*) FROM dba_invalid_objects;
SQL> SELECT distinct object_name FROM dba_invalid_objects;

注意:
アップグレード前情報ツールでINVALIDオブジェクトが検出され、registry$sys_inv_objs表およびregistry$nonsys_inv_objs表に格納された場合は、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行してアップグレード処理の結果新しく無効になったオブジェクトのみを表示します。このutluiobj.sqlスクリプトを実行すると、アップグレード前はVALIDであったが、現在はINVALIDであるオブジェクトのみが表示されます。

18. SQL*Plusを終了します。

19. リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。

$ srvctl upgrade database -d db-unique-name -o oraclehome

ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、oraclehomeは、データベースがアップグレードされるOracleホームの場所です。

これで、データベースが新しいOracle Database 11gリリースにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。

注意:
Oracle Warehouse Builderコンポーネントはcatupgrd.sqlスクリプトの一部としてアップグレードされませんので、このコンポーネントのバージョンはアップグレード処理中に更新されません。

注意:

古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。また、古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置してください。データ・ファイルの再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。

アップグレード後の状態ツールの概要

アップグレード後の状態ツール(utlu112s.sqlスクリプト)を実行すると、アップグレードされたデータベースのデータベース・コンポーネントの状態および各コンポーネントのアップグレード完了までの所要時間が表示されます。アップグレード中に発生したすべてのエラーが、コンポーネントごとにリストされますので、これに対処する必要があります。utlu112s.sqlスクリプトは、、catupgrd.sqlの実行後にいつでも実行できます(utlrp.sqlの実行後ではありません)。

アップグレード後の状態ツールを実行すると、次の出力のようなレポートが表示されます。

Oracle Database 11.2 Post-Upgrade Status Tool           07-12-2011 12:36:25
.
Component                               Current      Version     Elapsed Time
Name                                    Status       Number      HH:MM:SS
.
Oracle Server
.                                         VALID      11.2.0.3.0  00:04:47
JServer JAVA Virtual Machine
.                                         VALID      11.2.0.3.0  00:01:05
Oracle Workspace Manager
.                                         VALID      11.2.0.3.0  00:00:18
OLAP Analytic Workspace
.                                         VALID      11.2.0.3.0  00:00:07
OLAP Catalog
.                                         VALID      11.2.0.3.0  00:00:21
Oracle OLAP API
.                                         VALID      11.2.0.3.0  00:00:12
Oracle Label Security
.                                         VALID      11.2.0.3.0  00:00:02
Oracle Enterprise Manager
.                                         VALID      11.2.0.3.0  00:00:50
Oracle XDK
.                                         VALID      11.2.0.3.0  00:00:19
Oracle Text
.                                         VALID      11.2.0.3.0  00:00:11
Oracle XML Database
.                                         VALID      11.2.0.3.0  00:01:04
Oracle Database Java Packages
.                                         VALID      11.2.0.3.0  00:00:07
Oracle Multimedia
.                                         VALID      11.2.0.3.0  00:01:25
Spatial
.                                         VALID      11.2.0.3.0  00:00:50
Oracle Expression Filter
.                                         VALID      11.2.0.3.0  00:00:04
Oracle Rules Manager
.                                         VALID      11.2.0.3.0  00:00:02
Oracle Application Express
.                                         VALID     3.2.1.00.10
Oracle Database Vault
.                                         VALID      11.2.0.3.0  00:00:02
Gathering Statistics
.                                                                00:00:36
Total Upgrade Time: 00:12:30

Oracle Databaseのアップグレードのトラブルシューティング

Oracleでは、Oracle Databaseのアップグレード処理中に発生する可能性のある問題やエラーに関するトラブルシューティングのヒントおよび回避策を提供しています。また、『Oracle Databaseプラットフォーム共通日本語README』も確認してください。

この項には次のトピックが含まれます:

- Oracle RACでのアップグレード前のOracleホームの削除

- リソース制限およびOracle Databaseのアップグレード

- 未設定のCOMPATIBLEパラメータ

- エディション・セッションの起動エラー

- ORA-01408の手動の回避策

- アップグレード後にDBMS_DSTパッケージを実行した場合にORA-01822が発生する

- アップグレード全体が完了する前にDBUAにより無効なコンポーネントにXマークを付けることが可能

- コンポーネントの状態の理解

- Oracle Databaseのアップグレードの再実行

- Oracle Databaseのアップグレードの取消し

Oracle RACでのアップグレード前のOracleホームの削除

アップグレードが成功した後に、しばらくの間、古いOracleホームを保持しておく必要がある場合があります。ただし、新しくアップグレードされたOracle Databaseのテストが終了したら、古いOracleホームを削除する必要があります。

すべてのノードでClusterwareユーザーとして、次のSQL*Plusコマンドを入力します。

- OLD_HOMEをデタッチします(OLD_HOMEはアップグレード前のOracleホームです)。

$OLD_HOME/oui/bin/runInstaller -detachHome -silent -local

- OLD_HOMEが中央インベントリから削除されたことを確認します。

$OLD_HOME/OPatch/opatch lsinventory -all

- 手動でOLD_HOMEのファイルを削除します。

/bin/rm -rf $OLD_HOME

リソース制限およびOracle Databaseのアップグレード

Oracle Databaseのアップグレード中にリソース(ディスク領域、メモリーなど)が不足した場合は、リソースの割当てを増やします。リソースの割当てを増やした後、SHUTDOWN ABORTを実行し、インスタンスを(UPGRADEモードで)再起動してから、catupgrd.sqlスクリプトを再実行するか、またはDBUAを再起動する必要があります。

通常、Oracle Databaseの新しいリリース用に増やす必要があるリソースは、次のとおりです。

- SYSTEMおよびSYSAUX表領域
通常、SYSTEM表領域のサイズが不十分な場合、アップグレード中に次のいずれかのメッセージが表示されます。

ORA-01650: unable to extend rollback segment string by string in tablespace string
ORA-01651: unable to extend save undo segment by string for tablespace string
ORA-01652: unable to extend temp segment by string in tablespace string
ORA-01653: unable to extend table string.string by string in tablespace string
ORA-01654: unable to extend index string.string by string in tablespace string
ORA-01655: unable to extend cluster string.string by string in tablespace string

これらのエラーを回避するには、SYSTEMおよびSYSAUX表領域にAUTOEXTEND ON MAXSIZE UNLIMITEDを設定します。

- 共有メモリー
より大きな共有メモリーのプール・サイズが必要な場合があります。増やす必要がある共有メモリーの初期化パラメータが、エラー・メッセージに示されます。

ORA-04031: unable to allocate string bytes of shared memory ("string","string","string","string")

関連項目:
共有メモリーの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ロールバック・セグメント/UNDO表領域
ロールバック・セグメントを使用している場合、アップグレード・スクリプトの実行中は、1つの大きい(100MBの)パブリック・ロールバック・セグメントをオンラインにする必要があります。小さいパブリック・ロールバック・セグメントは、アップグレード中はオフラインにする必要があります。通常、ロールバック・セグメントのサイズが不十分な場合は、次のエラーが表示されます。

ORA-01562: failed to extend rollback segment number string

UNDO表領域を使用している場合は、400MB以上であることを確認してください。

- フラッシュ・リカバリ領域
フラッシュ・リカバリ領域を使用してアップグレード中にこの領域が一杯になった場合は、アラート・ログに次のエラーが表示され、その後に問題から復旧するためのアドバイスも表示されます。

ORA-19815: WARNING: db_recovery_file_dest_size of string bytes is 98.99%
used, and has string remaining bytes available.

問題の根本原因を特定し、アップグレードを続行するための適切な対処を行います。アップグレード中にこの問題が発生しないようにするには、アップグレードを開始する前に、フラッシュ・リカバリ領域内の使用可能な領域を増やします。

未設定のCOMPATIBLEパラメータ

アップグレード・モードで新しいOracleホームのデータベースをオープンしようとしたときに、エラーORA-00723「初期化パラメータCOMPATIBLEは明示的に設定する必要があります」が表示された場合、pfileまたはspfileでCOMPATIBLEが設定されていることを確認してください。

関連項目:
COMPATIBLE初期化パラメータの設定の詳細は、「COMPATIBLE初期化パラメータの設定」を参照してください。

エディション・セッションの起動エラー

SQL*Plusで実行するアップグレード・スクリプトまたはコマンドでEDITIONパラメータを設定すると、それ以降はOracle Databaseが適切に起動できなくなり、エラー「SP2-1540: Oracle Databaseはエディション・セッションでは起動できません。」がスローされます。この問題を回避するには、このパラメータが変更されるcatugrd.sqlまたはSQL*Plusセッションを実行した後に、そのSQL*Plusセッションを終了し、別のセッションでそのインスタンスを再起動します。

ORA-01408の手動の回避策

ORA-01408エラーは、Oracle Applicationデータベースの既知の問題です。この回避策では、次のシナリオに対処します。

SQL> Create Index system.repcat$_audit_column_f2_idx ON
2  system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
3  base_reference_name)
4  /
system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
*ERROR at line 2:
ORA-01408: such column list already indexed

回避策として、REPCAT$_AUDIT_COLUMN_IDX1索引を削除し、「Oracle Databaseのアップグレードの再実行」の説明に従って再度アップグレードを実行します。

アップグレード後にDBMS_DSTパッケージを実行した場合にORA-01822が発生する

Oracle Database 11gリリース2(11.2)にアップグレードした後、DBMS_DSTパッケージを実行すると、「ORA-01882: タイムゾーンのリージョンが見つかりません」エラーが発生する可能性があります。

このエラーは、ユーザーがタイムゾーン・ファイルのバージョンを誤って設定したことが原因で、データベースに複数のタイムゾーン地域のIDが不正に格納されている場合に戻されます。次に例を示します。

ERROR at line 1:
@  ORA-01882: time zone region not found
@  ORA-06512: at "SYS.DBMS_DST", line 113
@  ORA-06512: at "SYS.DBMS_DST", line 1101
@  ORA-06512: at line 1

この問題を解決するには、「TIMESTAMP WITH TIME ZONEデータ型に関する警告の概要」の説明に従ってタイムゾーンのバージョンを更新し、「Oracle Databaseのアップグレードの再実行」の説明に従ってアップグレードを再実行します。

コンポーネントの状態の理解

アップグレードの最後には、すべてのコンポーネントがVALIDの状態でアップグレード後の状態ツールに表示される必要があります。次のリストは、表示される可能性のある他の状態の値とその説明です。

- NO SCRIPT
コンポーネント・アップグレード・スクリプトがORACLE_HOMEに見つかりませんでした。インストール・ログを確認し、コンポーネント・ソフトウェアをインストールし、catupgrd.sqlを再実行します。

- OPTION OFF
コンポーネントに必要なサーバー・オプションがインストールされていないか、またはサーバーとリンクされていません。V$OPTIONビューとインストール・ログを確認します。コンポーネントをインストールするか、必要なオプションをサーバーに再リンクしてから、catupgrd.sqlを再実行します。

- REMOVED
データベースから削除されたため、コンポーネントはアップグレードされませんでした。

- INVALID
アップグレードの完了時に、コンポーネントの一部のオブジェクトが無効でした。コンポーネントのアップグレード中にエラーが発生しなかった場合は、アップグレード全体を再実行しなくても、utlrp.sqlを実行することで、状態がVALIDに変わる可能性があります。utlrp.sqlを実行した後に、DBA_REGISTRYビューを確認します。

- UPGRADING
コンポーネントのアップグレードが完了していません。問題を解決して、catupgrd.sqlを再実行します。

関連項目:
「アップグレード後の状態ツールの概要」

アップグレード全体が完了する前にDBUAにより無効なコンポーネントにXマークを付けることが可能

アップグレードの進行中に、アップグレード処理ウィンドウで、DBUAにより無効なコンポーネントにXマークを付けることができます。無効なコンポーネントは、再コンパイルの実行後に再検証できます。utlrp.sqlの再コンパイルが実行された後に、DBUAの「アップグレード結果」ページで最終的なコンポーネントの状態を確認してください。

関連項目:
「コンポーネントの状態の理解」

Oracle Databaseのアップグレードの再実行

次の手順に従って、catupgrd.sqlスクリプトでアップグレードを再実行できます。

アップグレードを再実行するには、次の手順を実行します。

1. 次のようにデータベースを停止します。

SQL> SHUTDOWN IMMEDIATE

2. UPGRADEモードでデータベースを再起動します。

SQL> STARTUP UPGRADE

3. 成功したかどうかを後で確認するために、結果をログ・ファイルにスプールするようにシステムを設定します。

SQL> SPOOL upgrade.log

4. catupgrd.sqlを再実行します。

SQL> @catupgrd.sql

注意:
catupgrd.sqlスクリプトは、必要な回数だけ再実行できます。このスクリプトを最初に実行した際は、エラー・メッセージが戻されません。スクリプトを再実行すると、ORA-00001メッセージが表示されます。このメッセージは無視して問題ありません。

5. utlu112s.sqlを再実行します。

SQL> @utlu112s.sql

Oracle Databaseのアップグレードの取消し

「手動アップグレードを行う場合のOracle Databaseのバックアップ」の手順を完了してデータベースのバックアップを作成済の場合、アップグレードを取り消す最も簡単な方法は、次の手順で説明するようにバックアップをリストアすることです。

以前のバックアップをリストアすることによってアップグレードを取り消すには、次の手順を実行します。

1. 以前のリリースのOracleホーム・ディレクトリの所有者としてシステムにログインします。

2. RMANにサインオンします。

rman "target / nocatalog"

3. 次のRMANコマンドを発行します。

STARTUP NOMOUNT
RUN
{
RESTORE CONTROLFILE FROM 'save_controlfile_location';
ALTER DATABASE MOUNT;
RESTORE DATABASE FROM TAG before_upgrade
ALTER DATABASE OPEN RESETLOGS;
}

Oracle ASMインスタンスのアップグレードの概要

Oracle ASMをアップグレードする場合は、Oracle Grid Infrastructureホーム・ディレクトリにあるOracle Universal Installer(OUI)の実行可能ファイルを使用してOracle ASMインスタンスをアップグレードすることをお薦めします。OUIは、以前のリリース・レベルのOracle ASMインスタンスを検出すると、自動的にアップグレード・モードに切り替わります。

Oracle ASM Configuration Assistantを使用すると、既存のOracle ASMインスタンスを現行のソフトウェア・レベルにアップグレードして、古いOracle ASMインスタンスから最新のOracle Grid Infrastructureホームにアップグレードできます。

Oracle ASMインスタンスをOracle Restart 11gリリース2(11.2)構成にアップグレードできます。Oracle Universal Installer(OUI)を使用して、Oracle ASMインスタンスをアップグレードする方法をお薦めします。

Oracle Database 11g以上を実行している環境では、クラスタ化されたOracle ASMインスタンスに対してローリング・アップグレードを実行することもできます。

関連項目:

- OUIを使用したOracle ASMインスタンスのアップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

- Oracle ASM Configuration Assistantを使用したOracle ASMインスタンスのアップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

- OUIを使用したOracle Restart構成でのOracle ASMインスタンスのアップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

- Oracle ASMのローリング・アップグレードの実行手順の詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

4 Oracle Databaseのアップグレード後の作業

Oracle Databaseをアップグレードする手順を実行した後は、必要な作業を行い、新しいリリースの推奨事項を考慮する必要があります。

この章の項目は次のとおりです。

- Oracleデータ・ディクショナリの現在の状態の表示方法

- Oracle Databaseのアップグレード後のOPatchコマンドについて

- Oracle Databaseのアップグレード後に必要な作業

- Oracle Databaseのアップグレード後の推奨作業

- 手動によるOracle Databaseのアップグレード後にのみ行う作業

- Oracle Grid Infrastructureのアップグレード後に必要な作業

- Oracle ASMのアップグレード後に必要な作業

- Oracle ASMのアップグレード後の推奨作業

Oracleデータ・ディクショナリの現在の状態の表示方法

dbupgdiag.sqlスクリプトを実行することで、データ・ディクショナリの現在の状態に関するアップグレードおよび移行の診断情報を収集できます。スクリプトは、アップグレード前にソース・データベース上、およびアップグレード後にSYSユーザーとしてアップグレードされたデータベース上のどちらででも、SQL*Plusで実行できます。

関連項目:
My Oracle Support (http://support.oracle.com)のNote 556610.1「Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)」

ディクショナリの現在の状態を表示するには、次の例のようなSQL問合せを実行します。

SQL> spool /tmp/regInvalid.out
SQL> set echo on
-- query registry
SQL> set lines 80 pages 100
SQL> select substr(comp_id,1,15) comp_id,substr(comp_name,1,30)
comp_name,substr(version,1,10) version,status
from dba_registry order by modified;

無効なオブジェクトを問い合せるには、次のようなSQL問合せを実行します。

SQL> select substr(owner,1,12) owner,substr(object_name,1,30) object,substr(object_type,1,30) type, status
from dba_objects where status <> 'VALID'order by owner, type;
SQL> spool off
SQL> set echo off

Oracle Databaseのアップグレード後のOPatchコマンドについて

Oracle Databaseをアップグレードした後で、新規OracleホームからOPatchコマンドを実行する必要があります。たとえば、システムに現在インストールされているものの正確で完全なインベントリをリストするには、新規Oracleホームからlsinventoryコマンドを実行します。

関連項目:
OPatchの構文およびコマンドは、Oracle OPatchユーザーズ・ガイドfor Windows and UNIXの付録Aを参照してください。

Oracle Databaseのアップグレード後に必要な作業

アップグレードを手動で行ったか、Database Upgrade Assistant(DBUA)を使用して自動的に行ったかに関係なく、Oracle Databaseをアップグレードした後、使用環境に対して指定されている必要な作業を完了する必要があります。また、使用している環境についての重要な情報も考慮する必要があります。次の項目で、必要な手順と情報について説明します。

- 手動アップグレード後のLinuxおよびUNIXシステム上での環境変数の設定

- Oracle Databaseのアップグレード後のリカバリ・カタログのアップグレード

- Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード

- Oracle Databaseのアップグレード後のDBMS_STATSパッケージで作成された統計表のアップグレード

- Oracle Databaseのアップグレード後の外部認証されたSSLユーザーのアップグレード

- Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール

- Oracle Databaseのアップグレード後のOracle Application Expressの構成の更新

- Oracle Databaseのアップグレード後の外部ネットワーク・サービスへのファイングレイン・アクセスの構成

- Oracle Databaseのアップグレード後のOracle Database Vaultの有効化およびDV_PATCH_ADMINロールの取消

手動アップグレード後のLinuxおよびUNIXシステム上での環境変数の設定

ご使用のオペレーティング・システムがLinuxまたはUNIXで、かつOracle Databaseを手動でアップグレードした場合は、特定の環境変数が新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。DBUAでは、自動的に環境変数に対して必要な変更が行われることに注意してください。また、クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。

次の環境変数が新しいOracleホームのディレクトリを指していることを確認します。

- ORACLE_HOME

- PATH

関連項目:

- 手順については、『Oracle Database管理者ガイド』を参照してください。

- ご使用のオペレーティング・システムでのその他の重要な環境変数の設定は、オペレーティング・システム固有のOracle Databaseのインストレーション・ガイドを参照してください。

Oracle Databaseのアップグレード後のoratabおよびスクリプトが新しいOracleホームを指すようにする設定

Oracle Databaseを新しいリリースにアップグレードした後に、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 11gリリース用に作成された新しいOracleホームを指していることを確認する必要があります。DBUAではoratabは自動的に新しいOracleホームを指しますが、アップグレードにどの方法を使用しても、クライアント・スクリプトを確認する必要があります。

関連項目:
『Oracle Database管理者ガイド』

Oracle Databaseのアップグレード後のリカバリ・カタログのアップグレード

リカバリ・カタログのアップグレード、およびUPGRADE CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の手順に関する項目を参照してください。

Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード

データベースのアップグレードを完了した後、アップグレード前情報ツールによってタイム・ゾーン・ファイルをアップグレードするよう指示された場合は、DBMS_DST PL/SQLパッケージを使用してこのファイルをアップグレードします。

Oracle Databaseでは複数のバージョンのタイム・ゾーン・ファイルが提供されており、互いに関連付けられている2種類のファイルがあります。1つはデータベースで定義されているすべてのタイム・ゾーンを含む大きなファイルで、もう1つは最も一般的に使用されるタイム・ゾーンのみを含む小さいファイルです。大きいバージョンはtimezlrg_version_number.dat、小さいバージョンはtimezone_version_number.datと指定されます。ファイルは、Oracle Databaseホーム・ディレクトリ下のoracore/zoneinfoサブディレクトリにあります。

関連項目:

- My Oracle Support (https://support.oracle.com)のNote ID 977512.1「Updating the RDBMS DST version in 11gR2 (11.2.0.1 and up) using DBMS_DST」

- 「TIMESTAMP WITH TIME ZONEデータ型に関する警告の概要」

- 『Oracle Databaseグローバリゼーション・サポート・ガイド』で、タイムゾーン・ファイルおよびTIMESTAMP WITH TIME ZONEデータのアップグレード手順に関する説明を参照してください。

Oracle Databaseのアップグレード後のDBMS_STATSパッケージで作成された統計表のアップグレード

DBMS_STATS.CREATE_STAT_TABLEプロシージャを使用して統計表を作成した場合、次のプロシージャを実行してこれらの表をアップグレードします。

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('scott', 'stat_table');

この例で、SCOTTは統計表の所有者で、STAT_TABLEは統計表の名前です。各統計表にこのプロシージャを実行します。

Oracle Databaseのアップグレード後の外部認証されたSSLユーザーのアップグレード

Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)からのアップグレード時に、外部認証されたSSLユーザーを使用している場合は、SSL外部ユーザー変換(extusrupgrade)スクリプトを実行してそれらのユーザーをアップグレードする必要があります。スクリプトの構文は次のとおりです。

ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring
<hostname:port_no:sid> --dbuser <db admin> --dbuserpassword
<password> -a

注意:
Oracle Database 10gリリース2(10.2)以上のリリースからアップグレードしている場合は、このコマンドを実行する必要はありません。

関連項目:
extusrupgradeスクリプトの詳細は、を参照してください。

Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール

Oracle Textナレッジ・ベースはOracle Database 11gリリースの付属製品の一部ですが、新しいOracle Database 11gへのアップグレード後すぐに使用できるようにはなっていません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースをインストール・メディアからインストールする必要があります。

Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、アップグレード後に再生成する必要があります。これらの変更は、指定されたOracleホームにインストールされているすべてのデータベースに影響します。

関連項目:

- Oracle Textナレッジ・ベースの詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。

- 付属製品については、ご使用のプラットフォーム固有の『Oracle Databaseインストレーション・ガイド』のインストール後の作業に関する項を参照してください。

Oracle Databaseのアップグレード後のOracle Application Expressの構成の更新

元のデータベースにApplication Expressバージョン3.2以上が含まれていた場合は、新しいOracle Database 11gリリースにアップグレードした後に必要な追加の構成はありません。

Oracle Express Edition(XE)データベース以外のデータベースを使用していた場合で、前のバージョンのApplication Express(HTML DB)が含まれている場合は、アップグレード中に最新バージョンが自動的にインストールされます。新しいOracle Database 11gリリースと併用するには、インストール後の一連の手順を実行して、Application Expressを構成する必要があります。

関連項目:
Application Expressのインストール後作業の詳細は、『Oracle Application Expressインストレーション・ガイド』を参照してください。

Oracle Express Edition(XE)データベースを使用している場合は、XE環境向けの前バージョンのApplication Expressが含まれています。次のURLに用意されている、Oracle XEとOracle Application Expressの相違点を説明したOTNのドキュメントを参照してください。

http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html

XEエディションのApplication Expressで使用できるデータベース管理機能はApplication Expressバージョン3.2では使用できませんが、Oracle Enterprise Manager Database Controlを追加でインストールすれば、データベース管理用のグラフィカル・インタフェースが提供されます。

Oracle Databaseのアップグレード後の外部ネットワーク・サービスへのファイングレイン・アクセスの構成

Oracle Database 11gには、Oracle XML DBを使用するUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、またはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。これらのパッケージを使用するアプリケーションがある場合は、Oracle XML DBがまだインストールされていなければインストールする必要があります。これらのパッケージを前のリリースと同様に動作させるには、データベースのネットワーク・アクセス制御リスト(ACL)を構成することも必要です。

次の例では、最初にhost_nameに現在割り当てられているACLを検索します。見つかると、この例では、user_nameがまだCONNECT権限を持っていない場合にかぎり、ACL内でこの権限をユーザーに付与します。host_name用のACLが存在しない場合、この例では、ACL_nameという新しいACLを作成し、user_nameにCONNECT権限を付与し、このACLをhost_nameに割り当てます。

DECLARE
acl_path  VARCHAR2(4000);
BEGIN
SELECT acl INTO acl_path FROM dba_network_acls
WHERE host = 'host_name' AND lower_port IS NULL AND upper_port IS NULL;
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(acl_path,
'user_name','connect') IS NULL THEN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(acl_path,
'user_name', TRUE, 'connect');
END IF;
EXCEPTION
WHEN no_data_found THEN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('ACL_name.xml',
'ACL description', 'user_name', TRUE, 'connect');
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('ACL_name.xml','host_name');
END;
COMMIT;

注意:
変更を有効にするには、トランザクションをコミットする必要があります。

関連項目:
一部のユーザーはホストAに接続し、別のユーザーはホストBに接続するなど、より複雑な状況については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

Oracle Databaseのアップグレード後のOracle Database Vaultの有効化およびDV_PATCH_ADMINロールの取消

Oracle Database Vaultを使用している場合は、データベースをアップグレードする前にこれを無効にするように指示がありました。ここで、次を行う必要があります。

- Database Vaultの有効化

- SYSアカウントからのDatabase VaultのDV_PATCH_ADMINロールの取消

関連項目:

- 「Oracle Database Vaultを使用しているデータベースのアップグレードの概要」

- 『Oracle Database Vault管理者ガイド』のOracle Database Vaultの有効化および無効化に関する付録

- 『Oracle Database Vault管理者ガイド』のOracle Database Vault管理者の手動デプロイに関する項

- 『Oracle Database Vault管理者ガイド』のOracle Database Vaultのインストール後の手順に関する付録

Oracle Databaseのアップグレード後の推奨作業

データベースをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。これらはアップグレードを手動で行ったかDBUAを使用して行ったかに関係なく推奨される作業です。

- すべてのデータベースのアップグレード後の推奨作業

- Oracle Database 10gリリース1(10.1)データベースのアップグレード後の推奨作業

- Oracle Express Edition Databaseのアップグレード後の推奨作業

- Oracle RACデータベースのアップグレード後の推奨作業

すべてのデータベースのアップグレード後の推奨作業

データベースをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。

- データベースのバックアップ

- パスワードのリセットによる大/小文字区別の強制

- Oracle Grid Infrastructureでの変更の理解

- Oracle ASMとOracle Grid Infrastructureのインストールとアップグレードの理解

- 新機能の適宜追加

- 必要な新しい管理手順の作成

- 表領域アラートのしきい値の設定

- ロールバック・セグメントから自動UNDOモードへの移行

- Oracle Data Guard Brokerの構成

- LONGデータ型からLOBデータ型への表の移行

- アップグレードした本番データベースのテスト

データベースのバックアップ

必ず本番データベースの全体バックアップを作成してください。

関連項目:
データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

パスワードのリセットによる大/小文字区別の強制

Oracle Database 11gリリース1(11.1)以上では、パスワードに大/小文字の区別を強制できるようになりました。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。これまでのリリースでは、パスワードの大/小文字は区別されませんでした。

パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいデータベース・インスタンスの場合は、追加の作業や追加の管理要件はありません。データベースをアップグレードした場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。

また、デフォルトを変更して、パスワード検証機能で大/小文字が区別されるようにすることもできます。通常のユーザーの場合は、初期化パラメータsec_case_sensitive_logonをfalseに設定します。

sql> alter system set sec_case_sensitive_logon=false;

sysdbaユーザーおよびsysoperユーザーの場合は、新しいコマンドライン・スイッチignorecaseを使用して、新しいorapwファイルを生成できます。

注意:
Oracle Databaseリリース11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

関連項目:
『Oracle Databaseセキュリティ・ガイド』

Oracle Grid Infrastructureでの変更の理解

Oracle Clusterware 11gリリース2およびOracle ASM 11gリリース2は、両方ともOracle Grid Infrastructureの一部としてインストールされます。

Oracle Grid Infrastructureは、単一サーバーにインストールした場合、Oracle ASMとともにOracle Restartインストールとしてデプロイされます。クラスタにインストールした場合は、Oracle ASMとともにOracle Clusterwareインストールとしてデプロイされます。

Oracle Restartは、単一インスタンス環境におけるOracle Databaseの可用性を向上します。Oracle Restartをインストールし、データベース、リスナー、Oracle ASMインスタンスなどのOracle Databaseソフトウェア・スタックの一部が一時的に失敗した場合、失敗したコンポーネントはOracle Restartによって自動的に再起動されます。また、これらのすべてのコンポーネントは、データベース・ホスト・コンピュータが再起動されるときに、Oracle Restartによって起動されます。コンポーネントは、コンポーネント間の依存性を考慮して適切な順序で起動されます。

Oracle Clusterwareは、単一サーバーを単一システムとして連携するようにクラスタ化できるポータブル・クラスタ・ソフトウェアです。Oracle RACに必須なインフラストラクチャも提供します。また、Oracle Clusterwareでは、クラスタ内の任意のOracleアプリケーションまたはその他のアプリケーションを保護できます。いずれの場合でも、Oracle Clusterwareはそれらのシステムにおけるインテリジェント機能としてクラスタ・ノード間の必要な連携を確実にします。

Oracle ASMとOracle Grid Infrastructureのインストールとアップグレードの理解

以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Database 11gリリース2(11.2)では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされ、また、Oracle RACなどとともにクラスタにインストールされた場合にはOracle ClusterwareとOracleホームを共有し、スタンドアロンサーバーにインストールされた場合にはOracle RestartとOracleホームを共有します。

既存のOracle ASMインスタンスがある場合は、Oracle Grid Infrastructureのインストール中またはインストール後にアップグレードできます。ただし、Oracle ClusterwareによってOracle ASMが管理されるのは、Oracle ASMがGrid Infrastructureホームで実行されている場合にかぎられるため、Oracle ASMをアップグレードするまでは、いくつかのOracle ASM機能が無効になったり、Oracle ClusterwareによるOracle ASMの管理が正しく機能しないことに注意してください。このことから、Oracle Clusterwareのアップグレードと同時にOracle ASMをアップグレードしない場合は、Oracle ASMを直後にアップグレードすることをお薦めします。

Oracle ASM Configuration Assistant(ASMCA)を使用してOracle ASMインスタンスをアップグレードできます。

関連項目:

- 「Oracle Grid Infrastructureのアップグレード後に必要な作業」

- 「Oracle ASMのアップグレードの準備」

- 「Oracle ASMのアップグレード」

- 「Oracle ASMのアップグレード後の推奨作業」

- 手動によるOracle Databaseのアップグレード後にのみ行う作業

旧リリースでは、Database Upgrade Assistant(DBUA)を使用してOracle DatabaseまたはOracle ASMをアップグレードできました。現在はそうではありません。DBUAを使用してアップグレードできるのは、Oracle Databaseインスタンスのみです。Oracle ASMをアップグレードするには、Oracle ASM Configuration Assistant(ASMCA)を使用します。

新機能の適宜追加

『Oracle Database新機能ガイド』では、新しいOracle Database 11gリリースで使用可能な多くの新機能について説明されています。どの新機能がデータベースおよびアプリケーションに有効かを判断して、これらの機能を使用する計画を立ててください。

新しいOracle Databaseソフトウェアを使用するためにすぐに変更する必要はありません。データベースおよびそれに対応するアプリケーションに、これらの拡張機能を徐々に取り入れることもできます。

第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」では、新しいOracle Database 11gリリースの機能を利用するためにアプリケーションを拡張する方法について説明します。ただし、新機能を実装する前にアプリケーションをテストし、アップグレードしたデータベース上でアプリケーションを正常に動作させる必要があります。

必要な新しい管理手順の作成

新しいOracle Database 11gリリースの機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。

それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。

表領域アラートのしきい値の設定

アップグレードされたOracle Database 11gリリース1(11.1)データベースでは、表領域アラートが無効になっています(しきい値がNULLに設定されています)。データベース内の監視対象の表領域を指定し、適切なしきい値を設定する必要があります。

新しく作成されたOracle Database 11gリリース1(11.1)データベースのデフォルトのしきい値は次のとおりです。

- 警告(表領域の使用率が85%の場合)

- クリティカル(表領域の使用率が97%の場合)

ロールバック・セグメントから自動UNDOモードへの移行

この項では、ロールバック・セグメント(手動UNDO管理)を使用するデータベースを、アップグレード中に自動UNDO管理へ移行する手順を説明します。

Oracle Database 11gリリース1(11.1)以上では、デフォルトのUNDO領域管理モードは自動UNDO管理です。システムで使用するUNDO領域管理モードは、次のようにUNDO_MANAGEMENT初期化パラメータで指定します。

- UNDO_MANAGEMENT=AUTOの場合(またはUNDO_MANAGEMENTを設定しない場合)は、データベース・インスタンスは自動UNDO管理モードで起動します。
UNDO_MANAGEMENT初期化パラメータがNULLの場合のデフォルトは、Oracle Database 11gリリース1(11.1)では自動UNDO管理モードですが、前のリリースでは手動UNDO管理モードです。したがって、前のリリースをOracle Database 11gにアップグレードする際は注意が必要です。

- UNDO_MANAGEMENT=MANUALの場合、UNDO領域はロールバック・セグメントとして外部に割り当てられます。

現在ロールバック・セグメントを使用してUNDO領域を管理している場合は、Oracle Database 11gリリース1(11.1)データベースを自動UNDO管理に移行することをお薦めします。移行した場合、新しくアップグレードしたデータベースを自動UNDO管理を使用して開く前に、まずUNDO表領域を作成する必要があります。UNDO表領域に必要なサイズは、システムのワークロードおよびフラッシュバックの要件によって異なります。

自動UNDO管理に移行するには、次の手順を実行します。

1. UNDO_MANAGEMENT=MANUALに設定します。

2. インスタンスを再起動して標準的なビジネス・サイクルを一通り実行し、代表的なワークロードを取得します。このようにしてワークロードを評価し、自動UNDO管理で必要なUNDO表領域のサイズを計算します。

3. 標準的なビジネス・サイクルを完了したら次のファンクションを実行し、UNDO表領域のサイズと、UNDO表領域のサイズ変更に関するヘルプを収集します(このファンクションの実行にはDBA権限が必要です)

DECLARE
utbsiz_in_MB NUMBER;
BEGIN
utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION;
end;
/

このファンクションではPL/SQLプロシージャが実行され、システム構成およびシステムのロールバック・セグメントの使用状況を基にして、新しいUNDO表領域のサイズを求める方法に関する情報が提供されます。このファンクションはサイズ変更に関する情報を直接戻します。

4. 必要なサイズのUNDO表領域を作成し、UNDO_MANAGEMENT=AUTOに設定するかパラメータを削除して、自動UNDO管理を有効にします。

5. Oracle RAC構成の場合は、すべてのインスタンスでこれらの手順を繰り返します。

Oracle Data Guard Brokerの構成

Data Guard BrokerのプロパティLocalListenerAddressは、ブローカの通信方法およびREDOの転送の設定方法が変更されたため、リリース11.2.0.1では非推奨となりました。

ブローカのプロパティInitialConnectIdentifierは、DGConnectIdentifierに変更されました。DGConnectIdentifierの値は、常時、すべてのData Guardネットワーク・トラフィック用に使用されます。Oracle Databaseリリース10gの構成をアップグレードする場合は、最初にOracle Database 11gリリース1(11.1)にアップグレードする必要があり、InitialConnectIdentifierの値は、11gデータベースのDGConnectIdentifierの新しい値として保持されます。Oracle RACデータベースをアップグレードする場合、データベース管理者は、InitialConnectIdentifierプロパティの値がすべてのインスタンスに到達できることを確認する必要があります。

LONGデータ型からLOBデータ型への表の移行

LOBデータ型(BFILE、BLOB、CLOBおよびNCLOB)には、LONGデータ型よりも多くのメリットがあります。LONGデータ型とLOBデータ型の違いの詳細は、『Oracle Database概要』を参照してください。

Oracle9iリリース1(9.0.1)以上では、ALTER TABLE文を使用して、LONGデータ型の列をCLOBに、LONG RAWデータ型の列をBLOBに変更できます。

次の例では、long_tab表のlong_colというLONG列が、CLOBデータ型に変更されます。

SQL> ALTER TABLE Long_tab MODIFY ( long_col CLOB );

この方法でLONG列をLOBに変換した後も、表に設定されている既存の制約およびトリガーはすべて使用できます。ただし、表のすべての列で、ドメイン索引およびファンクション索引を含むすべての索引が使用不可となるため、ALTER INDEX ... REBUILD文を使用してすべての索引を再構築する必要があります。また、LONG列上のドメイン索引は、LONG列をLOBに変更する前に削除する必要があります。

関連項目:
LOBデータを使用するためのアプリケーションの変更の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

アップグレードした本番データベースのテスト

テスト・データベースを新しいOracle Database 11gリリースにアップグレードしてテストした場合、新しいOracle Database 11gリリースにアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。

新しいOracle Databaseで既存のアプリケーションが正常に動作するかどうかを確認するために、この新しくアップグレードされた本番データベースをテストします。また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションがアップグレードの前と同様に動作するかどうかを最初に確認してください。

関連項目:
Oracle Databaseでのアプリケーションの使用方法の詳細は、第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」を参照してください。

Oracle Database 10gリリース1(10.1)データベースのアップグレード後の推奨作業

Oracle Database 10gリリース1(10.1)またはOracle Database 10gリリース2(10.2)をアップグレードした後に次の作業を行うことをお薦めしますが、必須の作業ではありません。

- チェンジ・データ・キャプチャのアップグレード

- Secure HTTPの構成

- HTTPを介したXML DBリポジトリ・データへの匿名アクセスの提供

チェンジ・データ・キャプチャのアップグレード

Oracle Database 10gリリース2(10.2)以上では、非同期チェンジ・データ・キャプチャ(CDC)に、ソースおよびターゲット・データベースのオペレーティング・システムが同じである必要はなくなりました。この機能を使用すると、異なるオペレーティング・システムおよびOracle Databaseリリースを使用した異機種間CDC設定が可能になり、これによって既存のOracle9iリリース2(9.2)システムをソースとして活用できるようになります。

関連項目:
Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)データベースをチェンジ・データ・キャプチャを使用して新しいOracle Database 11gリリースにアップグレードする方法およびチェンジ・データ・キャプチャの分散HotLogモードでサポートされる構成の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

Secure HTTPの構成

Oracle XML DBへのHTTPSアクセスを構成するには、この項の説明に従って正しい構成情報を指定します。

データベースをOracle Database 10gリリース2(10.2)以上にアップグレードすると、Oracle XML DB構成ファイル用のXMLスキーマは自動的にアップグレードされ、リポジトリ内の/xdbconfig.xmlにあるOracle XML DB構成ファイルにhttp2-portとhttp2-protocolの2つの要素を追加できるようになります。これらの要素は、アップグレード時にデフォルトではOracle XML DB構成ファイルに追加されません。HTTPSに対するサポートが必要な場合は、構成ファイルを編集して、これらの2つの新しい要素(正確な位置についてはXMLスキーマを参照)を追加し、http2-protocolの値をtcpsに設定する必要があります。http2-portの値には、http-portとは異なる値を指定する必要があります。

Oracle XML DB構成ファイルのパラメータhttp2-portおよびhttp2-protocolを指定するのみでなく、Oracle XML DBでHTTPSを使用できるように、データベースおよびリスナーを構成する必要があります。また、次の手順をアップグレード前に実行しなかった場合は、アップグレード後に実行する必要があります。

Oracle XML DBでHTTPSを使用できるようにするには、次の手順を実行します。

1. HTTPリスナーおよびデータベースでSSLを使用できるようにします。

2. TCPSディスパッチャを起動できるようにします。

実行方法は、『Oracle XML DB開発者ガイド』を参照してください。

注意:
まだシステムにOracle XML DBがインストールされていない場合は、アップグレード作業中にインストールする必要があります。Oracle XML DBでは、アクセス制御リスト(ACL)を適切に維持する必要があります。

HTTPを介したXML DBリポジトリ・データへの匿名アクセスの提供

HTTPを介してXML DBリポジトリ・データに匿名アクセスする必要がない場合は、この手順を実行する必要はありません。HTTPを介してXML DBリポジトリ・データに匿名アクセスする必要がある場合は、この項の説明に従って正しい構成情報を指定する必要があります。管理者は、考えられるセキュリティ上の危険性を考慮し、匿名アクセスを許可するかどうかを十分に検討する必要があります。

データベースをOracle Database 10gリリース2(10.2)以上にアップグレードすると、リポジトリ内の/xdbconfig.xmlにあるOracle XML DB構成ファイル用のXMLスキーマは自動的にアップグレードされ、Oracle XML DB構成ファイルにallow-repository-anonymous-accessという要素を追加できるようになります。この要素はブール型で、trueまたはfalseという値を指定できます。この要素を使用すると、ANONYMOUSユーザー・アカウントをロック解除した場合でも、認証されていないアクセスをHTTPを介してOracle XML DBリポジトリ・データに行うことを禁止できます。allow-repository-anonymous-access要素は、アップグレード時にデフォルトではOracle XML DB構成ファイルに追加されませんが、この要素が欠落している場合はfalseと解釈されます。

したがって、Oracle Database 10gリリース2(10.2)以上にアップグレードすると、HTTPを介したXML DBリポジトリ・データへの匿名アクセスが無効になります。HTTPを介してXML DBリポジトリ・データに匿名アクセスする場合は、ANONYMOUSユーザー・アカウントをロック解除すること以外に、構成ファイルを変更してこの新しい要素をtrueに設定する必要があります。

注意:
リポジトリへの認証されていないアクセスを許可した場合は、セキュリティ上の危険性を伴う可能性があります。

関連項目:
allow-repository-anonymous-access要素、およびOracle XML DBの構成方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

Oracle Express Edition Databaseのアップグレード後の推奨作業

Oracle Express Editionのデータベースに含まれているのは、Standard EditionまたはEnterprise Editionのデータベースで使用できるコンポーネントのサブセットのみです。新しいOracle Database 11gリリースにアップグレードした後、Database Configuration Assistantを使用して追加のコンポーネントをデータベースにインストールできます。DBUAによるアップグレード中にEnterprise Manager Database Controlをインストールしなかった場合は、データベースに追加する他の任意のコンポーネントとあわせてインストールできます。

Oracle RACデータベースのアップグレード後の推奨作業

Oracle Real Application Clusters(Oracle RAC)11gリリース2(11.2)には、単一クライアント・アクセス名(SCAN)が導入されています。SCANは、パブリック・ネットワークで3つのIPアドレスに解決される単一の名前です。以前のリリースのOracle RACデータベースは、11gリリース2(11.2)にアップグレードされると、リモート・リスナーとしてSCANリスナーに登録され、引き続きすべてのノード・リスナーにも登録されます。SCANを使用するか、または引き続きノード・リスナーを使用するようにクライアントを構成できます。SCANを使用するようにすべてのクライアント接続を移行する場合は、REMOTE_LISTENERSパラメータからノード・リスナーを削除できます。ただし、ノード・リスナーのみがデータベースの専用サーバーを作成できるため、リスナー自体を削除することはできません。

関連項目:
単一クライアント・アクセス名(SCAN)の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

手動によるOracle Databaseのアップグレード後にのみ行う作業

DBUAを使用せず手動でOracle Databaseのアップグレードを実行している場合は、データベースをアップグレードした後で、追加作業を実行する必要があります。

- オラクル社が提供するアカウント用のパスワードの変更

- ORAPWDによるパスワード・ファイルの作成

- サーバー・パラメータ・ファイルへの初期化パラメータ・ファイルの移行

- Oracle Textのアップグレード

- Oracle Clusterware構成のアップグレード

- 新しいリリース用の初期化パラメータ・ファイルの調整

- Enterprise Managerの構成

- Oracle RACのCLUSTER_DATABASE初期化パラメータの設定

オラクル社が提供するアカウント用のパスワードの変更

アップグレード元のリリースによっては、新しいアカウントが提供されている場合があります。SYSおよびSYSTEM以外のオラクル社が提供するアカウントは、すべてロックしてパスワードを期限切れにし、アカウントのロックを解除したときに新しいパスワードの指定が要求されるようにすることをお薦めします。

注意:
Oracle Database 11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

次のSQL文を発行して、すべてのアカウントの状態を確認できます。

SQL> SELECT username, account_status
FROM dba_users
ORDER BY username;

次のSQL文を発行して、パスワードをロックまたは期限切れにします。

SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;

ORAPWDによるパスワード・ファイルの作成

REMOTE_LOGIN_PASSWORDFILE初期化パラメータがexclusiveまたはsharedに設定されている場合、ORAPWDでパスワード・ファイルを作成します。

関連項目:
パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

サーバー・パラメータ・ファイルへの初期化パラメータ・ファイルの移行

従来の初期化パラメータ・ファイルを使用している場合は、次の手順でサーバー・パラメータ・ファイルへ移行します。

1. 初期化パラメータ・ファイルがクライアント・コンピュータ上にある場合は、クライアント・コンピュータからサーバー・コンピュータに転送します。

注意:
Oracle RACを使用している場合は、すべてのインスタンス固有の初期化パラメータ・ファイルを単一の初期化パラメータ・ファイルに結合する必要があります。インスタンス固有の初期化パラメータ・ファイルの結合方法およびクラスタ・データベース用のサーバー・パラメータ・ファイルの使用方法については、次のマニュアルを参照してください。

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- ご使用のオペレーティング・システム用の『Oracle Real Application Clustersインストレーション・ガイド』

2. CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを作成します。この文は、初期化パラメータ・ファイルを読み取り、サーバー・パラメータ・ファイルを作成します。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。

3. 新しく作成されたサーバー・パラメータ・ファイルを使用して、インスタンスを起動します。

関連項目:

- サーバー・パラメータ・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

- CREATE SPFILE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle Textのアップグレード

新しいOracle Database 11gリリースへアップグレードした後、次のファイルを以前のOracleホームから新しいOracleホームにコピーします。

- ステミング・ユーザー・ディクショナリ・ファイル

- ユーザーが変更したKOREAN_MORPH_LEXERディクショナリ・ファイル

- USER_FILTER実行可能ファイル

これらのファイルは、指定されたOracleホームにインストールされているすべてのデータベースに影響します。

これらのファイルのリストは、次の方法で取得できます。

1. $ORACLE_HOME/ctx/admin/ctxf102.txtを検索する

2. データベース・ユーザーSYS、SYSTEM、またはCTXSYSで、$ORACLE_HOME/ctx/admin/ctxf102.sqlを実行する

Oracle Textの索引でKOREAN_LEXERを使用している場合、これはOracle 9iで非推奨になり、Oracle Database 10gリリース2(10.2)でサポート対象外になっているため、My Oracle SupportのNote 300172.1でKOREAN_LEXERからKOREAN_MORPH_LEXERに手動で移行する方法を参照してください。

関連項目:

- これらのファイルの詳細は、『Oracle Textリファレンス』を参照してください。

- 以前のリリースのOracle Textからのアプリケーションのアップグレードについては、『Oracle Textアプリケーション開発者ガイド』を参照してください。

- My Oracle Support(https://support.oracle.com)

Oracle Clusterware構成のアップグレード

Oracle Clusterwareを使用している場合は、データベースのOracle Clusterwareキーをアップグレードする必要があります。

リリース11.2.0.3のsrvctlを実行してデータベースをアップグレードします。次に例を示します。

%11.2.0.3_ORACLE_HOME/bin/srvctl upgrade database -d <name> -o 11.2.0.3_ORACLE_HOME

注意:
デフォルトでは、指定したユーザーはサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者のリストに追加することをお薦めします。
関連項目: CRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください

新しいリリース用の初期化パラメータ・ファイルの調整

Oracle Databaseの新しいリリースごとに新しい初期化パラメータが導入され、非推奨となったり、廃止される初期化パラメータもあります。ご使用のシステムに有効な新しい初期化パラメータを使用するために、これらの変更に対してパラメータ・ファイルを調整する必要があります。また、DBUAを使用しないで手動アップグレードを実行した場合、tnsnames.oraファイルには新しい構成情報と設定が自動的に移入されません。したがって、手動でtnsnames.oraを更新し、local_listenerおよびremote_listenerパラメータ参照を調節する必要がある場合があります(これらを解決する必要がある場合)。

関連項目:

- 新しいOracle Database 11gリリースの新しい初期化パラメータのリストおよび各パラメータの詳細は、『Oracle Databaseリファレンス』のOracle Databaseリファレンスの新機能に関する項を参照してください。

- 新しいOracle Database 11gリリースで廃止および非推奨になった初期化パラメータのリストは、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

COMPATIBLE初期化パラメータの設定

COMPATIBLE初期化パラメータは、ご使用のデータベースの互換レベルを制御します。データベースを元のリリースにダウングレードする必要がない場合は、新しいデータベースで必要な互換性レベルに基づいてCOMPATIBLE初期化パラメータを設定します。

COMPATIBLE初期化パラメータ値を増やすには、次の手順を実行します。

1. COMPATIBLE初期化パラメータ値を増やす前に、データベースのバックアップを取ります(オプション)。
COMPATIBLE初期化パラメータ値を増やすことによって、現在のデータベースが以前のリリースのOracle Databaseとは非互換になる可能性があります。バックアップを取っておくと、必要に応じて以前のリリースに戻すことができます。

関連項目:
バックアップの実行の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2. サーバー・パラメータ・ファイルを使用している場合は、次の手順を実行します。

1. サーバー・パラメータ・ファイルを更新して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータを11.0.0に設定するには、次の文を入力します。

SQL> ALTER SYSTEM SET COMPATIBLE = '11.0.0' SCOPE=SPFILE;

2. インスタンスを停止し、再起動します。

注意:
HARD互換のストレージ(Hardware Assisted Resilient Data)を使用するシステムをアップグレードする場合は、次の点を考慮してください。

- COMPATIBLEパラメータが11.0.0より前のリリース番号に設定されている場合は、サーバー・パラメータ・ファイル(SPFILE)をHARDストレージに配置することはできません。

- COMPATIBLEパラメータが11.0.0に設定されている場合は、オプションでサーバー・パラメータ・ファイルをHARDストレージに配置することができます。

デフォルトのSPFILEの位置(ORACLE_HOME/dbs)はHARD互換のストレージ・システム上ではないと考えられるため、SPFILEの位置を指定するパラメータ・ファイルを指定することが必要になる場合があります。

関連項目:
HARDストレージの詳細は、『Oracle Database高可用性概要』または『Oracle Database概要』を参照してください。

3. 初期化パラメータ・ファイルを使用している場合は、次の手順を実行します。

1. インスタンスが実行している場合は、停止します。

SQL> SHUTDOWN IMMEDIATE

2. 初期化パラメータ・ファイルを編集して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータを11.0.0に設定するには、初期化パラメータ・ファイルに次のように入力します。

COMPATIBLE = 11.0.0

3. STARTUPを使用してインスタンスを起動します。

注意:
ASMディスク・グループを使用している場合、ディスク・グループの互換性属性は、init.oraのデータベース互換性パラメータの値以下である必要があります。

tnsnames.oraおよびリスナー・パラメータの構成

手動アップグレードの実行後、tnsnames.oraで解決する必要がある場合は、local_listenerおよびremote_listenerパラメータ参照を調節する必要がある場合があります。DBUAは、自動アップグレード時にネットワーク・ネーミングとリスナーの変更を処理しますが、手動アップグレード時には、tnsnames.oraもリスナーも変更されません。

関連項目:

- Oracle Database Net Servicesリファレンスのローカル・ネーミング・パラメータ(tnsnames.ora)に関する説明

- 『Oracle Database Net Services管理者ガイド』のインストール後のtnsnames.oraファイルの構成に関する説明

- ローカル・リスナーおよびリモート・リスナーに情報を登録する方法の詳細は、『Oracle Database Net Services管理者ガイド』のOracle Netリスナーの構成と管理に関する説明

- Windowsの『Oracle Real Application Clustersインストレーション・ガイド』のネット・サービス名(tnsnames.oraファイル)に関する説明

- 『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX Systems』のネット・サービス名(tnsnames.oraファイル)に関する説明

Enterprise Managerの構成

まだOracle Enterprise Managerを使用してデータベースを管理していない場合は、Enterprise Manager Database Controlをインストールして構成します。

Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlでデータベースを管理している場合は、次のコマンドを使用して構成を更新します。

emca -upgrade (db | asm | db_asm) [-cluster] [-silent] [parameters]

新しいOracle Database 11gリリースのOracleホームからこれを実行する必要があります。プロンプトが表示されたら、構成のアップグレードを行うOracleホームを入力します。

Enterprise Managerは、DBCAを使用して構成することもできます。「データベース・オプションの構成」オプションを選択してから、「Enterprise Managerリポジトリ」オプションを選択します。

関連項目:
『Oracle Enterprise Manager構成ガイド』

Oracle RACのCLUSTER_DATABASE初期化パラメータの設定

Oracle RACデータベースのアップグレードについては、「手動アップグレードを行う場合の新しいOracleホームの準備」に、クラスタ・データベースをアップグレードする前にCLUSTER_DATABASE初期化パラメータをfalseに設定するよう指示がありました。アップグレードが完了した時点で、この初期化パラメータをtrueに設定する必要があります。

Oracle Grid Infrastructureのアップグレード後に必要な作業

Oracle ASMリリース11.2以上のリリースは、Oracle Grid Infrastructureインストールの一部としてインストールされます。

クラスタのOracle ClusterwareとOracle ASMをアップグレードすると、Oracle ClusterwareとOracle ASMは両方ともGridホームと呼ばれる同じホームに配置されます。すべてのOracleソフトウェア・インストールを所有するインストール所有者を1人のみ割り当てることも、ロール割当て済の所有者を使用することもできますが、後者の場合は、Grid Infrastructureインストールに別のソフトウェア所有者、1つ以上のOracle Databaseインストールに別々のソフトウェア所有者を使用します。

次の作業は、別のインストール手順で実行されたOracle ASMからOracle Grid Infrastructureの一部としてインストールされるOracle ASMへのアップグレード後に行う必要があります。

- Grid Infrastructureのインストールでの環境変数の使用

- Oracle ASMの以前のリリースのOracle Grid Infrastructureへのアップグレード

関連項目:
ロール割当て済のインストール所有者の詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

Grid Infrastructureのインストールでの環境変数の使用

ご使用のオペレーティング・システムがLinuxまたはUNIXの場合、アップグレードを実行した後に環境変数の設定を変更する必要がある場合があります。

すべてのインストールに1人のOracleインストール所有者を使用する場合は、Oracle Databaseインスタンスをデータベース管理の一部として管理するかどうか、またはOracle ASMインスタンスをストレージ管理の一部として管理するかどうかに応じて、ORACLE_HOMEなどの環境変数をOracle DatabaseホームまたはGridホームに変更する必要があります。

ロール割当て済のOracleインストール所有者を使用し、Oracle Grid Infrastructure(Oracle ClusterwareとOracle ASM)ソフトウェアに別の所有者を使用する場合は、Grid Infrastructureインストール所有者の次の環境変数を、Grid Infrastructureホーム内のOracle ASMホームのディレクトリを指すように設定します。

- ORACLE_HOME

- PATH

また、oratabファイルおよびORACLE_HOME値を設定するOracle ASMのすべてのクライアント・スクリプトが、Grid Infrastructureホーム内のOracle ASMホームを指していることを確認します。

注意:
クラスタOracle ASMインストールをクラスタ用のOracle Grid Infrastructureにアップグレードする場合は、すべてのクラスタ・メンバー・ノードでこれらを確認してください。

関連項目:
ご使用のオペレーティング・システムでのその他の重要な環境変数の設定は、オペレーティング・システム固有のOracle Databaseのインストレーション・ガイドを参照してください。

Oracle ASMの以前のリリースのOracle Grid Infrastructureへのアップグレード

以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Database 11gリリース2(11.2)以上では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされます。クラスタにOracle Grid Infrastructureをインストールした場合、Oracle ClusterwareとともにGridホームに格納されます。単一サーバーにOracle Grid Infrastructureをインストールした場合、Oracle ASMはOracleホームをOracle Restartと共有します。

既存のOracle ASMをアップグレードする場合は、Oracle Grid Infrastructureのアップグレードを実行してOracle ASMをアップグレードする必要があります。Oracle ASMがインストールされていない場合、Oracle ASMを記憶域オプションとして使用するには、Oracle Databaseのインストールを開始する前に、Oracle Grid Infrastructureのインストールを完了してください。

関連項目:
ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』または『Oracle Databaseインストレーション・ガイド』を参照してください。

Oracle ASM Configuration Assistant(ASMCA)では、Oracle ASMインスタンス、ディスク・グループ、ボリュームおよびOracle ASMクラスタ・ファイルシステム(Oracle ACFS)のインストールおよび構成がサポートされています。さらに、非GUIユーティリティとしてASMCAコマンドライン・インタフェース(コマンド名はasmca)を使用できます。

asmcaコマンドを使用してアップグレードを個別に完了できます。ただし、Oracle ASMがアップグレードされるまでsrvctlなどのOracle ASM管理ツールが動作しないため、Oracle Clusterwareのアップグレード後すぐにasmcaを実行する必要があります。

注意:
クラスタ・アップグレードの場合、ASMCAによってローリング・アップグレードが実行されるのは、Oracle ASMの以前のリリースが11.1.0.6または11.1.0.7の場合のみです。それ以外の場合は、ASMCAにより、通常のアップグレードが実行され、すべてのOracle ASMインスタンスはクラスタのすべてのノードで停止されてから新しいGrid Infrastructureホームで起動されます。

Oracle ASMのアップグレードの準備

Oracle ASMのローリング・アップグレードを実行する場合は、次の情報に注意してください。

- アップグレードの一部としてホームの所有者を変更することはできません。たとえば、ユーザーgridでOracle Grid Infrastructureをインストールする場合、アップグレード前に、既存のOracle ASMのホームがユーザーgridによって所有されている必要があります。

- Oracle Clusterwareのアクティブなリリースは、11gリリース2(11.2)である必要があります。アクティブなリリースを確認するには、次のコマンドを入力します。

$ crsctl query crs activeversion

関連項目:
crsctlおよびCRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください

- 単一インスタンスのOracle ASMインストールをクラスタOracle ASMインストールにアップグレードできます。ただし、Oracle ASMがインストールされているノードからインストールを実行した場合、アップグレードできるのは既存の単一インスタンスのOracle ASMインストールのみです。リモート・ノードの単一インスタンスのOracle ASMインストールをアップグレードすることはできません。

- アップグレード処理を開始する前に、既存のOracle ASMインストールに対するリバランス操作が完了していることを確認する必要があります。

- アップグレード処理中に、Oracle ASMインスタンスをアップグレード状態に変更します。このアップグレード状態によってOracle ASM操作が制限されるため、開始後すぐにアップグレード処理を完了する必要があります。Oracle ASMインスタンスがアップグレード状態のときに実行できる操作は次のとおりです。

- ディスク・グループのマウントとディスマウント

- データベース・ファイルのオープン、クローズ、サイズ変更または削除

- インスタンスのリカバリ

- 固定ビューとパッケージの問合せ: 固定ビューに問い合せたり、dbms_diskgroupなどの固定パッケージを使用して無名PL/SQLブロックを実行できます。

Oracle ASMのアップグレード

この項の手順では、Oracle ASM Configuration Assistant(ASMCA)を使用してOracle ASMをアップグレードする方法について説明します。

Oracle ASMをアップグレードするには、次の手順を実行します。

1. Oracle Grid Infrastructureインストールのインストール所有者としてログオンします。

2. クラスタでアップグレードを行っており、ノードでアップグレードを開始する場合は、環境変数ASMCA_ROLLING_UPGRADEをtrueとして設定します。次に例を示します。

$ export ASMCA_ROLLING_UPGRADE=true

3. Oracle Grid Infrastructure 11gリリース2(11.2)のホームから、ASMCAを起動します。次に例を示します。

$ cd /u01/11.2/grid/bin
$ ./asmca

4. 「アップグレード」を選択します。
Oracle ASM Configuration Assistantによって、クラスタ内のすべてのノードのOracle ASMが連続的にアップグレードされます。

関連項目:
Oracle ASMのアップグレード計画の準備、およびOracle ASMアップグレードの開始、完了および停止の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

Oracle ASMのアップグレード後に必要な作業

この項では、Oracle ASMのアップグレード後に必要な作業と追加の考慮点について説明します。

- 環境変数の設定

- 単一インスタンスのOracle ASMのアップグレード

- クラスタOracle ASMのアップグレード

- Oracle ASMのアップグレード後の追加の考慮点

環境変数の設定

ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の環境変数が新しいOracle Database 11gリリースのディレクトリを指していることを確認します。

- ORACLE_HOME

- PATH

また、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 11gリリースのOracleホームを指していることを確認します。

注意:
ORACLE_HOME、PATHおよびoratabを確認する必要があるのは、手動でアップグレードした場合のみです。DBUAでは、oratabファイルは自動的に新しいOracleホームを指します。クライアント・スクリプトは、アップグレード方法に関係なく、確認する必要があります。
クラスタOracle ASMをアップグレードしている場合は、そのクラスタOracle ASMのインスタンスが構成されているすべてのノードでこれらを確認してください。

関連項目:
ご使用のオペレーティング・システムでのその他の重要な環境変数の設定は、オペレーティング・システム固有のOracle Databaseのインストレーション・ガイドを参照してください。

単一インスタンスのOracle ASMのアップグレード

次の手順では、Oracleホーム1(OH1)にOracle ASMがインストールされており、オペレーティング・システム・ユーザーがorauserであることが前提となっています。

Oracle ASMの単一インスタンスのアップグレードを実行するには、次の手順を実行します。

1. OUIおよびASMCAを使用して、orauserでOracle ASMをリリース11.2にアップグレードします。新しいOracle ASMリリース11.2は、Grid Infrastructureホームで実行されます。Oracle ASMは、引き続きorauserで実行されている必要があります。

2. orauserでOracle ASMインスタンスおよびリスナーを停止します。

3. rootで/etc/init.d/init.cssd stopを実行してCSSを停止します。

4. 新しいユーザー(asmuser)で、3つめのOracleホーム(OH3)に11.2をインストールします。ここでインストールするのはソフトウェアのみです。

5. rootで、OH3からlocalconfig resetを実行します。

6. /etc/oratabを更新し、OH3が+ASMエントリを含むOracleホームになるようにします。

7. listener.ora、sqlnet.oraおよびtnsnames.oraを、OH2からコピーします。

8. EMCPを実行し、Oracle ASMインスタンスのパスとconnect-stringロールを変更します。

9. ディスクの所有者がasmuserおよびOracle ASMのOSASMであることを確認します。これらのユーザーは、O660の権限セットを保持していることも必要です。

10. asmuserでリスナーを起動します。

11. asmuserでOracle ASMを起動します(SYSASMとして接続)。

12. コマンドGRANT sysasm TO sysを実行します。

クラスタOracle ASMのアップグレード

クラスタでOracle ASMのアップグレードを実行するには、次の手順を実行します。

1. OUIおよびASMCAを使用して、orauserでOracle ASMをリリース11.2にアップグレードします。新しいOracle ASMリリース11.2は、新しいOracleホーム2(OH2)で実行されている必要があります。Oracle ASMは、引き続きorauserで実行されている必要があります。

2. Oracle ASMおよびリスナーのリソースをCRSホームから停止します。

3. 新しいユーザー(crsなど)で、Grid Infrastructureホームのリリースと一致するように3つめのOracleホーム(OH3)に11.2をインストールします。ここでインストールするのはソフトウェアのみです。

4. CRSのホームから、次のコマンドを実行します。

srvctl remove listener -n node_name
srvctl add listener -n node_name -o OH3
srvctl modify asm -n node_name -i ASM_instance_name -o ORACLE_HOME_path

注意:
デフォルトでは、指定したユーザーはサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者のリストに追加することをお薦めします。
関連項目: CRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください

5. /etc/oratabを更新し、OH3が+ASMエントリを含むOracleホームになるようにします。

6. listener.ora、sqlnet.oraおよびtnsnames.oraを、OH2からコピーします。

7. EMCPを実行し、Oracle ASMインスタンスのパスとconnect-stringロールを変更します。

8. ディスクの所有者がasmuserおよびOracle ASMのOSASMであることを確認します。これらのユーザーは、O660の権限セットを保持していることも必要です。

9. 新しいOracle ASM 11gのORACLE_HOMEまたは新しいOracle Database 11gのORACLE_HOMEからOracle ASMおよびリスナーのリソースを起動します。

10. コマンドGRANT sysasm TO sysを実行します。

Oracle ASMインスタンスがクラスタ化されている場合は、Oracle ASMのローリング・アップグレードを実行することもできます。ローリング・アップグレードを使用すると、データベースの可用性に影響を与えることなく、Oracle ASMノードに対して個別にアップグレードやパッチの適用を行うことができるため、より長時間の稼働が可能になります。

関連項目:
Oracle ASMのローリング・アップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

Oracle ASMのアップグレード後の追加の考慮点

Oracle Grid Infrastructureバイナリのオペレーティング・システム・ユーザー所有権と1つ以上のデータベースのOracle Databaseインストール所有者を分けた場合は、「Oracle ASMのアップグレード後のロール割当て済のソフトウェアの所有者およびデータベースのアップグレード」の記述に従って、アップグレードしたOracle ASMまたはデータベースのホームのオペレーティング・システム・ユーザーを移行する必要があります。

Oracle ASMのアップグレード後のロール割当て済のソフトウェアの所有者およびデータベースのアップグレード

1つのソフトウェア・バイナリ所有者(oracleなど)から複数のロール割当て済のソフトウェア所有者ユーザー・アカウント(grid、oracle1、oracle2など)に移行する場合、既存のOracle ASMインストール所有者をOracle Grid Infrastructureインストールに使用するインストール所有者に変更します。

検討する例は次の3つです。

- Oracle ASMのオペレーティング・システム・ユーザーとしての既存ユーザーの保持

- 単一インスタンスのOracle ASMのオペレーティング・システム・ユーザーの変更

- Oracle RACデータベースのオペレーティング・システム・ユーザーの変更

関連項目:
Oracle Database 10gおよびOracle Database 11gとOracle ASMディスク・グループの互換性を保つ方法、およびOracle ASMアップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

Oracle ASMのオペレーティング・システム・ユーザーとしての既存ユーザーの保持

既存のOracle ASMインストールに使用したのと同じオペレーティング・システム・ユーザーをOracle Grid Infrastructureインストールに使用する場合は、Oracle Universal Installer(OUI)を実行してGrid Infrastructureインストールを実行し、アップグレード・オプションを選択します。Oracle Grid Infrastructureホームで、既存のOracle ASMインストールが以前のリリースから11gリリース2(11.2)に自動的にアップグレードされます。

単一インスタンスのOracle ASMのオペレーティング・システム・ユーザーの変更

以前のリリースのOracle ASMがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合に、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更する必要があるとします。これが役立つのは、Oracle ASMを使用するデータベースが2つあり、既存のデータベースと同じインストール所有者でOracle ASMをインストールした状態で、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようにOracle ASMのオペレーティング・システム・インストール所有者を変更する必要がある場合です(どちらのOracle Databaseインストール所有者にもOracle Grid Infrastructureバイナリ所有権がない場合)。

Oracle RACデータベースのオペレーティング・システム・ユーザーの変更

Oracle RACデータベースのオペレーティング・システム・ユーザーを変更する必要がある場合があります。たとえば、以前のリリースのデータベースがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合は、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更することを検討する必要があります。Oracle Databaseインストール所有者にGrid Infrastructureバイナリ所有権がない場合は、Oracle ASMのオペレーティング・システム・ユーザーを変更すると、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようになります。

Oracle ASMのアップグレード後の推奨作業

Oracle ASMをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。

- Oracle ASMパスワードのリセットによる大/小文字区別の強制

- Oracle ASMとOracle Databaseのディスク・グループの互換性の拡張

- Oracle ASMの優先読取りの障害グループの設定

次の作業を実行することも検討してください。これらの作業については、この章の前の方で説明しています。

- 「新機能の適宜追加」

- 「必要な新しい管理手順の作成」

Oracle ASMパスワードのリセットによる大/小文字区別の強制

Oracle Database 11gリリース1(11.1)以上では、パスワードに大/小文字の区別を強制できるようになりました。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。これまでのリリースでは、パスワードの大/小文字は区別されませんでした。

パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいOracle ASMインスタンスの場合は、追加の作業や追加の管理要件はありません。アップグレードしたOracle ASMのインスタンスの場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。

注意:
Oracle Database 11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

関連項目:
『Oracle Databaseセキュリティ・ガイド』

Oracle ASMとOracle Databaseのディスク・グループの互換性の拡張

Oracle Database 11gリリース1(11.1)以上では、ソフトウェア・バージョンをまたいでOracle DatabaseとOracle ASMのディスク・グループの互換性設定を拡張できます。

注意:
COMPATIBLE.RDBMS属性を拡張した場合、前の設定に戻ることはできません。したがって、COMPATIBLE.RDBMS属性を拡張する前に、ディスク・グループを使用するすべてのデータベースのCOMPATIBLE初期化パラメータの値が少なくともCOMPATIBLE.RDBMSの新しい設定に設定されていることを確認します。

互換性を拡張することにより、新しいリリースのみで使用可能な新機能が有効になります。ただし、こうすることで、ソフトウェアの古いリリースではディスク・グループが非互換になります。ディスク上の互換性を拡張する操作は元に戻せないことに注意してください。

compatible.rdbmsおよびcompatible.asm属性を使用して、データベース・インスタンスおよびOracle ASMインスタンスからディスク・グループにアクセスするのに必要な最小ソフトウェア・リリースをそれぞれ指定します。たとえば、次のALTER DISKGROUP文によって、ディスク・グループasmdg2のOracle ASMの互換性が拡張されます。

ALTER DISKGROUP asmdg2 SET ATTRIBUTE 'compatible.asm' = '11.1'

この場合、ディスク・グループを管理できるのはリリース11.1以上のOracle ASMソフトウェアのみですが、データベース・クライアントはリリース10.1以上であれば、このディスク・グループを使用できます。

関連項目:
ディスク・グループの互換性の詳細は『Oracle Databaseストレージ管理者ガイド』を、ALTER DISKGROUP文およびCREATE DISKGROUP文のディスク・グループ互換性属性の詳細は『Oracle Database SQL言語リファレンス』を参照してください。

Oracle ASMの優先読取りの障害グループの設定

Oracle ASMの管理者は、一部のディスクを他のディスクより優先して読取りI/O操作に使用するよう指定できます。Oracle ASMの優先読取りの障害グループを定義した場合、Oracle ASMでは常にプライマリ・コピーから読み取るのではなく、最も近いエクステントから読み取ることができます。

関連項目:

- 拡張クラスタへの障害グループの設定については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- Oracle ASMの優先読取りの障害グループ、および新しいASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータを指定してクラスタ内の各ノードに優先読取りディスクを含む障害グループ名をリストする方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

- ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

5 Oracle Databaseのアップグレード後のアプリケーションのアップグレード

新しいリリースのOracle Databaseにアップグレードすると、多くの新機能および拡張機能を使用できます。 新機能を利用する場合は、新しいリリースで実行されているアプリケーションをアップグレードする必要があります。

この章の内容は次のとおりです。

- アプリケーションのアップグレードの概要

- アップグレード時のアプリケーションの互換性の問題

- プリコンパイラおよびOCIアプリケーションのアップグレード

- SQL*PlusスクリプトおよびPL/SQLのアップグレード

- Oracle FormsまたはOracle Developerアプリケーションのアップグレード

アプリケーションのアップグレードの概要

新しいOracle Database 11gリリースで使用可能になった機能を使用しない既存のアプリケーションは、変更する必要がありません。新しいOracle Database 11gのデータベースで実行される既存のアプリケーションは以前のリリースと同様に機能し、同等以上のパフォーマンスを得ることができます。

新しいOracle Database 11gリリースにアップグレードすると、多くの新機能および拡張機能を使用できます。機能やファンクションが追加された機能がある一方、パフォーマンスが向上した機能もあります。アプリケーションをアップグレードする前に、これらの新機能を確認して、どの機能を使用するかを判断する必要があります。

関連項目:
新しいOracle Database 11gリリースで使用可能な機能については、『Oracle Database新機能ガイド』を参照してください。

アップグレード時のアプリケーションの互換性の問題

Oracle Databaseの異なるリリース間には、アプリケーションに影響を与えかねない互換性の問題がある場合があります。これらの互換性の問題は、Oracle Databaseの様々なリリースにおける相違によるものです。また、Oracle Databaseのリリースが新しくなるたびに、Oracleの新しい予約語が追加され、初期化パラメータおよびデータ・ディクショナリが変更されている場合があります。

Oracle Databaseソフトウェアを新しいリリースにアップグレードする場合は、アプリケーションでOracleの予約語が使用されていないか、アプリケーションにデータベースの初期化パラメータとの互換性があるか、アプリケーションにデータベースのデータ・ディクショナリとの互換性があるかを確認してください。新しいリリースのOracle Databaseソフトウェアでは、特定のリリースのオペレーティング・システムまたは特定のパッチ・セットの適用が必要な場合があります。

関連項目:

- 初期化パラメータおよびデータ・ディクショナリの変更の詳細は、付録A「Oracle Databaseのアップグレード後の動作の変更点」を参照してください。

- Oracleの予約語の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- オペレーティング・システムの要件の詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

プリコンパイラおよびOCIアプリケーションのアップグレード

プリコンパイラとOCIアプリケーションのアップグレード・パスは非常に似ています。この項では、これらのアプリケーションのアップグレード・オプションについて説明し、さらに必要に応じてプリコンパイラとOCIアプリケーションの違いを示します。

本番環境をアップグレードする前に、テスト環境を作成します。テスト環境には、アップグレードされたアプリケーションおよび新しいOracle Databaseソフトウェアが必要です。また、テスト環境では、アプリケーションの現実的なテストを行う必要があります。

この項の内容は次のとおりです。

- ソフトウェアのアップグレードおよびクライアント/サーバー構成の理解

- クライアント/サーバー・ソフトウェアをアップグレードする場合のアプリケーションの互換性規則

- プリコンパイラおよびOCIアプリケーションのアップグレード選択肢

関連項目:
これらのプログラミング環境の使用方法の詳細は、『Pro*C/C++プログラマーズ・ガイド』、『Pro*COBOLプログラマーズ・ガイド』および『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

ソフトウェアのアップグレードおよびクライアント/サーバー構成の理解

プリコンパイラおよびOCIアプリケーションのアップグレード選択肢を理解するには、まず、実行するソフトウェアのアップグレード・タイプおよびクライアント/サーバー構成を理解する必要があります。

この項の内容は次のとおりです。

- Oracle Databaseのソフトウェア・アップグレードのタイプ

- 使用可能なクライアント/サーバー構成

Oracle Databaseのソフトウェア・アップグレードのタイプ

Oracle Databaseをアップグレードすると、一般的にはメジャー・リリースにアップグレードするか、またはメンテナンス・リリースにパッチを適用します。Oracle Databaseのクライアントおよびサーバー・ソフトウェアに対して、次のタイプのアップグレードを行うことができます。

- データベースのメジャー・リリースのアップグレード

- データベースのメンテナンス・リリースのアップグレード

データベースのメジャー・リリースのアップグレード

このアップグレードは、リリース番号の最初の数字を変更します。たとえば、Oracle9iからOracle Database 11gへのアップグレードは、データベースのメジャー・リリースのアップグレードです。

データベースのメンテナンス・リリースのアップグレード

このアップグレードは、リリース番号の2番目の数字を変更します。たとえば、Oracle Database 11gリリース1(11.1)からOracle Database 11gリリース2(11.2)へのアップグレードは、データベースのメンテナンス・リリースのアップグレードです。

使用可能なクライアント/サーバー構成

プリコンパイラおよびOCIアプリケーションはクライアント/サーバー環境のクライアントで実行されます(ここでのサーバーは、Oracle Databaseサーバーです)。ご使用の環境で、次の1つ以上のクライアント/サーバー構成を使用できます。

- 異なるコンピュータ

- 同じコンピュータ上の異なるOracleホーム・ディレクトリ

- 同じOracleホーム

異なるコンピュータ

クライアント・ソフトウェアおよびサーバー・ソフトウェアが異なるコンピュータにあり、それぞれがネットワークで接続されています。クライアント環境とサーバー環境は独立しています。

同じコンピュータ上の異なるOracleホーム・ディレクトリ

クライアント・ソフトウェアおよびサーバー・ソフトウェアは同じコンピュータ上にありますが、異なるOracleホーム・ディレクトリにインストールされています。クライアント環境とサーバー環境は独立しています。

同じOracleホーム

クライアント・ソフトウェアおよびサーバー・ソフトウェアが同じコンピュータ上の同じOracleホームにインストールされています。この場合、サーバー・ソフトウェアをアップグレードすると、クライアント・ソフトウェアもアップグレードされます。

関連項目:
クライアント/サーバー環境の詳細は、『Oracle Database概要』および『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

クライアント/サーバー・ソフトウェアをアップグレードする場合のアプリケーションの互換性規則

この項では、Oracle Databaseクライアント・ソフトウェアまたはOracle Databaseサーバー・ソフトウェアをアップグレードする場合に適用される、互換性規則について説明します。この規則は、実行するソフトウェア・アップグレードのタイプおよびご使用のクライアント/サーバー構成に基づきます。

この項では、次のようなアップグレードの互換性規則について説明します。

- Oracle Databaseサーバー・ソフトウェアのアップグレード

- Oracle Databaseクライアント・ソフトウェアのアップグレード

注意:
この項では、「ソフトウェアのアップグレードおよびクライアント/サーバー構成の理解」で説明する用語を使用しています。

Oracle Databaseサーバー・ソフトウェアのアップグレード

次の規則は、Oracle Databaseサーバー・ソフトウェアをアップグレードする場合に適用されます。

- クライアント環境を変更しない場合、再リンクは不要

- Oracle Databaseサーバーの新/旧リリースでアプリケーションの実行が可能

クライアント環境を変更しない場合、再リンクは不要

クライアントとサーバーが異なるコンピュータにあるか、または同じコンピュータの異なるOracleホーム・ディレクトリにあるときに、クライアント・ソフトウェアを変更しないでOracle Databaseサーバー・ソフトウェアをアップグレードする場合は、アプリケーションをプリコンパイル、コンパイルまたは再リンクする必要はありません。このような場合、クライアント・ソフトウェアはサーバー・ソフトウェアから独立しており、サーバーに対し継続して機能します。

ただし、アプリケーションがOracle Databaseサーバーと同じOracleホームを使用している場合は、サーバー・ソフトウェアをアップグレードするとクライアント・ソフトウェアもアップグレードされます。この場合、「Oracle Databaseクライアント・ソフトウェアのアップグレード」の規則に従う必要があります。

注意:
Oracle Databaseサーバー・ソフトウェアと、プリコンパイラまたはOCIクライアント・ソフトウェア用に同じOracleホームを使用している場合、新しいプリコンパイラまたはOCIクライアント・ソフトウェアはインストールしないで、サーバー・ソフトウェアをアップグレードすることができます。この場合、クライアント・ソフトウェアはアップグレードされません。ただし、このような構成はお薦めしません。

Oracle Databaseサーバーの新/旧リリースでアプリケーションの実行が可能

データベース・サーバーに対してプリコンパイラまたはOCIアプリケーションを実行する場合、Oracleでは、クライアント・ソフトウェア・リリース以降のリリースのデータベース・サーバー・ソフトウェアを使用することをお勧めしますが、この構成が厳密に必要なわけではありません。たとえば、クライアント・ソフトウェアがOracle9iリリース2(9.2.0.8)である場合、サーバーに対してクライアント上でプリコンパイラ・アプリケーションを実行するには、Oracle9iリリース(9.2.0.8)以降のサーバー・ソフトウェアを使用することをお勧めします。

Oracle Databaseクライアント・ソフトウェアのアップグレード

ご使用のクライアント・ソフトウェアをアップグレードして、現行のサーバー・ソフトウェアと一致させることをお薦めします。たとえば、サーバーをOracle Database 11gリリース2(11.2)にアップグレードする場合は、クライアント・ソフトウェアもOracle Database 11gリリース2(11.2)にアップグレードすることをお薦めします。サーバー・ソフトウェアとクライアント・ソフトウェアのリリース番号を同じにしておくと、アプリケーションの最大の安定性を得ることができます。また、最新のOracle Databaseクライアント・ソフトウェアには、それまでのリリースにはなかった機能が追加されていたり、パフォーマンスが向上している可能性があります。

次の規則は、Oracle Databaseクライアント・ソフトウェアをアップグレードする場合に適用されます。

- アプリケーションは、より新しいライブラリにリンクできる

- 静的にリンクされたアプリケーションを常に再リンクさせる必要がある

- 動的にリンクされたアプリケーションの再リンク

アプリケーションは、より新しいライブラリにリンクできる

プリコンパイラ・アプリケーションによって生成されたコードは、サーバーのリリース以上のクライアント・ライブラリのリリースにリンクできます。

OCIアプリケーションは、そのアプリケーションが開発されたOCIライブラリのバージョン以上のOCIランタイム・ライブラリのバージョンとリンクできます。

静的にリンクされたアプリケーションを常に再リンクさせる必要がある

静的にリンクされたOCIアプリケーションは、メジャー・リリースおよびマイナー・リリースの両方に再リンクさせる必要がありますが、これは静的にリンクされたOracleのクライアントサイド・ライブラリのコードと、アップグレード後のORACLE_HOMEでのエラー・メッセージとの互換性が失われている可能性があるためです。たとえば、エラー・メッセージにパラメータが追加される更新があった場合、このエラー・メッセージは、静的にリンクされたコードとは非互換になります。

動的にリンクされたアプリケーションの再リンク

Oracle Database 10gリリース1(10.1)以上のリリースの動的にリンクされたOCIアプリケーションでは、現行のリリースとの上位互換性が保たれます。つまり、Oracleのクライアントサイド動的ライブラリには、前のバージョンのライブラリとの上位互換性があります。Oracle Universal Installerによって前のバージョンのライブラリへのシンボリック・リンクが作成され、このシンボリック・リンクが現行バージョンのライブラリに解決されます。したがって、前のバージョンのOracleクライアントサイド動的ライブラリと動的にリンクされたアプリケーションは、現行バージョンのOracleクライアントサイド・ライブラリと再リンクしなくても動作します。

注意:
アプリケーションがランタイム・ライブラリの検索パス(Linuxでの-rpathなど)にリンクされていると、リンクされているバージョンのOracleクライアントサイド・ライブラリを使用して引き続き実行される場合があります。現行バージョンのOracleクライアントサイド・ライブラリを使用して実行するには、アプリケーションを再リンクする必要があります。
アプリケーションが遅延オプション(静的にリンクされているアプリケーションなど)にリンクされている場合は、再リンクする必要があります。

Oracle Database 10gリリース1(10.1)より前のリリースのアプリケーションを使用している場合は、再リンクする必要があります。

プリコンパイラおよびOCIアプリケーションのアップグレード選択肢

プリコンパイラおよびOCIアプリケーションをアップグレードする場合は、次の選択肢があります。

- 選択肢1: アプリケーションを変更しない。アプリケーションを再リンク、プリコンパイルまたはコンパイルせず、また、アプリケーション・コードを変更しません。アプリケーションは、新しいOracle Database 11gリリースで引き続き動作します。

- 選択肢2: 新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする。APIが非推奨、サポート終了または変更されている場合は、アプリケーション・コードを変更する必要があります。

- 選択肢3: アプリケーション・コードを変更して、新しいOracle Database 11gの機能を使用する。その後、コードをプリコンパイルまたはコンパイルし、再リンクさせます。

これらの選択肢は、難易度が高く、考えられるメリットが大きくなる順序に記述されています。つまり、選択肢1は最も簡単ですが、考えられるメリットは最も小さくなり、選択肢3は最も難しい方法ですが、考えられるメリットは最も大きくなります。これらの選択肢については次の項で説明します。

選択肢1: アプリケーションを変更しない

この選択肢では、アプリケーションのOracleホーム環境をアップグレードしないでください。アプリケーションは変更しなくても、新しいOracle Database 11gサーバーで引き続き使用できます。この選択肢の主なメリットは、単純で簡単であることです。さらに、この選択肢では、クライアント・コンピュータをアップグレードする必要がないため、管理の必要性が最も少なくなります。多くのクライアント・コンピュータがある場合は、すべてのコンピュータのアップグレードに費やす管理コストを削減することが大変重要になります。

この選択肢の主なデメリットは、新しいOracle Database 11gリリースで使用可能な機能をアプリケーションで使用できないことです。また、期待できる新しいOracle Database 11gリリースのパフォーマンス上のメリットをアプリケーションで活用することができません。

選択肢2: 新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする

メンテナンス・リリースから新しいOracle Database 11gソフトウェアにアップグレードする場合は、APIが非推奨になったか変更されたために必要になったコード変更を行った後、新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする必要があります。Oracle Database 11gソフトウェア内のマイナー・リリースにアップグレードする場合は、再コンパイルを行う必要はありません。

この選択肢では、各クライアント・コンピュータに新しいOracle Databaseクライアント・ソフトウェアをインストールする必要があります。クライアントの数にかかわらず、必要なアプリケーションのプリコンパイルまたはコンパイルおよび再リンクは1回のみです。

再コンパイルすることによって、アプリケーション・コードの構文チェックを実行します。新しいOracleソフトウェアを使用してプリコンパイルまたはコンパイルすると、Oracleソフトウェアの以前のリリースでは検出されなかったアプリケーション・コードのいくつかの問題が、検出される場合があります。したがって、新しいソフトウェアを使用したプリコンパイルまたはコンパイルは、以前に検出されなかった可能性があるアプリケーション・コードの問題の検出および解決に役立ちます。

また、アプリケーションは新しいOracleソフトウェアで動作するため、再コンパイルすることによって、アプリケーションの最大の安定性を得ることができます。さらに、使用可能な最新のツール製品および機能を使用して、ご使用の環境で新しい開発を行うことができます。さらに、再コンパイルおよび再リンクの実行後のみ、新しいOracleソフトウェアで得られるパフォーマンスの向上を得ることができます。

選択肢3: アプリケーション・コードを変更して、新しいOracle Database 11gの機能を使用する

アプリケーションのコードを変更することで、新しいOracle Database 11gの機能を利用できます。この選択肢は最も難しい方法ですが、考えられるメリットも最大です。この選択肢では、「選択肢2: 新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする」で説明したすべてのメリットを実現できます。さらに、アプリケーションを変更することにより、新しいOracle Database 11gリリースで得られるパフォーマンスおよびスケーラビリティのメリットを活用できます。さらに、新しいOracle Database 11gリリースでのみ使用できる新機能を、アプリケーションに追加できます。

『Oracle Database新機能ガイド』を読んで、新しいOracle Database 11gリリースの機能を理解してください。使用する機能の実装方法については、ご使用の開発環境のOracleマニュアルを参照してください。プリコンパイラの詳細は、『Pro*C/C++プログラマーズ・ガイド』および『Pro*COBOLプログラマーズ・ガイド』を参照してください。OCIの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

使用する新機能を決定したら、アプリケーションのコードを変更して、これらの機能を使用できるようにします。ご使用の開発環境に基づいて、次の項の該当する指示に従ってください。

- プリコンパイラ・アプリケーションの変更

- OCIアプリケーションの変更

プリコンパイラ・アプリケーションの変更

プリコンパイラ・アプリケーションを変更して新しいOracle Database 11gリリースの機能を使用できるようにするには、次の手順を実行します。

1. 新しいOracle Database 11gリリースの機能を利用する場合は、これらの新機能のコードを既存のアプリケーションに取り込みます。

2. Oracleプリコンパイラを使用して、アプリケーションをプリコンパイルします。

3. アプリケーションをコンパイルします。

4. プリコンパイラに付属する新しいOracle Database 11gリリースのランタイム・ライブラリ(SQLLIB)を、アプリケーションと再リンクさせます。

OCIアプリケーションの変更

OCIアプリケーションを変更して新しいOracle Database 11gリリースの機能を使用できるようにするには、次の手順を実行します。

1. 新しいOracle Database 11gリリースのOCIコールを既存のアプリケーションに取り込みます。

2. アプリケーションをコンパイルします。

3. アプリケーションを新しいOracle Database 11gリリースのランタイム・ライブラリと再リンクさせます。

SQL*PlusスクリプトおよびPL/SQLのアップグレード

新しいOracle Database 11gリリースの機能およびファンクションを使用するには、新しいOracle Database 11gリリースの構文を使用するように既存のSQLスクリプトを変更します。新しいOracle Database 11gリリースの機能およびファンクションを使用しない場合は、既存のSQLスクリプトをそのまま新しいOracle Database 11gリリースで実行できるため、変更は不要です。

ただし、新しいOracle Database 11gリリースではエラー確認機能が強化されているため、実行時ではなくコンパイル時にエラーを識別できる場合があります。

関連項目:

- 数値リテラルの評価への変更

数値リテラルの評価への変更

数値リテラルの評価方法が変更され、リテラルを使用する数値計算の場合は、定数の1つ以上で小数第1位に小数点を指定することが必要になりました。これは、Oracle Database 10gリリース1(10.1)以上のリリースのOracle Databaseでは一部の式でINTEGER演算(有効桁は約9桁)が使用されますが、Oracle9iリリース2(9.2)ではNUMBER演算(有効桁数は約38桁)が使用されるためです。

したがって、有効桁数が9桁を超える計算結果を扱う場合、数値オーバーフローのエラーを回避するには、リテラルのうち1つが小数形式であることが必要です。たとえば、Oracle Database 10gでは、次に示す例のv1の計算で数値オーバーフローのエラーが発生します。

DECLARE
v1 NUMBER(38);
BEGIN
v1 := 256*256*256*256;
DBMS_OUTPUT.PUT_LINE(v1);
END;
/

エラーが発生しないようにするには、数値リテラルの1つを次のように小数(256.0)として指定します。

DECLARE
v1 NUMBER(38);
BEGIN
v1 := 256*256*256*256.0;
DBMS_OUTPUT.PUT_LINE(v1);
END;
/

関連項目:

- SQL*Plusの新機能の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』のSQL*Plusの新機能に関する項を参照してください。

- SQLスクリプトのアップグレードの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

Oracle FormsまたはOracle Developerアプリケーションのアップグレード

Formsアプリケーションは、Oracle9i、Oracle Database 10gおよびOracle Database 11gで同様に動作します。ただし、『Oracle Database新機能ガイド』で説明されている新機能を確認して、新しいOracle Database 11gリリースの機能がアプリケーションに有効か、アプリケーションに影響を与えるかを判断してください。新しいOracle Database 11gリリースの機能がFormsおよびDeveloperアプリケーションとどのように相互作用するかについては、Oracle Developerのドキュメント・セットを参照してください。また、オペレーティング・システムのOracle Developerドキュメントには、ご使用のFormsまたはDeveloperアプリケーションのアップグレード方法が記述されています。

注意:
Oracle Developerの新しいリリースでは、Oracle Developer固有の新しい予約語が導入されている場合があります。アプリケーションがこれらの予約語を使用している場合は、コードを変更する必要があります。

6 以前のリリースへのOracle Databaseのダウングレード

Oracle Databaseは、アップグレード元のリリースにのみダウングレードできます。たとえば、Oracle Database 10gリリース1(10.1.0.5)からOracle Database 11gリリース2(11.2)にアップグレードした場合は、その後、Oracle Database 10gリリース2(10.2)にダウングレードすることはできず、Oracle Database 10gリリース1(10.1.0.5)にのみダウングレードできます。

この章の内容は次のとおりです。

- Oracle Databaseのダウングレードがサポートされているリリース

- Oracle Databaseリリース間の非互換性の確認

- サーバー・パラメータ・ファイル(SPFILE)からのサポート対象外パラメータの削除

- ダウングレード前のOracle Databaseの全体バックアップの実行

- 以前のリリースへのOracle Databaseのダウングレード

- Oracle Databaseのダウングレード後の作業

- Oracle Databaseのダウングレードのトラブルシューティング

関連項目:
オペレーティング・システム固有のダウングレードの説明については、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

Oracle Databaseのダウングレードがサポートされているリリース

データベースがアップグレードされる前の元のリリースに基づいて、メジャー・リリースとパッチ・セット・リリースの両方をダウングレードできます。メジャー・リリースのダウングレードは、Oracle Database 11gリリース1(11.1.0.6)、Oracle Database 10gリリース2(10.2.0.2)およびOracle Database 10gリリース1(10.1.0.5)へのダウングレードがサポートされています。パッチ・セットのダウングレードは、11.2以前のすべてのパッチ・リリースへのダウングレードがサポートされています。

注意:
Oracle Database Express Editionからアップグレードされたデータベースをダウングレードすることはできません。

Oracle Database 11gリリース2(11.2)データベースとともにOracle Database Vaultがインストールされている場合は、リリース11.1.0.6および11.1.0.7にのみダウングレードできます。

データベースにメッセージ・ゲートウェイまたはWorkspace Managerが存在する場合でも、それらはリリース10.2.0.4以前のOracle Databaseパッチ・セットには含まれません。したがって、ダウングレード前にすべての関連パッチをリリース10.2.0.3またはリリース10.1.0.5のOracleホームに個別に適用する必要があります。

Oracle Enterprise Managerのダウングレードはサポートされていません。ただし、データベースをアップグレードする前にOracle Enterprise Manager Database Controlのファイルおよびデータを保存した場合、データベースのダウングレード後に古いバージョンのDatabase Controlをリストアできます。

注意:
Oracle Data Pumpのデータベースの全体エクスポートをINCLUDE=DBLINKパラメータとともに使用して、ダウングレードするデータベースへのインポートに適したダンプ・ファイルに、すべてのデータベース・リンクをエクスポートする必要があります。その後、このダンプ・ファイルは、ダウングレード後にデータベース・リンクを置き換えるために使用できます。

関連項目:

- 「emdwgrdユーティリティを使用したデータベースの制御ファイルおよびデータの保存」

- 「Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア」

Oracle Databaseリリース間の非互換性の確認

ご使用のOracle Databaseリリースの互換性レベルをチェックして、非互換性があるかどうかを確認します(非互換性がある場合は、ダウングレードできません)。Oracle Database 11gリリース2(11.2)データベースのの互換性レベルが11.2.0以上である場合は、ダウングレードできません。

関連項目:
「Oracle Databaseの互換性レベルの確認」

Oracle Database 11gリリース1(11.1)にダウングレードする場合は、COMPATIBLE初期化パラメータを11.0.0以下に設定する必要があります。

Oracle Database 10gリリース2(10.2)にダウングレードする場合は、COMPATIBLE初期化パラメータを10.2.0以下に設定する必要があります。

Oracle Database 10gリリース1(10.1)にダウングレードする場合は、COMPATIBLE初期化パラメータを10.1.0に設定する必要があります。

関連項目:
「Oracle Databaseのダウングレードおよび互換性に関する考慮点」および付録A「Oracle Databaseのアップグレード後の動作の変更点」

サーバー・パラメータ・ファイル(SPFILE)からのサポート対象外パラメータの削除

データベースでSPFILEを使用している場合、ダウングレード先の以前のリリースではサポートされていない新しいパラメータが、インストールまたはアップグレード時に追加されていることがあります。ダウングレード後、新しいパラメータによって、データベースが起動できない場合があります。そのため、以前のリリースでサポートされていないパラメータをSPFILEから削除する必要があります。『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の説明に従って、ALTER SYSTEM文のSET句を使用することで、SPFILEの設定を変更できます。

ダウングレード元の現行リリースの新しいパラメータの詳細は、そのリリースの『Oracle Database新機能ガイド』を参照してください。

ダウングレード前のOracle Databaseの全体バックアップの実行

ダウングレードする前に、Oracle Database 11gリリース2(11.2)データベースに対し、全体バックアップを実行します。『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明されている手順に従います。

関連項目:
詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

以前のリリースへのOracle Databaseのダウングレード

Oracle Database 11gリリース2(11.2)データベースは、メジャー・リリースまたは関連するパッチ・セット・アップグレードへダウングレードできます。

データベースを以前のリリースにダウングレードするには、次の手順を実行します。

1. データベースでOracle Database Vaultを有効にしている場合は、次を行う必要があります。

- SYSアカウントにDatabase VaultのDV_PATCH_ADMINロールを付与します。

- データベースをダウングレードする前に、Database Vaultを無効にします。

関連項目:
Oracle Database Vaultを無効にする手順は、『Oracle Database Vault管理者ガイド』を参照してください。

2. 以前にデータベースをアップグレードし、DBMS_DST PL/SQLパッケージを使用してそのデータベースのタイムゾーンのバージョンを更新した場合は、ダウングレード前に以前のリリースのOracleホームに同じバージョンのタイムゾーン・ファイルのパッチを適用する必要があります。
たとえば、DSTv4を使用するLinux x64上のリリース10.2.0.4データベースをリリース11.2.0.2にアップグレードし、DBMS_DSTを実行してこのデータベースをDSTv14に更新したとします。この場合、リリース11.2.0.3から10.2.0.4にダウングレードする前に、リリース10.2.0.4側に対してLinux x64向けの10.2.0.4用DSTv14パッチを適用する必要があります。これにより、TIMESTAMP WITH TIME ZONEデータが取得中に論理的に破損することがなくなります。

データベースで使用されているタイムゾーン・ファイルのバージョンを確認するには、次の手順を実行します。

SELECT value$ FROM sys.props$ WHERE NAME = 'DST_PRIMARY_TT_VERSION';

関連項目:
タイムゾーン・ファイルの適用の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

3. Oracle Database 11gリリース2(11.2)へのアップグレード時にORA_TZFILE環境変数をtimezone.datファイルのフルパス名に設定した場合は、後でデータベースをダウングレードする際にその設定を解除する必要があります。
Oracleホーム・ディレクトリには、次の2つのタイムゾーン・ファイルがあります。

- デフォルトのタイムゾーン・ファイル

$ORACLE_HOME/oracore/zoneinfo/timezonelrg.dat

- 小さいタイムゾーン・ファイル

$ORACLE_HOME/oracore/zoneinfo/timezone.dat

ORA_TZFILE変数の設定を解除しなかった場合、小さい方のタイムゾーン・ファイルを使用してデータベースに接続すると、次のエラーが発生する可能性があります。

SP2-1503: Unable to initialize Oracle call interface
SP2-0152: ORACLE may not be functioning properly

関連項目:
日時データ型およびタイムゾーン・サポートの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

4. データベースにOracle Application Expressがある場合は、Oracle Database 11gリリース2(11.2)のORACLE_HOME/apex/ディレクトリからOracleホーム外部のディレクトリ(システムの一時ディレクトリなど)にapxrelod.sqlファイルをコピーする必要があります。

このファイルの新しい場所を記録します。

5. 固定オブジェクトに基づいてオブジェクトを作成した場合は、これらのオブジェクトを削除して、ORA-00600エラーの発生を回避します。ダウングレード後にこれらのオブジェクトを再作成できます。

6. Oracle Database 11gリリース2(11.2)のOracleホーム・ディレクトリの所有者としてシステムにログインします。

7. この手順は、Enterprise Manager Database Controlがデータベースにすでに構成されている場合にのみ実行する必要があります。
次の手順を実行して、Database Controlを停止します。

1. ORACLE_UNQNAME環境変数をデータベースの一意の名前に設定します。

2. 次のコマンドを実行します。

ORACLE_HOME/bin/emctl stop dbconsole

ダウングレード中のデータベースがOracle RACデータベースの場合は、すべてのインスタンスでこの手順を実行します。

8. Oracle RACデータベースを10gリリース1(10.1)にダウングレードする場合は、Oracle Clusterwareスタックを停止する前に余分な投票ディスクを削除する必要があります。

1. 使用する投票ディスクの数を確認し、投票ディスクのパスを表示するには、次のコマンドを実行します。

Oracle_Clusterware_Home/bin/crsctl query css votedisk

2. 次のコマンドを実行して、前述の手順で検出した追加の投票ディスクをそれぞれ削除します。pathは、前述の手順で表示されたFile Name列内の投票ディスクのパスです。

Oracle_Clusterware_Home/bin/crsctl delete css votedisk path

次に例を示します。

Oracle_Clusterware_Home/bin/crsctl delete css votedisk /share/cluster2/vote_cluster2.dbf

最後の投票ディスクは削除しないでください。

9. システム・プロンプトで、ORACLE_HOME/rdbms/adminディレクトリへ移動します。

注意:
クラスタ・データベースをダウングレードしている場合は、インスタンスを完全に停止し、CLUSTER_DATABASE初期化パラメータをFALSEに設定します。ダウングレードが完了した後、このパラメータの設定をTRUEに戻す必要があります。

10. SQL*Plusを使用して、SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

11. DOWNGRADEモードでインスタンスを起動します。

SQL> STARTUP DOWNGRADE

PFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。

12. データベース内にEnterprise Managerが構成されている場合は、Enterprise Managerユーザーを削除します。

DROP USER sysman CASCADE;

注意:
この手順を実行すると、MGMT*シノニムが無効になる場合があります。シノニムを有効にするには、「Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア」のガイドラインに従います。

13. 変更と問題を追跡するために、結果をログ・ファイルにスプールするようにシステムを設定します。

SQL> SPOOL downgrade.log

14. catdwgrd.sqlを実行します。

SQL> @catdwgrd.sql

スクリプトの実行についての注意は、次のとおりです。

- Oracle Database 11gリリース2(11.2)に付属するスクリプトのバージョンを使用する必要があります。

- Oracle Database 11gリリース2(11.2)の環境でスクリプトを実行する必要があります。

- このスクリプトによって、データベース内のすべてのOracle Databaseコンポーネントがアップグレード元のメジャー・リリースまたはOracle Database 11gパッチ・リリースにダウングレードされます。

このスクリプトまたは残りの手順のいずれかのスクリプトを実行中になんらかの問題が発生した場合は、問題を解決してスクリプトを再実行します。必要に応じて、この章で説明されているスクリプトのいずれかを実行できます。

コンポーネントのダウングレードに失敗した場合、ORA-39709エラーが表示され、SQL*Plusセッションは、Oracle Databaseデータ・ディクショナリをダウングレードせずに終了します。すべてのコンポーネントは、Oracle Databaseのデータ・ディクショナリをダウングレードする前に、正常にダウングレードする必要があります。catdwgrd.sqlスクリプトを再実行する前に、問題を特定して修正する必要があります。

15. スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

次に、スプール・ファイルを確認して、ダウングレード中にエラーが発生しなかったかどうかを検証します。手順13で、スプール・ファイル名をdowngrade.logとしました。このファイルで見つけた問題を修正し、必要に応じてダウングレード・スクリプトを再実行します。

注意:
ダウングレード・スクリプトを初めて実行した結果を保存する場合は、再実行する前に、downgrade.logを他の名前に変更してください。

16. インスタンスを停止します。

SQL> SHUTDOWN IMMEDIATE

17. SQL*Plusを終了します。

18. ご使用のオペレーティング・システムがLinuxまたはUNIXの場合、次の環境変数がダウングレード先のリリースのディレクトリを指定するように変更してください。

- ORACLE_HOME

- PATH

また、oratabファイル、およびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、ダウングレードされたOracleホームを指していることを確認する必要があります。

関連項目:
ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関する詳細は、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

19. ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。

1. Oracle Database 11gリリース2(11.2)のデータベースのすべてのOracleサービス(OracleServiceSIDなど)を停止します。SIDはインスタンスの名前です。
たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。

C:\> NET STOP OracleServiceORCL

関連項目:
『Oracle Database Net Services管理者ガイド』

2. コマンド・プロンプトでORADIMコマンドを発行して、Oracleサービスを削除します。たとえば、SIDがORCLの場合、次のコマンドを入力します。

C:\> ORADIM -DELETE -SID ORCL

3. コマンド・プロンプトでORADIMコマンドを使用して、ダウングレードするデータベースのOracleサービスを作成します。

C:\> ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS
-STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

この構文には次の変数が含まれます。

変数

説明

SID

ダウングレードするデータベースと同じSID名です。

PASSWORD

データベース・インスタンスのパスワードです。SYSDBA権限で接続するユーザー用のパスワードです。-INTPWDオプションは必須ではありません。これを指定しない場合、オペレーティング・システムの認証が使用され、パスワードは不要です。

USERS

SYSDBA権限およびSYSOPER権限を付与できるユーザーの最大数です。

ORACLE_HOME

ダウングレード先のデータベースのOracleホーム・ディレクトリです。-PFILEオプションを使用して、(Oracleホーム・ディレクトリのドライブを含む)フルパス名を指定する必要があります。

たとえば、ダウングレード先がOracle Database 10gリリース2(10.2)、SIDがORCL、PASSWORDがTWxy5791、USERSの最大数が10、ORACLE_HOMEディレクトリがC:\ORANTの場合、次のコマンドを入力します。

C:\> ORADIM -NEW -SID ORCL -INTPWD TWxy5791 -MAXUSERS 10
-STARTMODE AUTO -PFILE C:\ORANT\DATABASE\INITORCL.ORA

注意:
データベースをダウングレードする際に、Windowsレジストリの設定を変更する必要はありません。必要な変更は、すべてORADIMユーティリティによって自動的に行われます。

20. ダウングレード先のリリースの構成ファイル(パラメータ・ファイル、パスワード・ファイルなど)をリストアします。
Oracle RACデータベースの場合は、次のコマンドを実行して、データベースを単一インスタンス・モードに戻します。

set CLUSTER_DATABASE=FALSE

注意:
クラスタ・データベースをダウングレードしている場合は、そのクラスタ・データベースのインスタンスを構成するすべてのノードでこの手順を実行してください。CLUSTER_DATABASE初期化パラメータをFALSEに設定します。ダウングレードが完了した後、この初期化パラメータの設定をTRUEに戻す必要があります。

21. システム・プロンプトで、以前のリリースのORACLE_HOME/rdbms/adminディレクトリへ移動します。

22. SQL*Plusを起動します。

23. SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

24. インスタンスを起動します。

SQL> STARTUP UPGRADE

25. 変更と問題を追跡するために、結果をログ・ファイルにスプールするようにシステムを設定します。

SQL> SPOOL reload.log

26. catrelod.sqlを実行します。

SQL> @catrelod.sql

catrelod.sqlスクリプトを使用すると、ダウングレードしたデータベース内の該当するバージョンのすべてのデータベース・コンポーネントが再ロードされます。

27. Oracle Database 11gリリース1(11.1.0.6)へダウングレードしている場合は、xsrelod.sqlスクリプトを実行します。

SQL> @xsrelod.sql

xsrelod.sqlスクリプトを実行すると、次のエラーを回避できます。

PLS-00306: wrong number or types of arguments in call
to 'INVALIDATE_DSD_CACHE' DBMS_XS_DATA_SECURITY_EVENTS
PL/SQL: Statement ignored

注意:
PLS-00306エラーは、Oracle Databaseリリース11.2.0.7以上では問題になりません。

28. Oracle Database 10gリリース1(10.1.0.5)へのダウングレード中で、データベースにXDBが存在する場合は、dbmsxdbt.sqlスクリプトを実行します。

@dbmsxdbt.sql

dbmsxdbt.sqlスクリプトを実行すると、XDB.DBMS_XDBTパッケージを再ロードするときに次のエラーを回避できます。

PLS-00201: identifier 'CTXSYS.CTX_OUTPUT' must be declaredPLS-00201: identifier 'CTX_DDL' must be declared

29. Oracle Database 11gリリース1以下にダウングレードする際にデータベースにOracle Application Expressがある場合は、ディレクトリを(手順4で)apxrelod.sqlスクリプトをコピーしたディレクトリに変更する必要があります。apxrelod.sqlスクリプトを実行して、Oracle Application Expressを手動で再ロードします。

SQL> @apxrelod.sql

apxrelod.sqlスクリプトを実行すると、次のエラーが原因でパッケージAPEX_030200.WWV_FLOW_HELPがINVALIDになることを回避できます。

PLS-00201: identifier 'CTX_DDL' must be declared

30. スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

次に、スプール・ファイルを確認して、すべてのパッケージおよびプロシージャのコンパイルが成功したかどうかを検証します。手順25で、スプール・ファイル名をreload.logとしました。このファイルで見つけた問題を処理し、必要に応じて適切なスクリプトを再実行します。

31. 通常の操作のために、インスタンスを停止し、再起動します。

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

PFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。

32. データベースがOracle Label Security用に構成されていて、Oracle Database 10gリリース1(10.1)からダウングレードする場合、次の手順を実行します。

1. olstrig.sqlスクリプトを、Oracle Database 11gリリース2(11.2)のOracleホームからダウングレード後のデータベースのバージョンのOracleホームにコピーします。

2. olstrig.sqlを実行し、Oracle Label Securityのポリシーを適用して、表のDMLトリガーを再作成します。

SQL> @olstrig.sql

詳細は、『Oracle Label Security管理者ガイド』を参照してください。

33. utlrp.sqlスクリプトを実行します。

SQL> @utlrp.sql

utlrp.sqlスクリプトは、以前INVALID状態だったパッケージ、プロシージャ、型などのすべての既存のPL/SQLモジュールを、再コンパイルします。

34. SQL*Plusを終了します。

35. クラスタ・データベースをダウングレードする場合は、次のコマンドを実行してOracle Clusterwareのデータベース構成をダウングレードする必要があります。

$ srvctl downgrade database -d db-unique-name -o old_ORACLE_HOME -t to_relnum

[ここで、db-unique-nameはインスタンス名ではなくデータベース名であり、old_ORACLE_HOMEは、ダウングレードされたデータベースが実行される古いOracleホームの場所です。この例では、to_relnumは、データベースのダウングレード後のリリース番号です(例: 11.2.0.1.0)。]

注意:
デフォルトでは、指定したユーザーはサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者のリストに追加することをお薦めします。
関連項目: CRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください

注意:
このコマンドは、データベースのダウングレード後のOracleホームからではなく、現在のOracleホームから実行してください。

データベースがダウングレードされました。

Oracle Databaseのダウングレード後の作業

Oracle Databaseのダウングレード後の作業が必要となる場合があります。この項には次のトピックが含まれます:

- Oracle Databaseリリース10.2または11.1にダウングレードする際のネットワーク・リスナーの再作成

- Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア

- Oracle ASMがない単一インスタンスのOracle Database

- Oracle ASMがないOracle RACデータベース

- 単一インスタンスのOracle ASMインスタンス

- Oracle RACインスタンス上のOracle ASM

- Oracle ASMがある単一インスタンスのOracle Database

- Oracle RACデータベースおよびOracle ASMインスタンス

- Oracle Databaseのダウングレード後のOracle Database Vaultの再有効化

- ダウングレード後のOracle Clusterware構成のリストア

- 以前のリリースからのダウングレードおよびデータベース・リンク

Oracle Databaseリリース10.2または11.1にダウングレードする際のネットワーク・リスナーの再作成

新しいデータベースをOracle Database 10gまたはOracle Database 11gリリース1にダウングレードする場合は、ダウングレード手順の実行後にリスナーを再作成する必要があります。Oracle Net Managerを実行して古いリスナーを削除し、新しいリスナーを作成します。

- Oracle Enterprise ManagerのコンソールからOracle Net Managerを起動するには、「ツール」メニューから「サービス管理」を選択し、「Oracle Net Manager」を選択します。

- Microsoft Windowsの場合、「スタート」メニューから「プログラム」を選択し、「Oracle - HOME_NAME」を選択します。次に、「Configuration and Migration Tools」を選択し、「Net Manager」を選択します。

関連項目:
『Oracle Database Net Services管理者ガイド』

Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア

このタスクは、なんらかの形式でダウングレード中であり、Oracle Enterprise Managerがホストに構成されている場合にのみ実行する必要があります。Oracle Enterprise Managerを前の状態にリストアするには、アップグレードを実行する前にOracle Enterprise Managerのファイルおよびデータを保存しておく必要があります。

関連項目:
「emdwgrdユーティリティを使用したデータベースの制御ファイルおよびデータの保存」

これがOracle Clusterwareを使用したOracle RACデータベースである場合は、emca -restoreコマンドを実行する前にsrvctlを使用してデータベースを登録する必要があります。これは、ダウングレード後のデータベースのバージョンのORACLE_HOME/binから実行する必要があります。

関連項目:
srvctlに関する詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

適切なオプションを指定してemca -restoreコマンドを実行し、Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlを古いOracleホームにリストアします。指定するオプションは、ダウングレード中のデータベースがOracle RACデータベースかOracle ASMデータベースかによって、次のように異なります。

注意:
この手順では、Oracle Database 11gリリース2(11.2)バージョンのemcaを使用します。emcaの詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle ASMがない単一インスタンスのOracle Database

111Home/bin/emca -restore db

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースSID

- リスナー・ポート番号

Oracle ASMがないOracle RACデータベース

111Home/bin/emca -restore db -cluster

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースの一意の名前

- リスナー・ポート番号

単一インスタンスのOracle ASMインスタンス

111Home/bin/emca -restore asm

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- Oracle ASMポート

- Oracle ASM SID

Oracle RACインスタンス上のOracle ASM

111Home/bin/emca -restore asm -cluster

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- Oracle ASMポート

Oracle ASMがある単一インスタンスのOracle Database

111Home/bin/emca -restore db_asm

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースSID

- リスナー・ポート番号

- Oracle ASMポート

- Oracle ASMホーム

- Oracle ASM SID [+ASM]

Oracle RACデータベースおよびASMインスタンス

111Home/bin/emca -restore db_asm -cluster

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースの一意の名前

- リスナー・ポート番号

- Oracle ASMポート

- Oracle ASM Oracleホーム

- Oracle ASM SID [+ASM]

emcaの出力は、指定するオプションおよびプロンプトで入力する値によって様々です。

インプレース・パッチ・セット・アップグレードでは、パッチ・セットを適用する前に保存した元のホームのバックアップをリストアする必要があります。この手順は、Oracle RAC環境内のすべてのノードに対して繰り返す必要があります。インプレース・パッチ・セット・アップグレードでは、emca -restoreコマンドを実行する必要はありません。

emca -restoreプロシージャの終了後、emdwgrdユーティリティを使用して、Oracle Enterprise Managerデータベースのファイルおよびデータをリストアする準備ができます。Oracle Database 11gリリース2(11.2)ホームからemdwgrdユーティリティを実行する必要があります。ただし、ORACLE_HOMEおよび他の環境変数を、アップグレードが実行される前のOracleホームを指すように設定する必要があります。

次の手順は、LinuxおよびUNIX用です。この手順をWindowsで実行する場合は、emdwgrdをemdwgrd.batに置き換えてください。

次の手順に従って、Database Controlのファイルおよびデータをリストアします。

1. ORACLE_HOMEを、データベースがアップグレードされる前のOracleホームに設定します。
インプレース・パッチ・セット・アップグレードでは、元のホームのバックアップを(11.1.0.6からアップグレードしている場合はOracle Bug#7131048の個別パッチを使用して)リストアして、ORACLE_HOMEを現行のOracleホームに設定します。

2. ORACLE_SIDを、アップグレード後にダウングレードされたデータベースのSIDに設定します。

3. データベースがアップグレードされる前のOracleホームを指すように、PATH、LD_LIBRARY_PATHおよびSHLIB_PATHを設定します。

4. Oracle Database 11gリリース2(11.2)のホームに移動します。

cd ORACLE_HOME/bin

5. 次のいずれかを実行します。

1. 単一インスタンス・データベースの場合は、次のコマンドを実行します。SIDはアップグレード後にダウングレードされたデータベースのSIDで、save_directoryは、Database Controlのファイルおよびデータの保存時に選択した記憶域の場所へのパスです。

emdwgrd -restore -sid SID -path save_sirectory -tempTablespace TEMP

2. Oracle RACデータベースの場合、クラスタ・ノード間のリモート・コピーが必要です。構成済のリモート・コピーを示す環境変数を定義します。次に例を示します。

setenv EM_REMCP /usr/bin/scp

その後、次のrestoreコマンドを実行します。

emdwgrd -restore -tempTablespace TEMP -cluster -sid SID10g -path save_directory

10gのOracleホームが共有デバイス上にある場合は、前述のコマンドラインに-sharedを追加します。

6. emdwgrdにより要求された場合は、SYSおよびSYSMANパスワードを入力します。

7. 単一インスタンスのデータベースの場合は、emdwgrdユーティリティによって次のような内容が出力されます。

Sat Apr 28 09:27:09 2007 - Verify EM DB Control files ... pass
Sat Apr 28 09:27:09 2007 - Validating DB Connection to DB102 ... pass
Sat Apr 28 09:27:19 2007 - Validating TEMP tablespace in DB102 ... pass
Sat Apr 28 09:27:20 2007 - creating directory ... created
Sat Apr 28 09:27:20 2007 - Stopping DB Control ... stopped
Sat Apr 28 09:27:21 2007 - dropping sysman schema ... dropped
Sat Apr 28 09:27:22 2007 - recreating sysman user ... recreated
Sat Apr 28 09:27:23 2007 - Restoring DB Control files ... restored
Sat Apr 28 09:27:23 2007 - Importing sysman schema ... imported
Sat Apr 28 09:30:42 2007 - recompiling invalid objects ... recompiled
Sat Apr 28 09:30:54 2007 - Starting DB Control ... started
Sat Apr 28 09:32:37 2007 - DB Control was restored successfully.

emdwgrdの終了時に、Oracle Enterprise Manager Database Controlは古いOracleホームにダウングレードされています。

Oracle RACデータベースの場合は、emdwgrdユーティリティによって次のような内容が出力されます。

$ /scratch/oracle/product/11.1.0/db_1/bin/emdwgrd -srcOracleHome $ORACLE_HOME -sid DB102 -path /scratch/rpattabh/ravi/tmp/dbcdir5 -restore –cluster -tempTablespace TEMP

Enter sys password for database DB102?
*****

Enter sysman password for database DB102?
*****

Sat Apr 28 09:27:09 2007 - Verify EM DB Control files ... pass
Sat Apr 28 09:27:09 2007 - Validating DB Connection to DB102 ... pass
Sat Apr 28 09:27:19 2007 - Validating TEMP tablespace in DB102 ... pass
Sat Apr 28 09:27:20 2007 - creating directory ... created
Sat Apr 28 09:27:20 2007 - Stopping DB Control on all Nodes
stbdq04, r101b1, /oradbnas/sangeeta/10.1.0/db, stop, 0
stbdq05, r101b2, /oradbnas/sangeeta/10.1.0/db, stop, 1

Please Execute '/tmp/racdwgrd_dbctl.sh' on Node1, Node2.

Press yes to continue when the operations are successful.
Continue (yes/no) ?
y

... stopped
Sat Apr 28 09:27:21 2007 - dropping sysman schema ... dropped
Sat Apr 28 09:27:22 2007 - recreating sysman user ... recreated
Sat Apr 28 09:27:23 2007 - Restoring DB Control files
Executing Restore directories to node Node1
Executing Restore directories to node Node2

... restored
Sat Apr 28 09:27:23 2007 - Importing sysman schema ... imported
Sat Apr 28 09:30:42 2007 - recompiling invalid objects ... recompiled
Sat Apr 28 09:32:37 2007 - DB Control was restored successfully.
Sat Apr 28 09:33:54 2007 - Starting DB Control On All nodes

Please Execute '/tmp/racdwgrd_dbctl.sh' on Node1, Node2.

Press yes to continue when the operations are successful.
Continue (yes/no) ?
y

... started
Sat Apr 28 09:38:57 2007 - Dump directory was dropped successfully.

Oracle Databaseのダウングレード後のOracle Database Vaultの再有効化

Oracle Database Vaultを使用している場合は、データベースをダウングレードする前にこれを無効にするように指示がありました。ダウングレード後にOracle Database Vaultを使用するには、これを再有効化する必要があります。

ダウングレード後にOracle Database Vaultを有効化するには、次の手順を実行します。

1. DV_OWNERロールを付与されているユーザーとしてSQL*Plusに接続します。

2. 次の文を発行します。

ALTER TRIGGER DVSYS.DV_BEFORE_DDL_TRG ENABLE;
ALTER TRIGGER DVSYS.DV_AFTER_DDL_TRG ENABLE;

関連項目:
『Oracle Database Vault管理者ガイド』

ダウングレード後のOracle Clusterware構成のリストア

Oracle Clusterware構成をOracle Clusterware 11gリリース2(11.2)のアップグレード前の状態にリストアできます。そのためには、アップグレード前のリリースをリストアする必要があります。11gリリース2(11.2)のアップグレード処理中またはアップグレード処理後に実行した構成変更は削除され、リカバリできません。

関連項目:

- 『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』

- Microsoft Windows (32-Bit)、Microsoft Windows (64-Bit) on Intel Itanium、Microsoft Windows x64用の『Oracle Grid Infrastructureインストレーション・ガイド』

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

- 『Oracle Databaseストレージ管理者ガイド』

以前のリリースからのダウングレードおよびデータベース・リンク

ダウングレードする前に、Oracle Data Pumpのデータベースの全体エクスポートをINCLUDE=DBLINKパラメータとともに使用して、ダウングレードするデータベースへのインポートに適したダンプ・ファイルに、すべてのデータベース・リンクをエクスポートする必要があります。その後、このダンプ・ファイルは、ダウングレード後にデータベース・リンクを置き換えるために使用できます。

新しく作成するデータベース・リンク(ダウングレード元の新しいリリースを実行中に作成する可能性があるデータベース・リンク)のパスワードを確認します。以前のリリース11.1にダウングレードした後でデータベース・リンク・パスワードをリセットする必要があるため、データベース・リンク・パスワードが必要です。これは、新しいリリースへのアップグレード後に新しく作成したdblinkにのみ必要です。

データベース・リンク・パスワードがリセットされない場合、そのデータベース・リンクの使用を試みると内部エラーが表示されます。Oracleサーバーがデータベース・リンクのパスワードを取得できないときにOracleトレース・ファイルに記録される内部エラーは、「ORA-00600: [kzdlk_zt2 err], [18446744073709551601]」です。また、ダウングレード完了後に、dblinkを再作成することもできます。

注意:
新しいOracle Databaseリリース11.2のアップグレード実行中に、ORA-00600の問題に影響されない新しいデータベース・リンクを作成する場合、Oracle Supportに問い合せることができます。

Oracle Databaseのダウングレードのトラブルシューティング

Oracleでは、Oracle Databaseをダウングレードする際に発生する可能性のある問題に関してトラブルシューティング情報を提供しています。このリリースに関する最新情報については、『Oracle Databaseプラットフォーム共通日本語README』を参照してください。

Oracle Grid Infrastructureのリリース11.2のダウングレードの失敗

Oracle Grid Infrastructureのリリース11.2のダウングレードが失敗した場合は、https://support.oracle.comでLinux/Unixに関するサポート・ノート「How to Proceed from Failed Upgrade to Grid Infrastructure」(ID 969254.1)を参照してください。対応を実行する前に、ノート全体を読んでおくことをお薦めします。

11.2.0.1 xsrelod.sqlスクリプトで発生したエラー

Oracle Databaseをリリース11.2.0.2または11.2.0.3からリリース11.2.0.1にダウングレードする場合、リリース11.2.0.1に付属するxsrelod.sqlスクリプトからエラーが発生する場合があります。この問題が発生するのは、リリース11.2.0.1にダウングレードした後に、XML DB索引を有効化しようとした場合のみです。エラー「ORA-01418: 指定した索引は存在しません。」が発生する可能性がありますが、無視して問題ありません。

Oracle Multimedia imrelod.sqlスクリプトで発生したエラー

Oracle Databaseをリリース11.2.0.2にダウングレードする場合、リリース11.2.0.2に付属するimrelod.sqlスクリプトからエラーが発生する場合があります。ORA-20000: レジストリ内のOracle ORDIMコンポーネントのステータスがDOWNGRADEDです。Oracle Multimediaをアップグレード、ダウングレードまたはパッチ適用する前にOracle ORDIMをインストールし、有効化しておく必要があります、というエラーは無視して問題ありません。

Oracle Databaseのダウングレードが原因の無効なオブジェクトCTX_FILTER_CACHE_STATISTICS

Oracle Databaseのダウングレード後に、次の無効なテキスト・オブジェクトが表示される場合があります。

CTX_FILTER_CACHE_STATISTICS (synonym)
CTX_FILTER_CACHE_STATISTICS (view)

Oracle Databaseの現行リリースでこの問題を修正するには、catdwgrd.sqlスクリプトの実行後、catrelod.sqlスクリプトの実行前に、次の2つのコマンドを発行します。

SQL> drop public synonym ctx_filter_cache_statistics;
SQL> drop view ctx_filter_cache_statistics;

7 Oracle Data Pumpを使用したデータの移動

Oracle Databaseをアップグレードするときに、Oracle Data Pumpのエクスポート/インポート・ユーティリティを使用して、あるデータベースから別のデータベースにデータを移動できます。

この章の内容は次のとおりです。

- Oracle Databaseのアップグレードに使用するデータ・ポンプ・エクスポートおよびインポートの概要

- Oracle Databaseをアップグレードする場合のエクスポート/インポートの要件

- データ・ポンプ・エクスポート/インポートを使用したデータベースのアップグレード

関連項目:
データ・ポンプおよびエクスポート/インポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

Oracle Databaseのアップグレードに使用するデータ・ポンプ・エクスポートおよびインポートの概要

データ・ポンプ・エクスポート(expdp)およびデータ・ポンプ・インポート(impdp)・ユーティリティの外観や使用感はオリジナルのエクスポート(EXP)およびインポート(IMP)ユーティリティと似ていますが、これらは別のユーティリティです。データ・ポンプ・エクスポート/インポート・ユーティリティが最初にリリースされたのはOracle Database 10gリリース1(10.1)であり、オリジナルのエクスポート/インポート・ユーティリティに置き換わる高パフォーマンスのユーティリティです。これらのユーティリティはオリジナルのエクスポート/インポート・ユーティリティに比べて大幅にパフォーマンスが向上しているため、データベースをアップグレードする場合は、データ・ポンプ・エクスポート/インポート・ユーティリティを使用する必要があります。また、IMPおよびEXPユーティリティは、サポートされなくなりました。

関連項目:

- このアップグレード方法を使用するタイミングの詳細は、「Oracle Data Pump Export/ImportおよびOracle Databaseのアップグレード」を参照してください。

- パフォーマンスの向上および使いやすさを実現するデータ・ポンプ機能の詳細なリストは、『Oracle Databaseユーティリティ』を参照してください。

- 「オリジナルのEXPおよびIMPユーティリティを使用するタイミング」

データ・ポンプ・エクスポートおよびインポートには、次のようなメリットがあります。

- データおよびメタデータのフィルタ機能は、オリジナルのエクスポート・ユーティリティで用意されていた機能を上回ります。データ・ポンプでは、オブジェクトおよびオブジェクトの種類に基づいてエクスポートおよびインポートされたメタデータを、INCLUDEおよびEXCLUDEパラメータを使用してフィルタ処理できます。

- データベースの一部を様々なモード(全体データベース・モード、スキーマ・モード、表モード、表領域モード、トランスポータブル表領域モードなど)でアンロード/ロードできます。(『Oracle Databaseユーティリティ』のデータ・ポンプ・エクスポートのモードおよびデータ・ポンプ・インポートのモードに関する項を参照してください。)

- インポート操作中のパーティション表の処理方法を、PARTITION_OPTIONSパラメータを使用して指定できます。

- 全種類のデータ型がサポートされます。

関連項目:
データ・ポンプ・エクスポートおよびインポートの概要は、『Oracle Databaseユーティリティ』を参照してください。

オリジナルのEXPおよびIMPユーティリティを使用するタイミング

データベースに対して次の種類のアップグレードおよびダウングレードを行う場合は、オリジナルのエクスポート/インポート・ユーティリティが必要です。

- Oracle Database 10gリリース1(10.1)より前のリリースからアップグレードする場合は、オリジナルのエクスポート/インポート・ユーティリティを使用してデータを移動する必要があります。同様に、Oracle Database 10gリリース1(10.1)より前のリリースにダウングレードする場合も、オリジナルのエクスポート/インポート・ユーティリティを使用する必要があります。

- Oracle Database 10gリリース1(10.1)より前のリリースにダウングレードする必要がある場合は、下位互換性を確保するために引き続きオリジナルのエクスポート・ユーティリティがサポートされます。

- XMLTypeの表またはXMLTypeの列を含む(スキーマ・ベースおよびスキーマ・ベース以外の)表をOracle Database 11gリリース1(11.1)からOracle Database 10gリリース2(10.2)に移動する場合。

関連項目:
プラットフォーム間のデータベース移動の詳細は、『Oracle Databaseユーティリティ』を参照してください。

Oracle Databaseをアップグレードする場合のエクスポート/インポートの要件

データ・ポンプ・エクスポート・ユーティリティで生成されるダンプ・ファイルには、オリジナルのエクスポート・ユーティリティで生成されるダンプ・ファイルとの互換性がありません。したがって、オリジナルのエクスポート(EXP)・ユーティリティで生成されたファイルは、データ・ポンプ・インポート(impdp)・ユーティリティでインポートすることはできません。逆もまた同様です。

エクスポート・ダンプ・ファイルおよびアップグレードの概要

いずれかのエクスポート・ユーティリティで作成されたダンプ・ファイルは、Oracle Databaseのすべての上位リリースにインポートできます。たとえば、Oracle8のオリジナルのエクスポート・ユーティリティのダンプ・ファイルは、Oracle8i、Oracle9i、Oracle Database 10gおよびOracle Database 11gのオリジナルのインポート・ユーティリティでインポートできます。

表7-1に、Oracle Database 11gリリース2(11.2)より前のリリースからデータをエクスポートし、そのデータをOracle Database 11gリリース2(11.2)にインポートする場合に使用するリリースを示します。

表7-1 リリース11.2より前のリリースからのエクスポートおよびリリース11.2へのインポート

エクスポート元

インポート先

使用するエクスポートのバージョン

使用するインポートのバージョン

リリース11.1

リリース11.2

データ・ポンプ・エクスポート・リリース11.1

データ・ポンプ・インポート・リリース11.2

リリース10.2

リリース11.2

データ・ポンプ・エクスポート・リリース10.2

データ・ポンプ・インポート・リリース11.2

リリース10.1

リリース11.2

データ・ポンプ・エクスポート・リリース10.1

データ・ポンプ・インポート・リリース11.2

リリース9.2

リリース11.2

オリジナルのエクスポートのリリース9.2

オリジナルのインポートのリリース11.2

リリース8.1.7

リリース11.2

オリジナルのエクスポートのリリース8.1.7

オリジナルのインポートのリリース11.2

リリース8.0.6

リリース11.2

オリジナルのエクスポートのリリース8.0.6

オリジナルのインポートのリリース11.2

リリース7.3.4

リリース11.2

オリジナルのエクスポートのリリース7.3.4

オリジナルのインポートのリリース11.2

ダウングレードに必要なエクスポートおよびインポートの要件

ダウングレードは、最大で1つ前のOracle Databaseリリースまで可能です。たとえば、現行のデータベースがOracle Database 11gリリース1(11.1)の場合は、ダウングレードがサポートされているリリースはOracle Database 10gリリース2(10.2)のみです。

下位互換性のあるダンプ・ファイルを取得するための要件

- データ・ポンプ・エクスポートを使用する場合は、現行バージョンのデータ・ポンプ・エクスポート・ユーティリティを使用しますが、VERSIONパラメータには、ターゲットである古いバージョンを設定します。
データ・ポンプ・インポートは、現在のデータベース・バージョンより新しいデータベース・バージョンで作成されたダンプ・ファイル・セットを読み込むことができません(ただし、VERSIONパラメータをターゲット・データベースのバージョンに設定して、ダンプ・ファイル・セットを作成している場合は除きます)。したがって、ダウングレードを行う場合は、VERSIONパラメータをターゲット・データベースのバージョンに設定して、データ・ポンプのエクスポートを使用するようにしてください。

関連項目:
VERSIONパラメータの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

- オリジナルのエクスポートを使用する場合は、古いバージョンのエクスポート(exp)を実行し、ダウングレード先のデータベース・バージョンと互換性のあるダンプ・ファイルを作成します。その後、ターゲットでオリジナルのインポート・ユーティリティを実行します。
オリジナルのエクスポートのダンプ・ファイルは、前のOracle Databaseリリースのインポート・ユーティリティとは下位互換性が ありません。そのため、エクスポートされたデータは、前のOracle Databaseリリースのインポート・ユーティリティではインポートできません。たとえば、Oracle9iのエクスポート・ダンプ・ファイルは、Oracle8iのインポート・ユーティリティではインポートできず、Oracle Database 10gのエクスポート・ダンプ・ファイルは、Oracle9iのインポート・ユーティリティではインポートできません。次の表に、例を示します。

関連項目:
異なるリリースおよびバージョンのエクスポートの使用の詳細は、『Oracle Databaseユーティリティ』を参照してください。

表7-2に、Oracle Database 11gリリース2(11.2)からデータをエクスポートし、そのデータを前のリリースにインポートする場合に使用するリリースを示します。メジャー・リリースのダウングレードは、11.1、10.2および10.1でサポートされています。

表7-2 リリース11.1からのデータのエクスポートおよび以前のリリースへのインポート

エクスポート元

インポート先

使用するエクスポートのバージョン

使用するインポートのバージョン

リリース11.2

リリース11.1

VERSION=11.1に設定したデータ・ポンプ・エクスポート・リリース11.2

データ・ポンプ・インポート・リリース11.1

リリース11.1

リリース10.2

VERSION=10.2 に設定したデータ・ポンプ・エクスポート・リリース11.1

データ・ポンプ・インポート・リリース10.2

リリース10.2

リリース10.1

VERSION=10.1 に設定したデータ・ポンプ・エクスポート・リリース10.2

データ・ポンプ・インポート・リリース10.1

注意:
オリジナルのエクスポート・ユーティリティを使用する場合に、ソース・データベースがターゲット・データベースより新しい場合は、エクスポートを正常に終了させるために、前の(古い)リリースに付属しているcatexp.sqlスクリプトを実行する必要があります。いったんエクスポートが終了したら、新しいリリースのほうでcatexp.sqlスクリプトを実行し、エクスポート・ビューをリストアします。次の手順を実行します。

1. エクスポートされるデータベース上で、古いほうのCATEXP.SQLスクリプトを実行します。

2. 古いほうのエクスポート・ユーティリティを使用して、ダンプ・ファイルを作成します。

3. 古いほうのインポート・ユーティリティを使用して、ターゲット・データベースにインポートします。

4. エクスポートされたデータベース上で、新しいほうのCATEXP.SQLスクリプトを実行します。

以前のリリースと互換性がないデータでのエクスポート/インポートの使用方法

データを以前のリリースにエクスポートする場合、以前のリリースと互換性のないデータはエクスポートできないか、またはいくつかの機能が失われた状態でエクスポートされます。

通常は、データを以前のリリースにエクスポートする必要がある場合は、データをエクスポートする前に、以前のリリースとの非互換性をできるだけ多く削除します。

データ・ポンプ・エクスポート/インポートを使用したデータベースのアップグレード

データ・ポンプのエクスポート/インポート・ユーティリティを使用してデータベースをアップグレードするには、次の手順を実行します。

1. 現行データベースに付属のエクスポート・ユーティリティを使用して、現行データベースのデータをエクスポートします。現行データベースでのエクスポート・ユーティリティの使用方法の詳細は、現行の『Oracle Databaseユーティリティ』ドキュメントを参照してください。
一貫性のあるエクスポート結果を得るには、エクスポートの実行中と実行後は現行データベースが更新不可である必要があります。エクスポート実行後にユーザーが現行データベースを更新できるようにする場合は、現行データベースで行われた変更を、インポート完了後に新しいデータベースにコピーするための手順をプロシージャを配置し、その後で現行データベースを使用可能にします。

2. 新しいOracle Databaseソフトウェアをインストールします。インストールは、オペレーティング・システム別に行います。Oracle Databaseのインストール手順は、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

3. 新しいデータベースに現行データベースと同じ名前を付ける場合は、新しいデータベースを作成する前に現行データベースを停止します。

4. 新しいデータベースを作成します。

関連項目:
データベースの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

5. SQL*Plusを新しいOracle Database環境で起動します。

6. SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

7. STARTUPを使用してOracle Databaseインスタンスを起動します。

8. オプションで、ソース・データベースとは異なる記憶域パラメータを指定できます。
新しいデータベースに表領域、ユーザーおよび表を事前に作成し、記憶域パラメータを変更することにより、ディスク領域の使用状況を改善できます。SQL*Plusを使用して表を事前に作成する場合は、元のデータベースとの互換モードで実行するか、またはインポート中に発生する特定のデータ定義の変換を許可するようにします。項目を事前作成した場合は、次のいずれかのオプションを選択します。

- データ・ポンプ・インポートでTABLE_EXISTS_ACTION=APPENDを指定

- オリジナルのインポート・ユーティリティでIGNORE=Yを指定

注意:
新しいデータベースをソース・データベースと同じコンピュータ上に作成し、ソース・データベースのデータ・ファイルを上書きしない場合は、事前に表領域を作成し、インポート時に次のオプションのいずれかを指定する必要があります。

- データ・ポンプ・インポートでREUSE_DATAFILES=Nを指定
ダンプ・ファイル・セット内の古い名前に対する参照が、競合しない新しい名前にマップしなおされるように、REMAP_DATAFILE、REMAP_TABLESPACEおよびREMAP_TABLEオプションの使用を、必要に応じて検討します。

- オリジナルのインポート・ユーティリティでDESTROY=Nを指定

9. 新しいデータベースのインポート・ユーティリティを使用して、現行データベースからエクスポートしたオブジェクトをインポートします。インポート・セッションからファイルに情報メッセージやエラー・メッセージを保存するには、次のいずれかのパラメータを組み込んでください。

- データ・ポンプ・インポートでLOGFILEパラメータを指定

- オリジナルのインポート・ユーティリティでLOGパラメータを指定

関連項目:
データ・ポンプ・インポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

10. インポート作業が完了したら、どのオブジェクトのどのインポートが正常に終了してどれが失敗したか(失敗したものがある場合)を、インポート・ログ・ファイルで確認します。

関連項目:
エラーの対処については、『Oracle Databaseユーティリティ』およびOracle DatabaseのREADME.docを参照してください。

11. その他のインポート方法(『Oracle Databaseユーティリティ』を参照)を使用するか、またはデータベース・オブジェクトを作成するSQLスクリプトを使用して、インポートに失敗したオブジェクトを作成しなおします(または、完全に新規のインポートを開始します)。

注意:
データ・ポンプ・エクスポートまたはインポートのジョブで致命的なエラーが発生した場合は、エラーの原因となった条件を修正した後ジョブを再起動できます。ジョブは、エラーが発生した箇所から自動的に続行されます。

12. エクスポートの実行後に現行データベースに変更を加える場合は、ユーザーに使用可能にする前に、それらの変更が新しいデータベースに伝搬されるようにします。詳細は、手順1を参照してください。

13. 第4章「Oracle Databaseのアップグレード後の作業」に示す手順を実行します。

ネットワーク・リンクを使用したデータベース全体のインポート

「データ・ポンプ・エクスポート/インポートを使用したデータベースのアップグレード」にかわる手順として、データベース・リンクを介してデータ・ポンプ・インポート・ユーティリティを使用して、中間ダンプ・ファイルなしでソース・データベースからインポート先データベースへデータベース全体のインポートを実行できます。

注意:
相互運用性のエラーを回避するには、アップグレードするデータベースに適切なパッチ・セットを確実に適用します。最新のパッチ・セットを取得するには、My Oracle Support(https://support.oracle.com)を参照してください。
また、サポート・ノートID 4511371.8で、ORA-6544およびORA-4052エラーに関する説明を参照することもできます。

impdpを介してネットワーク・リンクを使用するには、次の手順を実行します。

1. ソース・データベースでエクスポートを実行するユーザーにEXP_FULL_DATABASEロールがあることを確認します。
データベース・リンク作成時に、このユーザーを指定する必要があります。

2. インポート先データベースでインポートを実行するユーザーにIMP_FULL_DATABASEロールがあることを確認します。

3. ソース・データベースとインポート先データベースとの間にデータベース・リンクを作成してテストします。

4. 次のコマンドを実行します。import_userはインポートを実行するユーザーのユーザー名で、db_linkはエクスポートを実行するユーザーが所有するデータベース・リンクの名前です。

IMPDP import_user/password NETWORK_LINK=db_link FULL=Y;

5. インポート操作のログ・ファイルが、DATA_PUMP_DIRディレクトリに書き込まれます。このディレクトリの場所は、次のコマンドを実行して検出できます。

SQL> select * from dba_directories where DIRECTORY_NAME like 'DATA_PUMP_DIR';

注意:
XMLオブジェクトはソース・データベースからエクスポートされません。

注意:
インポート操作によって新しいインポート先サーバーにユーザーが再作成され、dba_usersの作成日付は実際のインポート日付を示します。有効期限は、creation_date + password_life_timeに更新されます。新しいサーバーの上のdba_usersのパラメータは、インポート元サーバーの上のdba_usersパラメータとは異なります。

A Oracle Databaseのアップグレード後の動作の変更点

Oracle9iリリース2(9.2)、Oracle Database 10gリリース1(10.1)、Oracle Database 10gリリース2(10.2)、Oracle Database 11gリリース1(11.1)およびOracle Database 11gリリース2(11.2)の間には、動作に関する重要な変更点があります。動作の変更によって発生する可能性がある危険性を最小限に抑えるために、データベース管理者(DBAとも呼ばれる)が詳細な情報を得て決定を行う必要がある動作の変更点に焦点を当てて説明します。新しいOracle Database 11gリリースのすべての動作の変更または新機能については説明しません。

この付録では、次の項目について説明します。

- Oracle Database 11gリリース2(11.2)で発生する互換性および相互運用性の問題

- Oracle Database 11gリリース1(11.1)で発生する互換性および相互運用性の問題

- Oracle Database 10gリリース2(10.2)で発生する互換性および相互運用性の問題

- Oracle Database 10gリリース1(10.1)で発生する互換性および相互運用性の問題

関連項目:

- Oracle Database 11gリリースで導入された新機能の完全なリストについては、『Oracle Database新機能ガイド』を参照してください。

- Oracle Database 11gリリースの新しい初期化パラメータ、新しい静的データ・ディクショナリ・ビューおよび新しい動的パフォーマンス・ビューのリストについては、『Oracle Databaseリファレンス』のOracle Databaseリファレンスの新機能に関する項を参照してください。

注意:
この付録で示す初期化パラメータの一部は、オペレーティング・システム固有です。これらの初期化パラメータの詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

Oracle Database 11gリリース2(11.2)で発生する互換性および相互運用性の問題

次の各項では、Oracle Database 11gリリース2(11.2)で発生する互換性および相互運用性の問題と、変更によって発生する問題を回避するための対処方法を説明します。

- Oracle Enterprise Manager Database Controlの非推奨

- Oracle Netリスナーで非推奨のSNMPサポート

- PL/SQLプロシージャの変更点

- 非推奨のXML DB構造体

- Oracle DatabaseでのCursor_sharing=similarの廃止

- チェンジ・データ・キャプチャの計画されているサポート終了

- Oracle Database 11gリリース2(11.2)で非推奨の初期化パラメータ

- Oracle Database 11gリリース2(11.2)で廃止された初期化パラメータ

- Oracle Database 11gリリース2(11.2)で非推奨の静的データ・ディクショナリ・ビュー

- Oracle Database 11gリリース2(11.2)で非推奨の動的パフォーマンス・ビュー

- Oracle Database 11gリリース2(11.2)で非推奨となった機能

- LOG_ARCHIVE_DEST_nパラメータの変更

- QOSCTLサービスのクオリティ(QoS)コマンドの-checkpasswdの非推奨

- 削除ツールの-cleanupOBaseフラグのサポート終了

- DES、RC4およびMD5アルゴリズムのサポート終了

Oracle Enterprise Manager Database Controlの非推奨

Oracle Enterprise Manager Database Controlは、Oracle Database 11gリリース2 (11.2)では非推奨で、Oracle Databaseの次のメジャー・リリースでは、サポートが終了しています。Oracle Database 11gリリース2 (11.2)の存続中および強化サポートの終了まで、Oracle Enterprise Manager Database Controlは、すべてのパッチ・セットも含め、完全にサポートされています。

Oracle Netリスナーで非推奨のSNMPサポート

Oracleでは、Oracle Database 11gリリース2(11.2)のOracle NetリスナーでのSNMPサポートを非推奨としています。新しい実装ではSNMPを使用しないことをお薦めします。

関連項目:
Doc ID 1341834.1(https://support.oracle.com)

PL/SQLプロシージャの変更点

次のPL/SQLプロシージャは、リリース11.2.0.3でパッケージDBMS_XDBからパッケージDBMS_XDB_ADMINに移動されました。

- moveXDB_tablespace

- rebuildHierarchicalIndex

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

JOB_QUEUE_PROCESSESパラメータおよびジョブのスケジューリング

Oracle Database 11gリリース2(11.2)以上では、JOB_QUEUE_PROCESSESを0に設定すると、DBMS_SCHEDULERおよびDBMS_JOBジョブが実行されません。以前は、JOB_QUEUE_PROCESSESを0に設定すると、DBMS_JOBジョブは実行されませんでしたが、DBMS_SCHEDULERジョブは影響を受けることなく実行されました。デフォルト値は1000です。

Oracle Databaseによって、ジョブ・キューの設定が上書きされ、アップグレード・モード中にスケジューラ・ジョブが無効化されます。したがって、Oracle Databaseのアップグレード時にこの設定を変更する必要はありません。

関連項目:
このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

非推奨のXML DB構造体

次のXML DB構造体は、リリース11.2.0.3で非推奨になりました。

- PL/SQLプロシージャDBMS_XDB_ADMIN.createRepositoryXMLIndex

- PL/SQLプロシージャDBMS_XDB_ADMIN.XMLIndexAddPath

- PL/SQLプロシージャDBMS_XDB_ADMIN.XMLIndexRemovePath

- PL/SQLプロシージャDBMS_XDB_ADMIN.dropRepositoryXMLIndex

- XMLスキーマの注釈(属性)csx:encodingType

- ハイブリッドのXMLType storageにおけるCLOB部分のXMLIndex索引

関連項目:
『Oracle XML DB開発者ガイド』

Oracle DatabaseでのCursor_sharing=similarの廃止

cursor_sharing=similarパラメータはOracle Databaseリリース11.2.0.3では非推奨です。かわりに、適応カーソル共有を使用してください。

関連項目:
適応カーソル共有の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

チェンジ・データ・キャプチャの計画されているサポート終了

Oracleチェンジ・データ・キャプチャは、Oracle Databaseの将来のリリースにおいてサポートされなくなり、Oracle GoldenGateに置き換えられます。そのため、新しいアプリケーションにはOracle GoldenGateを使用することを強くお薦めします。

Oracle Database 11gリリース2(11.2)では、チェンジ・データ・キャプチャは旧リリースと同様に機能します。チェンジ・データ・キャプチャを現在使用している場合、当分は引き続き使用できます。ただし、チェンジ・データ・キャプチャは今後拡張されません。

関連項目:
Oracle GoldenGateの詳細は、Oracle Technology Networkのhttp://www.oracle.com/technetwork/middleware/goldengate/overview/index.htmlを参照してください。

Oracle Database 11gリリース2(11.2)で非推奨の初期化パラメータ

非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。

現行データベースで非推奨に指定されているすべての初期化パラメータのリストを表示するには、次のSQL文を発行します。

SQL> SELECT name FROM v$parameter
WHERE isdeprecated = 'TRUE';

次の初期化パラメータはOracle Database 11gリリース2(11.2)で非推奨となりました。

ACTIVE_INSTANCE_COUNT
PARALLEL_IO_CAP_ENABLED

Oracle Database 11gリリース2(11.2)で廃止された初期化パラメータ

次の初期化パラメータはOracle Database 11gリリース2(11.2)で廃止されました。

注意:
廃止された初期化パラメータを1つ以上使用しているデータベースについては、起動はできますが、警告が戻され、アラート・ログに記録されます。

DRS_START
GC_FILES_TO_LOCKS
MAX_COMMIT_PROPAGATION_DELAY
PLSQL_NATIVE_LIBRARY_DIR
PLSQL_NATIVE_LIBRARY_SUBDIR_COUNT
SQL_VERSION

Oracle Database 11gリリース2(11.2)で非推奨の静的データ・ディクショナリ・ビュー

次の静的データ・ディクショナリ・ビューはOracle Database 11gリリース2(11.2)で非推奨となりました。

ALL_STREAMS_STMTS (replaced by DBA_STREAMS_STMTS)
ALL_STREAMS_STMT_HANDLERS (replaced by DBA_STREAMS_STMT_HANDLERS)
DBA_COMPARISON_SCAN_SUMMARY (replaced by DBA_COMPARISON_SCAN)
USER_COMPARISON_SCAN_SUMMARY (replaced by USER_COMPARISON_SCAN)

Oracle Database 11gリリース2(11.2)で非推奨の動的パフォーマンス・ビュー

次の動的パフォーマンス・ビューはOracle Database 11gリリース2(11.2)で非推奨となりました。

V$FLASH_RECOVERY_AREA_USAGE(V$RECOVERY_AREA_USAGEに変更)

Oracle Database 11gリリース2(11.2)で非推奨となった機能

次のOracle Databaseの機能はOracle Database 11gリリース2(11.2)で非推奨となりました。下位互換性を保持する目的で、これらの機能がこのリリースでサポートされています。ただし、これらの非推奨となった機能は移行の対象外とすることをお薦めします。

ディクショナリ管理表領域

ローカル管理表領域を作成することをお薦めします。ローカル管理表領域は、ディクショナリ管理表領域より非常に効率的に管理されます。

MAX_JOB_SLAVE_PROCESSES

MAX_JOB_SLAVE_PROCESSESは非推奨となりました。かわりにJOB_QUEUE_PROCESSESを使用してください。

LOG_ARCHIVE_DEST_nパラメータの変更

Oracle Database 11gリリース2(11.2)以上では、LOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_nパラメータでサポートされる宛先の数が10から31に増えました。宛先LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31は、SYNC、ARCH、LOCATION、MANDATORY、ALTERNATEまたはDEPENDENCY属性をサポートしておらず、また、ALTERNATEまたはDEPENDENCY属性のターゲットとして指定することもできません。

LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31を使用できるのは、COMPATIBLE初期化パラメータを11.2.0以上に設定した場合のみです。

QOSCTLサービスのクオリティ(QoS)コマンドの-checkpasswdの非推奨

このリリースでは、構文qosctl -checkpasswd username passwordが非推奨になりました。QOSCTL構文とコマンドの詳細は、『Oracle Database Quality of Service Managementユーザーズ・ガイド』を参照してください。

削除ツールの-cleanupOBaseフラグのサポート終了

削除ツールの-cleanupOBaseフラグは、Oracle Database 11gリリース2 (11.2)でサポートが終了しました。このフラグの代替機能はありません。

DES、RC4およびMD5アルゴリズムのサポート終了

DES、RC4およびMD5アルゴリズムは、Oracle Database 11gリリース2 (11.2)でサポートが終了しました。

Oracle Database 11gリリース1(11.1)で発生する互換性および相互運用性の問題

次の各項では、Oracle Database 11gリリース1(11.1)で発生する互換性および相互運用性の問題と、これらの問題によって発生する問題を回避するための対処方法を説明します。

- Oracle Database 11gリリース1(11.1)で非推奨の初期化パラメータ

- Oracle Database 11gリリース1(11.1)で廃止された初期化パラメータ

- Oracle Database 11gリリース1(11.1)で列が削除された静的データ・ディクショナリ・ビュー

- Oracle Database 11gリリース1(11.1)で非推奨となった機能

- 自動メンテナンス・タスク管理

- ASM管理用の新しいSYSASM権限およびOSASMグループ

- ASMディスク・グループの互換性

- COMPUTE STATISTICS句とESTIMATE STATISTICS句

- Oracle Data MiningモデルおよびDMSYSスキーマ・オブジェクト

- Oracle Data Miningスコアリング・エンジン

- SQL計画管理とSQL計画ベースラインの制御

- Oracle XML DatabaseでのバイナリのXMLのサポート

- PL/SQLのネイティブ・コンパイルとネットワーク・ユーティリティ・パッケージのアクセス制御

- PL/SQLの制御パラメータ

- Oracle XML DBにおけるWebDAV ACL評価ルールの変更

- サマリー管理とSQLアクセス・アドバイザ

- Standard Editionの初期データベース

- コア・ダンプの位置

- UNDO_MANAGEMENTの新規デフォルト値

- LOG_ARCHIVE_DEST_nパラメータ

- SHARED_POOL_SIZEパラメータ

- JOB_QUEUE_PROCESSESパラメータおよびジョブのスケジューリング

- 自動診断リポジトリ

Oracle Database 11gリリース1(11.1)で非推奨の初期化パラメータ

次の初期化パラメータはOracle Database 11gリリース1(11.1)で非推奨となりました。

すべての非推奨の初期化パラメータのリストを表示するには、次のSQL文を発行します。

SQL> SELECT name FROM v$parameter
WHERE isdeprecated = 'TRUE';

非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。

BACKGROUND_DUMP_DEST(DIAGNOSTIC_DESTに変更)
COMMIT_WRITE
CURSOR_SPACE_FOR_TIME
INSTANCE_GROUPS
LOG_ARCHIVE_LOCAL_FIRST
PLSQL_DEBUG(PLSQL_OPTIMIZE_LEVELに変更)
PLSQL_V2_COMPATIBILITY
REMOTE_OS_AUTHENT
RESOURCE_MANAGER_CPU_ALLOCATION
(CQ_NOTIFICATION$_REG_INFOオブジェクトの)STANDBY_ARCHIVE_DEST
TRANSACTION_LAG属性
USER_DUMP_DEST(DIAGNOSTIC_DESTに変更)

Oracle Database 11gリリース1(11.1)で廃止された初期化パラメータ

次の初期化パラメータはOracle Database 11gリリース1(11.1)で廃止されました。

DDL_WAIT_FOR_LOCKS
LOGMNR_MAX_PERSISTENT_SESSIONS
PLSQL_COMPILER_FLAGS

注意:
廃止された初期化パラメータを1つ以上使用しているデータベースについては、起動はできますが、警告が戻され、アラート・ログに記録されます。

Oracle Database 11gリリース1(11.1)で列が削除された静的データ・ディクショナリ・ビュー

Oracle Database 11gリリース1(11.1)では、次の静的データ・ディクショナリ・ビューの列が削除されました。

静的データ・ディクショナリ・ビュー

削除された列

V$DATAFILE

PLUGGED_IN

Oracle Database 11gリリース1(11.1)で非推奨となった機能

この項では、Oracle Database 11gリリース1(11.1)で非推奨となった機能を示します。下位互換性を保持する目的で、これらの機能がこのリリースでサポートされています。ただし、これらの非推奨となった機能は移行の対象外とすることをお薦めします。

- Oracle Ultra Search

- Java Development Kit(JDK)1.4
JDK 5.0の使用をお薦めします。ただし、JDK 1.5も完全にサポートされます。

- CTXXPATH索引
かわりにXMLIndexを使用することをお薦めします。

関連項目:
『Oracle XML DB開発者ガイド』

自動メンテナンス・タスク管理

Oracle Database 11gリリース1(11.1)の新しいデータベース・コンポーネントである自動メンテナンス・タスク管理では、すべての自動メンテナンス・タスクがメンテナンス期間の拡張セット内にスケジュールされます。自動メンテナンス・タスク管理を使用することにより、オプティマイザ統計の収集、セグメント・アドバイザおよび自動SQLチューニング・アドバイザなどのタスクについて、メンテナンス・タスクのスケジュール作成をより細かく制御することが可能です。

自動メンテナンス・タスク管理では、既存のメンテナンス期間がすべて使用されます(たとえば、MAINTENANCE_WINDOW_GROUPの現行のメンバーである期間)。そのメンテナンス期間に関連付けられた既存のリソース・プランが使用されます。ただし、AUTOTASK_CONSUMER_GROUPは、AutoTaskリソース・サブプランによってリソース・プラン内で置換されます。

オプティマイザ統計の収集またはセグメント・アドバイザのいずれかを10gで無効にしている場合は、対応する自動メンテナンス・タスク管理機能は、Oracle Database 11gリリース1(11.1)へのアップグレード後に無効になります。

次に、メンテナンス・タスクのデフォルト設定を示します。

- オンライン・バックアップは無効です。

- オプティマイザ統計の収集は有効です。

- セグメント・アドバイザは有効です。

- 自動SQLチューニングは有効です。

その他の自動メンテナンス・タスク管理クライアントはすべてデフォルトで有効です。

自動メンテナンス・タスク管理は、Oracle Database 11gリリース1(11.1)へのアップグレード時に自動的に有効になりますが、AutoTaskオンライン・バックアップは自動的に有効にはなりません。必要な場合は、データベースをアップグレードした後に、手動でオンライン・バックアップを構成する必要があります。データベースをダウングレードした場合、自動メンテナンス・タスク管理は、そのリリースでのデフォルトの動作状態に戻ります。

関連項目:
自動メンテナンス・タスク管理機能の詳細は、『Oracle Database管理者ガイド』を参照してください。

ASM管理用の新しいSYSASM権限およびOSASMグループ

Oracle Database 11gリリース1(11.1)には、ASM管理タスクの実行目的に特化したSYSASM権限という新しい権限が導入されています。SYSDBA権限のかわりにSYSASM権限を使用することにより、ASMの管理職務とデータベースの管理職務を明確に区別できます。

ディスク・グループのメンテナンス(CREATE DISKGROUP、MOUNT/DISMOUNT、ADD/DROP DISK、ONLINE/OFFLINE DISK、DROP DISKGROUP)をSYSDBAで実行すると、ASMのalert.logに警告メッセージが表示されます。これらの作業はSYSDBAでは非推奨になっており、SYSASMで実行する必要があります。

OSASMは、ASM用として専用に使用される新しいオペレーティング・システム(OS)・グループです。OSASMグループのメンバーはOS認証を使用してAS SYSASMで接続が可能であり、ASMに対するすべてのアクセス権限を持ちます。

この機能の詳細は、「Oracle ASMインスタンスのシステム認証のアップグレードの概要」を参照してください。

関連項目:
ASMインスタンスへのアクセスの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

ASMディスク・グループの互換性

Oracle Database 11gリリース1(11.1)以上では、ソフトウェア・バージョンをまたいでOracle DatabaseとASMのディスク・グループの互換性設定を拡張できます。新しい互換性属性であるcompatible.rdbmsおよびcompatible.asmを使用して、データベース用のディスク・グループおよびASM用のディスク・グループを使用するために必要な最小ソフトウェア・バージョンをそれぞれ指定できます。

この機能により、Oracle Database 10gリリース1(10.1)、Oracle Database 10gリリース2(10.2)およびOracle Database 11gリリース1(11.1)のディスク・グループで構成される異機種環境が実現します。デフォルトでは、属性は両方とも10.1に設定されます。新機能を活用するには、これらの属性を拡張する必要があります。

関連項目:
ASMディスク・グループの互換性の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

COMPUTE STATISTICS句とESTIMATE STATISTICS句

以前のリリースでは、ANALYZE...COMPUTE STATISTICSおよびANALYZE...ESTIMATE STATISTICS句を使用して、索引での統計の収集を開始および停止できました。これらの句は廃止されました。Oracle Database 11gリリース1(11.1)では、索引の作成中および再構築中に統計が自動的に収集されます。今回のバージョンでは、これらの句はサポートされていません。

Oracle Data MiningモデルおよびDMSYSスキーマ・オブジェクト

Oracle Database 11gリリース1(11.1)へのアップグレード中に、DMSYSスキーマ・オブジェクトは大きな制約もなく、ユーザー・スキーマに存在するユーザー・モデルとともにアップグレードされます。アップグレード完了時に、マイニングのメタデータはSYSスキーマに移行されますが、ユーザー・モデルは新しいメタデータで継続して機能します。COMPATIBLE初期化パラメータを11.0.0に設定した後、DMSYSスキーマを削除することをお薦めします。また、データベース管理者は、既存のユーザーが引き続きマイニング・モデルを作成できるように、新しいCREATE MINING MODEL権限を付与する必要があります。

ユーザー・スキーマに存在するデータ・マイニング・モデルは、モデルのアップグレードの一環として自動的にアップグレードされますが、これはOracle Databaseのアップグレード処理で欠かすことのできない部分です。データ・マイニング・モデルのエクスポートおよびインポート・ユーティリティを、データ・マイニング・モデルのリリース間アップグレードの手段として使用することもできます。

データベースのダウングレード処理中に、データ・マイニングのコンポーネントは以前のリリースにダウングレードされます。ダウングレード処理では、パッケージ、タイプおよび表オブジェクトなどのDMSYSオブジェクトが再ロードされる他、ユーザー・スキーマがある場合はダウングレードするユーザー・スキーマ内のモデル・オブジェクトが再ロードされます。データベースのアップグレードの一環として作成されたオブジェクトは、ダウングレード処理中にSYSスキーマから削除されます。これは透過的な処理であり、ユーザーの介入は不要です。

アップグレード(およびCOMPATIBLE初期化パラメータを11.0.0に設定してからDMSYSスキーマの削除)を行った後に、Oracle Database 10gリリース1(10.1)からエクスポートされたモデルがすでに存在しないDMSYSスキーマを参照しているために、そのモデルのインポート作業が多少複雑になる場合があります。このような場合の対策として、Oracle Database 10gリリース1(10.1)のデータベースに存在するDMSYSのインタフェースを十分(かつ必要最小限)に模倣するスクリプトが用意されおり、インポート処理を続行できるようになっています。モデルが古くなると、通常ユーザーは古いモデルをインポートするよりもモデルを作成しなおすため、このような例は一般的には発生しません。

データ・マイニングはCOMPATIBLE初期化パラメータで保護されていないことに注意してください。データベースをOracle Database 11gリリース1(11.1)にアップグレードしても、COMPATIBLEが10.1.0または10.2.0に設定されている場合は、データ・マイニングの新機能および既存の機能はすべて動作します。Oracle Database 11gリリース1(11.1)のみで使用できる新しいマイニング・モデルを作成し、その後Oracle Database 10gリリース2(10.2)にデータベースをダウングレードすることにした場合は、ダウングレードする前に新しいマイニング・モデルを削除することが必要になります。

Oracle Data Miningスコアリング・エンジン

Oracle Database 11gリリース1(11.1)以上では、Oracle Data Mining Scoring Engineのインストールができなくなりました。

関連項目:
『Oracle Data Mining管理者ガイド』

SQL計画管理とSQL計画ベースラインの制御

Oracle Database 11gリリース1(11.1)では、ストアド・アウトラインの使用は非推奨となっています。かわりに、オプティマイザでSQL文の実行計画履歴をメンテナンスできるSQL計画管理機能を使用する必要があります。実行計画履歴を使用することにより、SQL文の計画変更を示している新しい計画をオプティマイザで検出することができます。オプティマイザは新しい計画を検出すると、新しい計画を保存し、パフォーマンス評価の対象としてマーキングし、現時点で優れた計画とみなされている古い計画を使用します。オプティマイザが新しい計画を使用するのは、新しい計画のほうが古い計画よりもパフォーマンスが優れていることが検証された場合のみです。SQL計画ベースラインは、優れたSQL文の計画とみなされている一連の計画で構成されます。

SQLプロファイルの移行

SQLプロファイルは、Oracle Database 10gリリース1(10.1)で導入されたSQL管理オブジェクトです。これらのオブジェクトは、SYSTEM表領域内に定義されたディクショナリの一部に存在しました。SQLプロファイルが格納されるディクショナリ表は再構築され、SQL管理オブジェクトであるSQL計画ベースラインの記憶域としても使用できるようになりました。また、これらのディクショナリ表はSYSAUX表領域内に定義されています。

Oracle Database 10gリリース1(10.1)からOracle Database 11gリリース1(11.1)にアップグレードすると、既存のSQLプロファイルはデータベース・アップグレード・スクリプトによってSYSTEM表領域からSYSAUX表領域に移動されます。したがって、Oracle Database 11gリリース1(11.1)のデータベース・インスタンスが起動していてもSYSAUX表領域がオフラインの場合は、オプティマイザでSQL管理オブジェクトにアクセスすることはできず、このことが一部のSQLワークロードのパフォーマンスに影響する場合があります。一方、Oracle Database 10gリリース1(10.1)の場合、SQLプロファイルはSYSTEM表領域に格納されていたため、SQLプロファイルが使用できないということはありませんでした。Oracle Database 11gリリース1(11.1)以上では、SYSAUX表領域をオフラインにすると、SQLのパフォーマンスに影響が出る可能性があることに注意してください。

下位互換性

Oracle Database 11gリリース1(11.1)では、下位互換性は次のようになっています。

- SQL文のストアド・アウトラインがユーザー・セッションに対してアクティブな場合(たとえば、ストアド・アウトラインのカテゴリがユーザー・セッションのカテゴリと一致する場合)、文はストアド・アウトラインを使用してコンパイルされます。

- SQL文に対してプライベート・アウトラインが使用可能な場合、文はプライベート・アウトラインを使用してコンパイルされます。

SQL文に対してストアド・アウトラインが使用可能な場合、SQL計画管理機能は使用されません。ただし、別のユーザー・セッションで同じSQL文がアクティブなストアド・アウトラインなしで使用されている場合は、SQL計画管理機能が使用されます。

関連項目:

- SQL計画管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_SPMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle XML DatabaseでのバイナリのXMLのサポート

Oracle Database 11gリリース1(11.1)の新しいオプションであるバイナリのXML記憶域オプションは、COMPATIBLE初期化パラメータを11.0.0以上に設定した場合に使用できます。この記憶域オプションを使用して表または列を作成すると、互換性の最小要件が確認されます。最小要件は、バイナリのXMLドキュメントを直接XML DBリポジトリに格納しようとしたときにも確認されます。

Oracle Database 11gリリース1(11.1)へのアップグレード時

データベースをOracle Database 11gリリース1(11.1)にアップグレードするときに、既存のユーザーXMLType表およびインスタンスの変更は一切行われません。アップグレードの完了後に、新しい記憶域形式を使用して既存の表を変更したり、その後で新しい表を作成することができます。XDBの表XDB$CONFIGおよびXDB$ACLと、対応するXMLスキーマは、データベースをOracle Database 11gリリース1(11.1)にアップグレードするときに、バイナリのXML記憶域に移行されます。

PL/SQLのネイティブ・コンパイルとネットワーク・ユーティリティ・パッケージのアクセス制御

Oracle Database 11gリリース1(11.1)のPL/SQLでは、互換性および相互運用性が変更されました。

- PL/SQLネイティブ・コンパイル

- ネットワーク・ユーティリティ・パッケージのアクセス制御

PL/SQLネイティブ・コンパイル

Oracle Database 11g以上では、PL/SQLネイティブ・コンパイルにCコンパイラは不要です。したがって、現在、PL/SQLネイティブ・コンパイルをサポートする目的のみでCコンパイラを使用している場合は、データベースがインストールされているマシン(およびOracle RAC構成の各ノードから)からCコンパイラを削除できます。

さらに、PL/SQLネイティブ・コンパイルの出力はファイル・システム上で実現されなくなりました。そのため、Oracle Database 10gの初期化パラメータPLSQL_Native_Library_DirおよびPLSQL_Native_Library_Subdir_Countは、Oracle Database 11gでは重要でなくなりました。これらのパラメータが示すディレクトリ、およびディレクトリの内容は、アップグレード処理の完了時に削除しても問題ありません。

また、ORACLE_HOME/plsqlディレクトリにあるSPNC_COMMANDSファイルも不要です。

PL/SQLネイティブ・コンパイルの制御用として、初期化パラメータPLSQL_Code_Typeのみが残されています。したがって、データベース管理者はPL/SQLネイティブ・コンパイルを考慮する必要はありません。

ネットワーク・ユーティリティ・パッケージのアクセス制御

ネットワーク・ユーティリティ・パッケージに対するアクセス制御のデフォルトの動作が変更され、権限を持たないすべてのユーザーに対してネットワーク操作が許可されなくなりました。このデフォルトの動作はこれまでのバージョンのOracle Databaseとは異なる動作であり、互換性がなくなりました。

Oracle Database 11gリリース1(11.1)にアップグレードするデータベース・ユーザーの場合、PL/SQLネットワーク・ユーティリティ・パッケージに依存するアプリケーションは問題なくコンパイルできます。ただし、権限が必要なネットワーク操作を実行しようとすると、実行時にアプリケーションで例外が受信される可能性があります。ネットワーク操作の実行に必要な権限をワイルドカードを使用してPUBLICに付与することで互換性を回復することはできますが、データベース管理者はそれぞれの状況を個別に慎重に調査し、必要な場合にのみ権限を付与することを強くお薦めします。

注意:
Oracle XML DBでは、アクセス制御リストを適切に維持する必要があります。まだシステムにOracle XML DBがインストールされていない場合は、アップグレード作業中にインストールする必要があります。

関連項目:
「Oracle Databaseのアップグレード後の外部ネットワーク・サービスへのファイングレイン・アクセスの構成」

PL/SQLの制御パラメータ

PL/SQLの動作を制御するOracleパラメータの一部は、Oracle Database 11gリリース1(11.1)で動作が変更されました。

- いずれかのパラメータ設定により、PL/SQLのデバッグ・コード生成モードが選択されている場合は、ネイティブ・コードが生成されません。

- PLSQL_OPTIMIZE_LEVEL <= 1の場合は、デバッグ・コードが生成されます。

- PLSQL_DEBUGは非推奨です。
かわりに、PLSQL_OPTIMIZE_LEVELを使用する必要があります。PLSQL_DEBUGを使用すると、非推奨であることを示す警告が発行されます。

- PLSQL_OPTIMIZE_LEVEL <= 1の場合は、ネイティブ・コードが生成されません。

- PLSQL_COMPILER_FLAGSは廃止されました。これは無効になっており、不正なオプションが設定されているという内容のエラー・メッセージが表示されます。

- PLSQL_V2_COMPATIBILITYは非推奨です。

Oracle XML DBにおけるWebDAV ACL評価ルールの変更

Oracle XML DBでは、アクセス制御リスト(ACL)に基づくセキュリティ・メカニズムによって、Oracle XML DBのリソースへのアクセスが制限されます。ACLとは、アクセス制御エントリ(ACE)のリストで、指定されたリソースへのアクセス権を持っているユーザー、ロールおよびグループの特定は、このリストを基に行われます。

WebDAV ACLエントリの処理方法は変更されました。Oracle Database 11gリリース1(11.1)より前のリリースの場合、指定されたACL内で<deny>エントリは常に<allow>エントリより優先されました。Oracle Database 11gリリース1(11.1)以上では、ACEの順番が重要ではなくなりました。デフォルトの動作は、最初に出現した<allow>エントリまたは<deny>エントリによってのみ決定されます。つまり、プリンシパルに対する動作は最初のエントリで決定され、そのプリンシパルに設定された他のACEは効力を持ちません。

デフォルトの動作は、これまでのバージョンのOracle Databaseとは異なる動作に変更され、互換性は失われました。Oracle Database 11gリリース1(11.1)へのアップグレード時に、必要に応じて手動でACLを並べ替えることにより、前のリリースと同様に動作させることができます。つまり、<allow>の後に<deny>が続くACLがある場合は、<deny>エントリが先に検出されるように、ACLを手動で並べ替える必要があります。

関連項目:
ACLの評価ルールの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

サマリー管理とSQLアクセス・アドバイザ

Oracle Database 10gリリース2(10.2)以上では、DBMS_OLAPパッケージ(サマリー管理内のサマリー・アドバイザ)は非推奨とされており、SQLアクセス・アドバイザに置き換えられています。

SQLアクセス・アドバイザのタスク

SQLアクセス・アドバイザ・リポジトリの内部構造が変更されたため、データベースをアップグレードすることにより、既存のSQLアクセス・アドバイザのタスクはすべて初期状態にリセットされます。つまり、アップグレード前に正常に完了していたタスクに対する推奨情報は、すべて削除されます。

アップグレード後に、既存のSQLアクセス・アドバイザのタスクを再実行することにより、推奨情報を回復できます。

Standard Editionの初期データベース

Standard Edition(SE)の初期データベースをアップグレードする場合、次のコンポーネントに必要なオプションがStandard Editionにはインストールされていないため、次のコンポーネントはSEサーバーでアップグレードすることはできません。

- OLAPカタログ

- OLAPアナリティック・ワークスペース

- Oracle OLAP API

アップグレード後、これらのコンポーネントをDBA_REGISTRYビューで参照するとSTATUSの値が'OPTION OFF'と表示され、関連付けられたコンポーネント・スキーマに無効なオブジェクトが含まれます。Database Upgrade Assistant(DBUA)には、これらのコンポーネントのアップグレードが失敗したことが表示されます。

コア・ダンプの位置

UNIXシステムでは、セグメンテーション違反などの処理できないシグナルにより、アプリケーション・プログラムがクラッシュした場合、通常、コア・ダンプ・ファイルが生成されます。このファイルは、coreというデフォルト名で、アプリケーションを現在実行しているディレクトリに配置されます。

Oracle Database 11gリリース1(11.1)以上では、Oracle Call Interface(OCI)を使用するアプリケーションの場合は、core_process_id(process_idはクラッシュしたプロセスのUNIX ID)という名前のサブディレクトリを作成できるようになりました。この場合、coreファイルは、アプリケーションが実行されている場所ではなく、そのサブディレクトリに配置されます。

sqlnet.oraにDIAG_SIGHANDLER_ENABLED = TRUEを設定した場合も、生成されたcoreファイルはcore_process_idという名前のディレクトリに配置されます。

UNDO_MANAGEMENTの新規デフォルト値

Oracle Database 11gリリース1(11.1)以上では、UNDO_MANAGEMENTパラメータのデフォルト値はAUTOであるため、自動UNDO管理はデフォルトで有効になっています。パラメータをMANUALに設定し、必要に応じて自動UNDO管理をオフにする必要があります。

UNDO_MANAGEMENTおよびROLLBACK_SEGMENTS初期化パラメータは、基本初期化パラメータから基本初期化パラメータ以外に変更になりました。データベースを正しく効率的に実行するためにほとんどのデータベースで必要とされているのは、基本パラメータの設定のみです。

関連項目:
『Oracle Databaseリファレンス』の「UNDO_MANAGEMENT」

LOG_ARCHIVE_DEST_nパラメータ

Oracle Database 11gリリース1(11.1)以上では、LOG_ARCHIVE_DEST_nパラメータを使用して、Oracle Standard Editionを実行するデータベース・インスタンス上にローカルのアーカイブ先を指定できます。以前は、このパラメータで指定できるのはOracle Enterprise Editionを実行するデータベース・インスタンス上のみでした。

SHARED_POOL_SIZEパラメータ

このリリース用の移行ユーティリティでは、アップグレード前の環境における内部SGAのオーバーヘッドの値に基づいて、SHARED_POOL_SIZEの新しい値を設定することが推奨されています。その値は、Oracle Database 11gリリース1(11.1)にアップグレードする前に次の問合せを実行することにより求めることができます。

SQL> SELECT SUM(BYTES) FROM v$sgastat WHERE pool = 'shared pool';

Oracle Database 11gリリース1(11.1)では、内部SGAのオーバーヘッド(共有プール内の起動時のオーバーヘッド)の正確な値は、新しいv$sgainfoビューにリストされます。

手動SGAモードのときに、SHARED_POOL_SIZEの値が小さすぎて内部SGAのオーバーヘッドに対応できない場合は、起動中にORA-00371エラーが発生します。このエラーでは、SHARED_POOL_SIZEパラメータの推奨値を含むエラー・メッセージが生成されます。自動共有メモリー管理を使用している場合、共有プールのサイズは自動調整されるため、ORA-00371エラーが発生することはありません。

Oracle Database 10gリリース1(10.1)より前のOracle Databaseリリースで共有プールに割り当てられたメモリー量は、SHARED_POOL_SIZE初期化パラメータの値とインスタンスの起動中に計算された内部SGAのオーバーヘッドを合計した値と等しい量でした。このオーバーヘッドは、他のいくつかの初期化パラメータの値に基づいていました。

たとえば、SHARED_POOL_SIZEパラメータが64MBで内部SGAのオーバーヘッドが12MBの場合、SGA内の共有プールのサイズは実際には76MBになります。ただし、SHARED_POOL_SIZEパラメータの値は引き続き表示されます。

Oracle Database 10gリリース1(10.1)以上では、内部SGAのオーバーヘッドのサイズはSHARED_POOL_SIZEパラメータの値に含まれます。起動時に共有プールに割り当てられるメモリー量は、SHARED_POOL_SIZEパラメータの値と正確に一致します。したがってこのパラメータには、内部SGAのオーバーヘッドと共有プールとして実際に必要なサイズの両方を含んだ値を設定する必要があります。

内部SGAのオーバーヘッドが変更されていないと仮定すると、起動後に実際に共有プールとして使用できる値はSHARED_POOL_SIZEパラメータの値より12MB少ない値、つまり52MBになります。共有プールの実際のメモリー量を64MBに維持するには、このパラメータを76MBに設定します。

JOB_QUEUE_PROCESSESパラメータの新しいデフォルト設定

Oracle Database 11gリリース1(11.1)以上では、JOB_QUEUE_PROCESSES初期化パラメータは基本パラメータから基本パラメータ以外に変更になりました。正常かつ効率的に稼働するために、多くのデータベースで基本的なパラメータのみが設定されている必要があります。デフォルト値も、0から1000に変更されます。

Oracle Databaseによって、ジョブ・キューの設定が上書きされ、アップグレード・モード中にスケジューラ・ジョブが無効化されます。したがって、Oracle Databaseのアップグレード時にこの設定を変更する必要はありません。

関連項目:
このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

自動診断リポジトリ

アラート・ログおよびトレース・ファイルの場所は、初期化パラメータBACKGROUND_DUMP_DESTおよびUSER_DUMP_DESTによっては設定されなくなりました。これらは自動診断リポジトリ(ADR)に保持されるようになり、自動診断リポジトリの場所は初期化パラメータDIAGNOSTIC_DESTによって設定されます。

関連項目:
診断情報の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Database 10gリリース2(10.2)で発生する互換性および相互運用性の問題

次の項では、Oracle Database 10gリリース2(10.2)で発生する互換性および相互運用性の問題について説明します。Oracle Database 10gリリース2(10.2)より前のリリースからOracle Database 11gリリース1(11.1)にアップグレードする場合は、これらの問題によって発生する問題を回避するための対処方法について、次の各項で詳細を参照してください。

- Oracle Database 10gリリース2(10.2)で非推奨の初期化パラメータ

- Oracle Database 10gリリース2(10.2)で廃止された初期化パラメータ

- Oracle Database 10gリリース2(10.2)で列が削除された静的データ・ディクショナリ・ビュー

- SQL

- CONNECTロール

- タイムゾーン・ファイル

- FAILED_LOGIN_ATTEMPTSに対する新しい制限

Oracle Database 10gリリース2(10.2)で非推奨の初期化パラメータ

次の初期化パラメータはOracle Database 10gリリース2(10.2)で非推奨となりました。すべての非推奨の初期化パラメータのリストを表示するには、次のSQL文を発行します。

SQL> SELECT name FROM v$parameter
WHERE isdeprecated = 'TRUE';

非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。

LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
REMOTE_ARCHIVE_ENABLE
SERIAL_REUSE
SQL_TRACE

Oracle Database 10gリリース2(10.2)で廃止された初期化パラメータ

次の初期化パラメータはOracle Database 10gリリース2(10.2)で廃止されました。

注意:
廃止された初期化パラメータを1つ以上使用しているデータベースについては、起動はできますが、警告が戻され、アラート・ログに記録されます。

ENQUEUE_RESOURCES

Oracle Database 10gリリース2(10.2)で列が削除された静的データ・ディクショナリ・ビュー

Oracle Database 10gリリース2(10.2)では、次の静的データ・ディクショナリ・ビューの列が削除されました。

静的データ・ディクショナリ・ビュー

削除された列

DBA_HIST_SQLBIND

CHILD_NUMBER

SQL

XMLファンクションで使用した場合の日付のフォーマットの動作が変更されています。XMLデータの日付とタイムスタンプは標準フォーマットで表記するようにXMLスキーマ標準で規定されています。Oracle Database 10gリリース2(10.2)より前のリリースでは、XMLデータ内の日付およびタイムスタンプはこの標準に準拠しておらず、生成されるXML内の日付およびタイムスタンプのフォーマットはデータベースのフォーマットによって決定されていました。

Oracle Database 10gリリース2(10.2)では、Oracle XML DBのXML生成ファンクションにより、XMLスキーマ標準に従って日付およびタイムスタンプが生成されます。

関連項目:
詳細は、『Oracle XML DB開発者ガイド』を参照してください。

CONNECTロール

Oracle Database 10gリリース2(10.2)より前のリリースからアップグレードした後は、CONNECTロールに含まれる権限はCREATE SESSIONのみになり、前のリリースでCONNECTロールに付与されていた他の権限は、アップグレード時に取り消されます。これについての詳細は、「以前のリリースからのCONNECTロールの更新」を参照してください。

タイムゾーン・ファイル

Oracle Database 10gリリース2(10.2)に付属のタイムゾーン・ファイルはバージョン4からバージョン8に更新され、一部のタイムゾーン地域の変換ルールに対して行われた変更が反映されています。これらの変更は、TIMESTAMP WITH TIME ZONEデータ型の既存のデータに影響する場合があります。これについての詳細は、「TIMESTAMP WITH TIME ZONEデータ型に関する警告の概要」を参照してください。

FAILED_LOGIN_ATTEMPTSに対する新しい制限

Oracle Database 10gリリース2(10.2)では、DEFAULTプロファイルに対するFAILED_LOGIN_ATTEMPTSの制限は10です。Oracle Database 10gリリース2(10.2)より前のリリースでは、デフォルトはUNLIMITEDでした。

Oracle Database 10gリリース1(10.1)で発生する互換性および相互運用性の問題

次の項では、Oracle Database 10gリリース1(10.1)で発生する互換性および相互運用性の問題について説明します。Oracle Database 10gリリース1(10.1)より前のリリースからOracle Database 11gリリース1(11.1)にアップグレードする場合は、これらの問題によって発生する問題を回避するための対処方法について、次の各項で詳細を参照してください。

- Oracle Database 10gリリース1(10.1)で非推奨の初期化パラメータ

- Oracle Database 10gリリース1(10.1)で廃止された初期化パラメータ

- Oracle Database 10gリリース1(10.1)で非推奨の静的データ・ディクショナリ・ビュー

- Oracle Database 10gリリース1(10.1)で廃止された静的データ・ディクショナリ・ビュー

- Oracle Database 10gリリース1(10.1)で非推奨の動的パフォーマンス・ビュー

- Oracle Database 10gリリース1(10.1)で廃止された動的パフォーマンス・ビュー

- SQLオプティマイザ

- SQLの変更

- アップグレード後の無効なシノニム

- 管理性

- トランザクションおよび領域

- リカバリおよびData Guard

- RMAN

- CREATE DATABASE

- Real Application Clusters

- マテリアライズド・ビュー

- チェンジ・データ・キャプチャ

- リモートのアーカイブ先に対するデフォルトのアーカイブ処理の変更

- NCHARデータ型の制限事項

- PL/SQLネイティブ・コンパイル

- 数値リテラルの評価

- SESSION_CACHED_CURSORSの動作変更

- DB_BLOCK_SIZEの新規デフォルト値

- OPTIMIZER_MAX_PERMUTATIONSおよびOPTIMIZER_FEATURES_ENABLE

- LOG_ARCHIVE_FORMATの動作変更

- PGA_AGGREGATE_TARGETの新規デフォルト値

- SHARED_POOL_SIZEの動作変更

- 共有サーバーのパラメータ

Oracle Database 10gリリース1(10.1)で非推奨の初期化パラメータ

次の初期化パラメータはOracle Database 10gリリース1(10.1)で非推奨となりました。すべての非推奨の初期化パラメータのリストを表示するには、次のSQL文を発行します。

SQL> SELECT name FROM v$parameter
WHERE isdeprecated = 'TRUE';

非推奨のパラメータは通常のパラメータと同様に動作しますが、非推奨のパラメータをパラメータ・ファイルに指定した場合、インスタンスの起動時に警告メッセージが表示されます。また、非推奨のすべてのパラメータは、インスタンスの起動時にアラート・ログに記録されます。

BUFFER_POOL_KEEP(DB_KEEP_CACHE_SIZEに変更)
BUFFER_POOL_RECYCLE(DB_RECYCLE_CACHE_SIZEに変更)
GLOBAL_CONTEXT_POOL_SIZE
LOCK_NAME_SPACE
LOG_ARCHIVE_START
MAX_ENABLED_ROLES
PARALLEL_AUTOMATIC_TUNING
PLSQL_COMPILER_FLAGS(PLSQL_CODE_TYPEおよびPLSQL_DEBUGに変更)
SQL_VERSION

Oracle Database 10gリリース1(10.1)で廃止された初期化パラメータ

次の初期化パラメータはOracle Database 10gリリース1(10.1)で廃止されました。

注意:
廃止された初期化パラメータを1つ以上使用しているデータベースについては、起動はできますが、警告が戻され、アラート・ログに記録されます。

DBLINK_ENCRYPT_LOGIN
HASH_JOIN_ENABLED
LOG_PARALLELISM
MAX_ROLLBACK_SEGMENTS
MTS_CIRCUITS
MTS_DISPATCHERS
MTS_LISTENER_ADDRESS
MTS_MAX_DISPATCHERS
MTS_MAX_SERVERS
MTS_MULTIPLE_LISTENERS
MTS_SERVERS
MTS_SERVICE
MTS_SESSIONS
OPTIMIZER_MAX_PERMUTATIONS
ORACLE_TRACE_COLLECTION_NAME
ORACLE_TRACE_COLLECTION_PATH
ORACLE_TRACE_COLLECTION_SIZE
ORACLE_TRACE_ENABLE
ORACLE_TRACE_FACILITY_NAME
ORACLE_TRACE_FACILITY_PATH
PARTITION_VIEW_ENABLED
PLSQL_NATIVE_C_COMPILER
PLSQL_NATIVE_LINKER
PLSQL_NATIVE_MAKE_FILE_NAME
PLSQL_NATIVE_MAKE_UTILITY
ROW_LOCKING
SERIALIZABLE
TRANSACTION_AUDITING
UNDO_SUPPRESS_ERRORS

Oracle Database 10gリリース1(10.1)で非推奨の静的データ・ディクショナリ・ビュー

次の静的データ・ディクショナリ・ビューはOracle Database 10gリリース1(10.1)で非推奨となりました。

ALL_STORED_SETTINGS(ALL_PLSQL_OBJECT_SETTINGSに変更)
DBA_STORED_SETTINGS(DBA_PLSQL_OBJECT_SETTINGSに変更)
USER_STORED_SETTINGS(USER_PLSQL_OBJECT_SETTINGSに変更)

Oracle Database 10gリリース1(10.1)で廃止された静的データ・ディクショナリ・ビュー

次の静的データ・ディクショナリ・ビューはOracle Database 10gリリース1(10.1)で廃止されました。

ALLビュー

DBAビュー

USERビュー

ALL_SOURCE_TAB_COLUMNS

DBA_SOURCE_TAB_COLUMNS

USER_SOURCE_TAB_COLUMNS

Oracle Database 10gリリース1(10.1)で非推奨の動的パフォーマンス・ビュー

次の動的パフォーマンス・ビューはOracle Database 10gリリース1(10.1)で非推奨となりました。

GV$CACHE
GV$CACHE_TRANSFER
GV$CLASS_CACHE_TRANSFER(GV$INSTANCE_CACHE_TRANSFERに変更)
GV$FALSE_PING
GV$FILE_CACHE_TRANSFER(GV$INSTANCE_CACHE_TRANSFERに変更)
GV$GC_ELEMENTS_WITH_COLLISIONS
GV$LOCK_ACTIVITY
GV$TEMP_CACHE_TRANSFER(GV$INSTANCE_CACHE_TRANSFERに変更)
V$CACHE
V$CACHE_LOCK
V$CACHE_TRANSFER
V$CLASS_CACHE_TRANSFER(V$INSTANCE_CACHE_TRANSFERに変更)
V$FALSE_PING
V$FILE_CACHE_TRANSFER(V$INSTANCE_CACHE_TRANSFERに変更)
V$GC_ELEMENTS_WITH_COLLISIONS
V$LOCK_ACTIVITY
V$TEMP_CACHE_TRANSFER(V$INSTANCE_CACHE_TRANSFERに変更)

Oracle Database 10gリリース1(10.1)で廃止された動的パフォーマンス・ビュー

次の動的パフォーマンス・ビューはOracle Database 10gリリース1(10.1)で廃止されました。

GV$ビュー

V$ビュー

GV$COMPATIBILITY

V$COMPATIBILITY

GV$COMPATSEG

V$COMPATSEG

GV$MLS_PARAMETERS

V$MLS_PARAMETERS

GV$MTS

V$MTS

SQLオプティマイザ

この項では、Oracle Database 10gリリース1(10.1)のSQLオプティマイザに関連する互換性の問題および相互運用性の問題について説明します。

サポートされないルールベース・オプティマイザ

Oracle Database 10gリリース1(10.1)以上では、コストベース・オプティマイザ(CBO)がデフォルトで有効になっています。ルールベース・オプティマイザは、Oracle Database 10gリリース1(10.1)ではサポートされなくなりました。その結果、ruleおよびchooseはOPTIMIZER_MODE初期化パラメータの値としてサポートされなくなったため、OPTIMIZER_MODEにこれらのいずれかの値を設定すると、アラート・ログに警告が表示されます。

関連項目:
コストベース・オプティマイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

オプティマイザ統計

現在、オプティマイザ統計の収集は、すべてのスキーマ(SYSを含む)、Oracle Database 10gリリース1(10.1)より前のリリースからアップグレードした既存のデータベース、および新規作成したデータベースに対してデフォルトで自動的に実行されます。無効なオブジェクトのオプティマイザ統計の収集は、メンテナンス期間中、毎日実行されるようにデフォルトでスケジュールされます。

関連項目:
オプティマイザ統計の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

CREATE INDEXのCOMPUTE STATISTICS句

以前のリリースでは、CREATE INDEXのCOMPUTE STATISTICS句を使用して、索引での統計の収集を開始および停止できました。この句は非推奨となっています。Oracle Database 10gリリース1(10.1)以上のリリースでは、索引の作成中および再構築中に統計が自動的に収集されます。この句は、下位互換性のためにサポートされているもので、エラーは発生しません。

SKIP_UNUSABLE_INDEXES

以前のリリースでは、SKIP_UNUSABLE_INDEXESはセッション・パラメータのみでした。Oracle Database 10gリリース1(10.1)以上のリリースでは、このパラメータは初期化パラメータであり、デフォルトはtrueです。trueに設定すると、索引のエラー・レポートおよびUNUSABLEにマークされた索引パーティションが使用不可になります。この設定を使用すると、使用できない索引または索引パーティションを使用する表で、すべての操作(挿入、削除、更新および選択)を実行できます。

関連項目:
『Oracle Databaseリファレンス』の「SKIP_UNUSABLE_INDEXES」

SQLの変更

Oracle Database 10gリリース1(10.1)以上では、SQLおよびPL/SQLでのCLOBとNCLOBの暗黙的な変換が可能です。

Oracle Database 10gリリース1(10.1)以上では、シノニムの名前解決が変更されています。現在、シノニムのベース・オブジェクトが存在しない場合、SQLコンパイラはPUBLIC.base_objectの検索を試行します。

Oracle Database 10gリリース1(10.1)以上では、VPDポリシーがベース・オブジェクトにではなくシノニムに付加されます。

アップグレード後の無効なシノニム

Oracle Database 10gリリース1(10.1)以上では、シノニム(パブリックまたはプライベート)が存在しない場合または無効なオブジェクトを指している場合、アップグレード後にそのシノニムは無効になります。

管理性

現在、データベースのパフォーマンス統計は、Oracle Database 10gリリース1(10.1)より前のリリースからアップグレードされたデータベースおよび新規に作成されたデータベースの自動ワークロード・リポジトリ(AWR)のデータベース・コンポーネントによって自動的に収集されます。このデータは、SYSAUX表領域に格納され、推奨パフォーマンスを自動生成するために、データベースによって使用されます。

関連項目:
『Oracle Databaseパフォーマンス・チューニング・ガイド』

パフォーマンス・データの収集にStatspackを使用している場合は、AWRとの競合を回避するために、StatspackのREADME(ORACLE_HOME/rdbms/adminディレクトリにあるspdoc.txt)で、Oracle Database 10gリリース1(10.1)以上のリリースでのStatspackの使用についての説明を参照してください。

トランザクションおよび領域

Oracle Database 10gリリース1(10.1)以上では、削除されたオブジェクトはごみ箱に移動され、このごみ箱の領域は必要なときにのみ再利用されます。これによって、オブジェクトは、FLASHBACK DROP機能を使用して削除を取り消すことができます。

関連項目:
『Oracle Database管理者ガイド』

Oracle Database 10gリリース1(10.1)以上では、UNDO保存の自動チューニングはデフォルトで有効になっています。UNDO_SUPPRESS_ERRORS初期化パラメータは、非推奨になりました。自動UNDO管理モードのときにロールバック・セグメント操作を実行した場合に生成されるエラーは、常に、表示されません。

Oracle Database 10gリリース1(10.1)以上では、Oracle Managed Files(OMF)のデフォルトのAUTOEXTEND NEXTサイズが大きくなります。

関連項目:
『Oracle Database SQL言語リファレンス』

リカバリおよびData Guard

Oracle Database 10gリリース1(10.1)以上では、LOG_ARCHIVE_START初期化パラメータが非推奨となりました。アーカイブは、データベースをARCHIVELOGモードにすると、自動的に開始されます。

Oracle Database 10gリリース1(10.1)以上では、LOG_PARALLELISM初期化パラメータが非推奨となりました。ログ・ファイルの並列処理は、自動的に有効になります。

Oracle Database 10gリリース1(10.1)以上では、RECOVERY_PARALLELISM初期化パラメータのデフォルト値は、パラレル・リカバリの許可に設定されます。

Oracle Database 10gリリース1(10.1)以上では、ALTER DATABASE RECOVER DATABASE文のパラレル句のデフォルト値が、PARALLELに変更されています。

関連項目:
『Oracle Database SQL言語リファレンス』

Oracle Database 10gリリース1(10.1)以上では、LOG_ARCHIVE_DEST_n初期化パラメータのASYNC属性のデフォルト・バッファ・サイズが、2,048ブロックから61,440ブロックに増加されています。

Oracle Database 10gリリース1(10.1)以上では、DBMS_LOGSTDBY.APPLY_SET()プロシージャで設定されるパラメータMAX_SGAおよびMAX_SERVERSのデフォルト値が変更されています。

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

Oracle Database 10gリリース1(10.1)以上では、Data Guard BrokerのプロパティApplyParallel、AsyncBlocksおよびLogXptModeのデフォルト値が変更されています。

関連項目:
『Oracle Data Guard Broker』

Oracle Database 10gリリース1(10.1)以上では、フィジカル・スタンバイ・データベースでのSQL*PlusコマンドSTARTUP、SQL文ALTER DATABASE MOUNTおよびALTER DATABASE OPENのデフォルトの動作が変更されています。コマンドによってデータベースがフィジカル・スタンバイであることが自動的に検出されるため、STANDBY DATABASEおよびREAD ONLYオプションがデフォルトに設定されます。

関連項目:
『Oracle Database SQL言語リファレンス』

RMAN

Oracle Database 10gリリース1(10.1)以上では、バックアップからファイルをリストアするときにファイルのバックアップが存在しない場合は、RMANによって空のファイルが作成されます。アーカイブ・ログのRMANのバックアップは、最後のresetlogsの前に作成されたログを自動的にバックアップします。以前は、このようなログは無視されました。

Oracle Database 10gリリース1(10.1)以上では、RMANでエラーが発生した場合、バックアップまたはリストア・ジョブの残りの部分は継続して実行されます。対象となるバックアップの破損を検出すると、RMANは代替バックアップからのリストアを試行します。

CREATE DATABASE

Oracle Database 10gリリース1(10.1)以上のリリースでは、データベースの作成時またはデータベースのアップグレード時に、常にSYSAUX表領域が作成されます。SYSAUX表領域は、SYSTEM表領域の予備の表領域として機能します。SYSAUXは、Oracleの多くの機能および製品(以前は機能や製品ごとに表領域を必要としていた)のデフォルトの表領域であるため、DBAによる管理が必要な表領域の数が減少します。

関連項目:
SYSAUX表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Database 10gリリース1(10.1)以上では、ログ・ファイルの最小サイズおよびデフォルトのサイズが増やされています。最小サイズは4MBです。デフォルトのサイズは50MBですが、Oracle Managed Files(OMF)を使用している場合、デフォルトのサイズは100MBになります。

Real Application Clusters

Oracle Database 10gリリース1(10.1)では、Oracle Real Application Clustersに対して、自動化された高可用性(HA)フレームワークが提供されます。このフレームワークでは、検出、リカバリ、再起動および通知サービスが行われます。

関連項目:
詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

マテリアライズド・ビュー

Oracle Database 10gリリース1(10.1)以上では、一部の権限の名前が変更されています。新しい名前は、すべてのデータ・ディクショナリ・ビューに表示されます。ただし、GRANTおよびREVOKE SQL文では、以前の名前と新しい名前の両方が使用できます。

- CREATE SNAPSHOTは、CREATE MATERIALIZED VIEWに変更されました

- CREATE ANY SNAPSHOTは、CREATE ANY MATERIALIZED VIEWに変更されました

- ALTER ANY SNAPSHOTは、ALTER ANY MATERIALIZED VIEWに変更されました

- DROP ANY SNAPSHOTは、DROP ANY MATERIALIZED VIEWに変更されました

チェンジ・データ・キャプチャ

Oracle Database 10gリリース1(10.1)以上では、DBMS_CDC_SUBSCRIBEおよびDBMS_CDC_PUBLISHのインタフェースで使用されるのは、サブスクリプション・ハンドルではなくサブスクリプション名パラメータです。

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

Oracle Database 10gリリース1(10.1)以上では、サブスクライバ・ビューは自動的に管理されます。PREPARE_SUBSCRIBER_VIEW()およびDROP_SUBSCRIBER_VIEW()をインタフェースとするDBMS_CDC_SUBSCRIBEおよびDBMS_CDC_PUBLISHをコールする必要がなくなりました。

Oracle Database 10gリリース1(10.1)以上では、同期チェンジ・データ・キャプチャのRSID$列の計算が変更され、サブスクライバ・ビュー同士を結合して古い値と新しい値の両方を同じ行に表示することが容易になりました。同じ更新操作に関連するUO行およびUN行のRSID$の値は、等しくなります。Oracle9iの動作(同じ更新操作では、UN RSID$値はUO RSID$値に1を加えた値に等しい)に戻すには、イベント10983をレベル4に設定します。

リモートのアーカイブ先に対するデフォルトのアーカイブ処理の変更

Oracle Database 10gリリース1(10.1)以上では、リモートの宛先に対するデフォルトのアーカイブ処理が変更されており、この変更によって、プライマリ・データベースのアーカイブ処理では、リモートのスタンバイ宛先にREDOデータが転送される前に、ローカルのオンラインREDOログ・ファイルがすべて正常にアーカイブされます。このデフォルトの動作は、LOG_ARCHIVE_LOCAL_FIRST初期化パラメータをtrueに設定した場合と同じであり、Oracle Database 10gリリース1(10.1)以上のリリースでの新機能でもあります。この新しいデフォルトのアーカイブ処理は、ログ転送サービスがログ・ライター・プロセス(LGWR)ではなくアーカイバ・プロセス(ARCn)を使用するように定義され、アーカイバ・プロセスがリモートの宛先に書込みを実行していて、リモートのスタンバイ宛先が必須の宛先ではない場合にのみ、有効になることに注意してください。

Oracle Database 10gリリース1(10.1)より前のリリースでは、オンラインREDOログ・ファイルがローカルのオンラインREDOログ・ファイルにアーカイブされると同時に、REDOデータをスタンバイ宛先に転送するのがデフォルトの動作でした。LOG_ARCHIVE_LOCAL_FIRST初期化パラメータをfalseに設定すると、このように動作します。また、このアーカイブ処理は、ログ転送サービスがログ・ライター・プロセス(LGWR)ではなくアーカイバ・プロセス(ARCn)を使用するように定義され、アーカイバ・プロセスがリモートの宛先に書込みを実行していて、リモートのスタンバイ宛先が必須の宛先ではない場合にのみ、有効になります。

新しいデフォルトの動作の利点は、ローカルのアーカイブ、つまりプライマリ・データベースでの処理は、必須ではないリモートの宛先へのアーカイブに影響されない点です。ローカルのアーカイブとリモートのアーカイブは連動しなくなったため、プライマリ・データベースのアーカイブ済REDOログ・ファイルをバックアップ直後に削除するポリシーを設定しているサイトでは、プライマリ・データベースのアーカイブ済REDOログ・ファイルを削除する前に、スタンバイの宛先が対応するREDOデータを受信していることを確認する必要があります。V$ARCHIVED_LOGビューを問い合せて、スタンバイの宛先でREDOデータが受信されていることを確認できます。

注意:
LOG_ARCHIVE_LOCAL_FIRST初期化パラメータで指定するすべての値は、必須の宛先(LOG_ARCHIVE_DEST_n初期化パラメータのMANDATORY属性が設定されている宛先)では無視されます。

関連項目:
リモートの宛先へのアーカイブの設定の詳細は、『Oracle Data Guard概要および管理』を参照してください。

NCHARデータ型の制限事項

Oracle9i以上では、NCHARデータ型(NCHAR、NVARCHAR2、NCLOBなど)は、Unicodeキャラクタ・セット・コード(UTF8およびAL16UTF16)に制限されています。

PL/SQLネイティブ・コンパイル

Oracle Database 10gリリース1(10.1)以上では、ネイティブ・コンパイルの初期化パラメータの構成およびコマンド設定が簡単になっています。現在の重要なパラメータは、PLSQL_NATIVE_LIBRARY_DIRとPLSQL_NATIVE_LIBRARY_SUBDIR_COUNTです。コンパイラ、リンカーおよびmakeユーティリティに関連するパラメータは廃止されています。ネイティブ・コンパイルは、PLSQL_COMPILER_FLAGSパラメータ(現在は非推奨)のいずれかのオプションではなく、個別の初期化パラメータPLSQL_CODE_TYPEで有効または無効にします。ORACLE_HOME/plsqlディレクトリにあるspnc_commandsファイルには、makeファイルではなく、コンパイルおよびリンク用のコマンドおよびオプションが含まれています。

関連項目:

- ネイティブ実行のためのPL/SQLコードのコンパイルの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

- 次のURLで、Oracle Technology Network(OTN)の「PL/SQL Native Compilation (NCOMP) In Oracle Database 10g Rel 1」を参照してください。

http://www.oracle.com/technetwork/database/features/plsql/index.html

数値リテラルの評価

数値リテラルの評価方法が変更され、リテラルを使用する数値計算の場合は、定数の1つ以上で小数第1位に小数点を指定することが必要になりました。これは、Oracle Database 10gリリース1(10.1)以上のリリースでは一部の式でINTEGER演算(有効桁は約9桁)が使用されますが、Oracle9iリリース2(9.2)ではNUMBER演算(有効桁数は約38桁)が使用されるためです。

したがって、有効桁数が9桁を超える計算結果を扱う場合、数値オーバーフローのエラーを回避するには、リテラルのうち1つが小数形式であることが必要です。たとえば、Oracle Database 10gリリース1(10.1)では、次に示す例のv1の計算で数値オーバーフローのエラーが発生します。

DECLARE
v1 NUMBER(38);
BEGIN
v1 := 256*256*256*256;
DBMS_OUTPUT.PUT_LINE(v1);
END;
/

エラーが発生しないようにするには、数値リテラルの1つを次のように小数(256.0)として指定します。

DECLARE
v1 NUMBER(38);
BEGIN
v1 := 256*256*256*256.0;
DBMS_OUTPUT.PUT_LINE(v1);
END;
/

関連項目:

- SQL*Plusの新機能の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』のSQL*Plusの新機能に関する項を参照してください。

- SQLスクリプトのアップグレードの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

SESSION_CACHED_CURSORSの動作変更

Oracle Database 10gリリース1(10.1)以上では、キャッシュされるカーソルの数はSESSION_CACHED_CURSORS初期化パラメータによって決定されます。以前のリリースのOracle Databaseでは、PL/SQLでキャッシュされるSQLカーソルの数はOPEN_CURSORS初期化パラメータによって決定されました。

関連項目:
『Oracle Databaseリファレンス』の「SESSION_CACHED_CURSORS」

DB_BLOCK_SIZEの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、DB_BLOCK_SIZEのデフォルト値はオペレーティング・システム固有であり、通常は8KB(8192バイト)です。以前のリリースのOracle Databaseでは、デフォルト値は2KB(2048バイト)でした。Oracle9iリリース2(9.2)からアップグレードする際にDB_BLOCK_SIZEがパラメータ・ファイルで指定されていない場合、データベースを起動しようとするとエラーが表示されます。次の行をパラメータ・ファイルに追加します。

DB_BLOCK_SIZE = 2048

DB_BLOCK_SIZEがパラメータ・ファイルで指定されている場合、Oracle Databaseはデフォルト値(8KB)ではなく指定された値を使用します。

OPTIMIZER_MAX_PERMUTATIONSおよびOPTIMIZER_FEATURES_ENABLE

Oracle Database 10g以上では、OPTIMIZER_MAX_PERMUTATIONS初期化パラメータは廃止されました。Oracle9iからアップグレードして、パラメータ・ファイルでOPTIMIZER_FEATURES_ENABLEを8.1.7以下に設定し、OPTIMIZER_MAX_PERMUTATIONSを明示的に2000に設定すると、Oracle Database 11gリリース1(11.1)のデータベースの起動時にリリース8.1.7のデフォルトの80000が使用されます。

OPTIMIZER_FEATURES_ENABLEを9.0.0以上に設定すると、デフォルトが2000に設定されます。

LOG_ARCHIVE_FORMATの動作変更

Oracle Database 10gリリース1(10.1)以上では、COMPATIBLE初期化パラメータを10.0.0以上に設定する場合、すべてのアーカイブ・ログのファイル名が一意となるように、アーカイブ・ログのファイル名に要素%s(順序)、%t(スレッド)および%r(リセットログID)を含める必要があります。LOG_ARCHIVE_FORMAT初期化パラメータをパラメータ・ファイルに設定する場合は、パラメータ値に%s、%tおよび%r要素が含まれていることを確認します。

PGA_AGGREGATE_TARGETの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、自動PGAメモリー管理がデフォルトで使用可能です(PGA_AGGREGATE_TARGETに0、またはWORKAREA_SIZE_POLICYにMANUALが明示的に設定されていない場合)。PGA_AGGREGATE_TARGETのデフォルトは、明示的に指定されていない場合はSGAのサイズの20%です。アップグレード後にPGA_AGGREGATE_TARGETの値をチューニングすることをお薦めします。

関連項目:
『Oracle Databaseパフォーマンス・チューニング・ガイド』

SHARED_POOL_SIZEの動作変更

以前のリリースでは、割り当てられた共有プールのメモリーの量は、SHARED_POOL_SIZE初期化パラメータの値とインスタンスの起動中に計算された内部SGAのオーバーヘッドの量の合計でした。Oracle Database 10gリリース1(10.1)以上では、SHARED_POOL_SIZEの値はこの共有プールのオーバーヘッドに対応する必要もあります。

Oracle Databaseリリース9.2以上では、共有プールは複数にパーティション化できます。パーティションは共有プールのサブプールと呼ばれ、最高7つのサブプールに分割できます。標準の推奨事項はありませんが、デフォルト・サイズより大きいサブプールを生成する方法で共有プール・メモリーを構成する必要があります。たとえば、256Mと500Mは、それぞれOracle Databaseリリース9iと10gのサブプール・サイズとしてより適切に機能する可能性があります。十分なサイズを共有プールのサブプールに割り当てると、ORA-4031エラーを回避できます。

共有サーバーのパラメータ

Oracle Database 10gリリース1(10.1)以上で共有サーバー・モードをオンにする場合は、SHARED_SERVERSを0より大きい値に設定することをお薦めします。これは、起動時またはインスタンスの起動後に動的に設定できます。SHARED_SERVERSを0に設定して共有サーバー・モードをオフにした場合、これは新しいクライアントのみに影響します(つまり、新しいクライアントは共有モードでは接続できず、すでに共有モードで接続しているクライアントは共有サーバーによるサービスを受けることができます)。

以前のリリースでは、共有サーバー・モードをオンにするにはDISPATCHERSを設定する方法をお薦めしていました。SHARED_SERVERSが0に変更された後も共有サーバー・クライアントが接続していた場合は、クライアントの要求はハングアップしました。

Oracle Database 10gリリース1(10.1)より前のリリースでは、次の共有サーバーのパラメータを動的に変更することはできませんでした。

- MAX_SHARED_SERVERS

- MAX_DISPATCHERS

- SHARED_SERVER_SESSIONS

- CIRCUITS

Oracle Database 10gリリース1(10.1)以上では、これらの共有サーバーのパラメータを動的に変更できます。

DISPATCHERSの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、DISPATCHERSのデフォルトは'(PROTOCOL=TCP)'です。値が設定されていない場合、または''が設定され、SHARED_SERVERSが1以上に設定されている場合、DISPATCHERSにこのデフォルト値が設定されます。

以前のリリースでは、DISPATCHERSのデフォルト値はありませんでした。

SHARED_SERVERSの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、ディスパッチャの合計数が0になるようにDISPATCHERSを設定する場合、SHARED_SERVERSのデフォルトは0です。ディスパッチャの合計数が0よりも多くなるようにDISPATCHERSを設定する場合、SHARED_SERVERSのデフォルトは、以前のリリースと同様に1です。

以前のリリースでは、ディスパッチャの数が0になるようにDISPATCHERSを設定する場合、SHARED_SERVERSのデフォルトは1でした。

MAX_SHARED_SERVERSの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、MAX_SHARED_SERVERSに対して事前に設定されたデフォルトはありません。共有サーバーの合計数は、空きプロセス・スロットの数によって異なります。MAX_SHARED_SERVERSが設定されていない場合、またはPROCESSES以上の値が設定されている場合、空きプロセス・スロットの数が2(PROCESSESが24未満の場合)または1 / 8未満のときは、既存のサーバーがデッドロック状態でないかぎり、PMONは共有サーバーを起動しません。既存のサーバーがデッドロック状態の場合、トランザクションの負荷にかかわらず、空きプロセス・スロットがないときは新しいサーバーが起動されます。

以前のリリースでは、MAX_SHARED_SERVERSがPROCESSESを超えない場合、MAX_SHARED_SERVERSのデフォルトは20またはSHARED_SERVERSの2倍(どちらか大きい方)でした。

Oracle Database 10gリリース1(10.1)以上では、サーバーの数が常にSHARED_SERVERSに設定されたレベルである場合、SHARED_SERVERSをMAX_SHARED_SERVERSより大きく設定できます。これによって、特定の順序でこれらのパラメータを変更する必要なく、SHARED_SERVERSからMAX_SHARED_SERVERSの範囲を変更できます。

以前のリリースでは、SHARED_SERVERSをMAX_SHARED_SERVERSよりも大きく設定できませんでした。

SHARED_SERVER_SESSIONSの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、SHARED_SERVER_SESSIONSに対して事前に設定されたデフォルトはありません。したがって、SHARED_SERVER_SESSIONSを指定しない場合は、セッションの制限で許可されている範囲で、必要に応じて、共有サーバー・セッションを作成できます。

以前のリリースでは、SHARED_SERVER_SESSIONSのデフォルトは、バーチャル・サーキットの最大数(CIRCUITS)またはデータベース・セッションの最大数(SESSIONS)から5を引いた数(いずれか小さい方)でした。

CIRCUITSの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、CIRCUITSに対して事前に設定されたデフォルトはありません。したがって、CIRCUITSを指定しない場合は、ディスパッチャの制約およびシステム・リソースで許可されている範囲で、必要に応じて、サーキットを作成できます。

以前のリリースでは、CIRCUITSのデフォルトは、共有サーバー・モードが有効な場合はデータベース・セッションの最大数(SESSIONS)、その他の場合は0でした。

MAX_DISPATCHERSの新規デフォルト値

Oracle Database 10gリリース1(10.1)以上では、MAX_DISPATCHERSに対して事前に設定されたデフォルトはありません。MAX_DISPATCHERSはディスパッチャの数を制限しなくなったので、空きプロセス・スロットおよびシステム・リソースがあるかぎりは、ユーザーはDISPATCHERSパラメータでディスパッチャの数を増加できます。

以前のリリースでは、MAX_DISPATCHERSのデフォルトは、5またはDISPATCHERSパラメータで指定したディスパッチャの合計数(いずれか大きい方)でした。

B Oracle Databaseをアップグレードする場合のオプティマイザ統計の収集

Oracleでは、Oracle Databaseのディクショナリ・オブジェクトのオプティマイザ統計を収集するためのスクリプトを提供しています。データベースのアップグレード前にこれらのスクリプトを実行しておくと、アップグレード時の停止時間を短縮できます。

この処理は、アップグレードの他の処理と同様にテスト・データベースでテストする必要があります。また、データベース・コンポーネントの一部がインストールされていない場合は、これらのスクリプトで参照されるスキーマが存在しない場合があります。

この付録には、次の項目が含まれます。

- システム・コンポーネント・スキーマに対する統計の収集

- 統計表の作成

システム・コンポーネント・スキーマに対する統計の収集

Oracle9iリリース2(9.2)を使用している場合は、DBMS_STATS.GATHER_SCHEMA_STATSプロシージャを使用して統計を収集する必要があります。次のサンプル・スクリプトでは、このプロシージャを使用してシステム・コンポーネント・スキーマに対する統計を収集します。

このスクリプトを実行するには、SQL*Plusを使用して、AS SYSDBAでデータベースに接続する必要があります。

spool gdict

grant analyze any to sys;

exec dbms_stats.gather_schema_stats('WMSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('MDSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('CTXSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('XDB',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('WKSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('LBACSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('ORDSYS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('ORDPLUGINS',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('SI_INFORMTN_SCHEMA',-
options=>'GATHER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('OUTLN',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('DBSNMP',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

exec dbms_stats.gather_schema_stats('SYSTEM',options=>'GATHER', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

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);

spool off

注意:
特定のコンポーネント・スキーマがデータベースに存在しない場合、統計の収集は失敗する場合があります。これは、コンポーネントがインストールされていない場合、または無効である場合に発生します。

統計表の作成

このスクリプトは、表dictstattabを作成し、RDBMSコンポーネント・スキーマに対する統計をその表にエクスポートします。特定のコンポーネント・スキーマがデータベースに存在しない場合、エクスポートは失敗します。これは、コンポーネントがインストールされていない場合、または無効である場合に発生します。

このスクリプトは、データベースに統計をインポートする場合に有効です。たとえば、次のPL/SQLサブプログラムは既存の統計を削除した後、SYSスキーマに対する統計をインポートします。

EXEC DBMS_STATS.DELETE_SCHEMA_STATS('SYS');
EXEC DBMS_STATS.IMPORT_SCHEMA_STATS('SYS','dictstattab');

次のスクリプトを実行するには、SQL*Plusを使用してAS SYSDBAでデータベースに接続する必要があります。

spool sdict

grant analyze any to sys;

exec dbms_stats.create_stat_table('SYS','dictstattab');

exec dbms_stats.export_schema_stats('WMSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('MDSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('CTXSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('XDB','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('WKSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('LBACSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('ORDSYS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('ORDPLUGINS','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('SI_INFORMTN_SCHEMA','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('OUTLN','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('DBSNMP','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('SYSTEM','dictstattab',statown => 'SYS');
exec dbms_stats.export_schema_stats('SYS','dictstattab',statown => 'SYS');

spool off

索引
A  B  C  D  E  F  H  I  L  M  N  O  P  R  S  T  U  W  X

数値

32ビットから64ビットへの変換。「ワード・サイズ」を参照

A

アクセス制御リスト(ACL)

ネットワーク・ユーティリティ・パッケージへのアクセス権の付与, 3.4.1.2

ネットワーク・ユーティリティ・パッケージのアクセス制御, A.2.13.2 アクセス制御リスト(ACL)

11gリリース1(11.1)における動作の変更, A.2.15

アプリケーション

互換性, 5.2

より新しいライブラリへのリンク, 5.3.2.2.1

古いサーバーでの実行, 5.3.2.1.2

アップグレード, 5, 5

クライアント/サーバー構成, 5.3.1

互換性規則, 5.3.2

オプション, 5.3.3

再リンク規則, 5.3.2

apxrelod.sqlファイル

ダウングレード後の再ロード, 6.5

ASM

データベースのアップグレード後, 4.7.4.1

ディスク・グループの互換性, A.2.7

アップグレード後のオプション作業, 4.7.4

ASM_PREFERRED_READ_FAILURE_GROUPS, 4.8.3 自動メンテナンス・タスク管理

AutoTask, A.2.5

自動ストレージ管理(ASM)

ディスク・グループの互換性, 4.8.2

ファイルのアクセス制御, 3.1.4.5

優先読取りの障害グループ, 4.8.3

ローリング・アップグレード

ASM, 1.8.1

アップグレード, 3.1.4, 3.12 自動UNDO管理

移行, 4.4.1.8

UNDO_MANAGEMENT, A.2.20

AutoTask, A.2.5

B

バックアップ

アップグレード後, 4.4.1.1

ダウングレード前, 6.4

計画の準備, 2.1.6

バイナリのXML記憶域, A.2.12

C

データベースのワークロードの取得およびリプレイ, 2.1.5.6.1

大/小文字区別

パスワード用, 4.4.1.2

catdwgrd.sqlスクリプト, 6.5 CATRELOD.SQLスクリプト, 6.5, 6.5 CATUPGRD.SQLスクリプト, 3.8.3 パスワードの変更

オラクル社が提供するアカウント, 4.5.1

クライアント・ソフトウェア

アップグレード, 5.3.2.2

クライアント/サーバー構成, 1.4.2 オプティマイザ統計の収集, B コマンド

crsctl, 4.6.2.1

互換性

アプリケーション, 5.2

非互換性の調査, 6.2

COMPATIBLE初期化パラメータ, 1.5.1.1

ダウングレード, 1.5.1.3

オリジナルのエクスポート・ユーティリティ, 7.2.2

COMPATIBLE初期化パラメータ, 1.5.1.1, 4.8.2

設定, 4.5.6.1

D

データのコピー

エクスポート/インポートの使用, 7

データ・マイニング・モデル, A.2.9 データ・ポンプ

使用のメリット, 2.1.3.3

データ・ポンプ・エクスポート/インポート

推奨事項, 2.1.3.3, 7.1

オリジナルのエクスポート/インポートとの対比, 7.1

使用のタイミング, 7.1

データベース・リンク

ダウングレード, 6.6.5

データベース・リプレイ

アップグレード前のデータベースのワークロード, 2.1.5.6.1

データベースのアップグレード

ORA_00904による終了, 3.8.3

ORA_00942による終了, 3.8.3

ORA_01722による終了, 3.8.3

Database Upgrade Assistant(DBUA)

メリット, 2.1.3.1

listener.oraファイルへのデータベースの登録, 3.5

実行, 3.6

サイレント・モード, 3.7.2

起動, 3.6.2, 3.6.3

データベースのアップグレード処理

概要, 1.2

データベース

ダウングレード, 6.5

アップグレード, 1.2

クライアント・ソフトウェアのアップグレード, 5.3.2.2

DB_BLOCK_SIZE

新規デフォルト値, A.4.23

DB_BLOCK_SIZE初期化パラメータ

互換性, A.4.23

dblink

ORA-00600, 6.6.5

DBMS_DST PL/SQLパッケージ

ORA-01822エラー, 3.9.6

DBMS_STATSパッケージ

統計表のアップグレード, 4.3.5

DBMS_STATSプロシージャ

統計表作成に使用, B.2

DBUA。「Database Upgrade Assistant」を参照 Developer/2000アプリケーション

アップグレード, 5.5

DGConnectIdentifierプロパティ, 4.4.1.9 直接のアップグレード, 2.1.2 ディスク・グループの互換性, 4.8.2 ディスク

優先読取りの障害グループの指定, 4.8.3

DMSYSスキーマ・オブジェクト, A.2.9 ダウングレード

データベースのバックアップ, 6.4

バイナリのXML記憶域, A.2.12

CATRELOD.SQL, 6.5, 6.5

非互換性の調査, 6.2

ORADIM, 6.5

パッチ・セット・リリース, 6.1

手順, 6.5

スクリプト, 6.5

再実行, 6.5

ダウンストリーム取得

アップグレード, 3.1.9

ダンプ・ファイル

エクスポート・ユーティリティで生成, 7.2

E

パスワードの大/小文字区別の強制, 4.4.1.2

環境変数

アップグレードに必要, 3.8.3

数値リテラルの評価, 5.4.1, A.4.21 エクスポートおよびインポート

推奨事項, 2.1.3.3, 7.1

エクスポート・ユーティリティ, 7.1

データのコピー, 7

要件, 7.2

エクスポート/インポート

メリットおよびデメリット, 2.1.3.3

メリット, 2.1.3.3.2

アップグレードされたデータベースへの影響, 2.1.3.3.1

非互換データ, 7.2.3

時間要件, 2.1.3.3.3

アップグレード, 7.3

拡張遠距離クラスタの構成

優先読取りディスク, 4.8.3

エクステント

セカンダリからの読取り, 4.8.3

extusrupgrade, 4.3.6

F

FAILED_LOGIN_ATTEMPTS初期化パラメータ

DEFAULTの制限, A.3.7

高速リカバリ領域, 3.9.2 ファイルのアクセス制御

SYSASMロール, 3.1.4.5

ネットワーク・ユーティリティ・パッケージへのファイングレイン・アクセス制御, 3.4.1.2 Forms

Oracle Formsアプリケーションのアップグレード, 5.5

H

Hardware Assisted Resilient Data(HARD)

システムのアップグレード, 4.5.6.1

I

インポート・ユーティリティ, 7.1

データのコピー, 7

要件, 7.2

インポート

ダウングレードのダンプ・ファイル, 7.2

非互換性

調査, 6.2

非互換データ

エクスポート/インポート, 7.2.3

初期化パラメータ

Oracle Database 10gでの調整, 4.5.6

Oracle Database 11gでの調整, 3.8.2

ASM_PREFERRED_READ_FAILURE_GROUPS, 4.8.3

互換性

DB_BLOCK_SIZE, A.4.23

SESSION_CACHED_CURSORS, A.4.22

COMPATIBLE, 1.5.1.1 初期化パラメータ、COMPATIBLE, 4.8.2 インストール

Oracle Database 11gリリース1(11.1), 3.2

インスタンス

ダウングレード後に起動, 6.5

INTEGER演算

数値リテラルの評価, 5.4.1, A.4.21

中間リリース

アップグレード, 2.1.2

相互運用性, 1.5.2

L

listener.oraファイル

変更, 3.5

リスナー

Oracle Net Configuration Assistantを使用した変更, 3.5

ロード・テスト, 2.1.5.7 LocalListenerAddressプロパティ

Oracle Data Guard, 4.4.1.9

ロジカル・スタンバイ・データベース

ローリング・アップグレード, 1.8.1

ログイン

DEFAULTの新しい制限, A.3.7

lsinventoryコマンド, 4.2

M

メンテナンス・タスク

AutoTaskを使用したスケジュール, A.2.5

手動アップグレード

メリット, 2.1.3.2

データベースのバックアップ, 3.8.1

OCR構成, 4.5.5

データの移行

異なるオペレーティング・システム, 3.1.8

エクスポート/インポートによるデータの移動, 7.1 複数バージョン, 1.4.2 My Oracle Support

「The Upgrade Companion」Webサイトへのリンク, はじめに, 1.1, 1.1, 2.1.5.4, 3.1.8

N

ネットワーク・ユーティリティ・パッケージ

アクセス制御, A.2.13.2

ネットワーク

ネットワーク・ユーティリティ・パッケージへのACLアクセス権の付与, 3.4.1.2

新機能

アップグレード後の追加, 4.4.1.5

NUMBER演算

数値リテラルの評価, 5.4.1, A.4.21

数値計算

数値リテラルの評価, 5.4.1, A.4.21

数値リテラル

評価, 5.4.1, A.4.21

O

OCIアプリケーション

静的リンク, 5.3.2.2.2

OCIアプリケーション

変更, 5.3.3.3.2

動的リンク, 5.3.2.2.3

アップグレード, 5.3

アップグレード選択肢, 5.3.3

OFA, 1.6 個別パッチ, 1.8 OPatch lsinventoryコマンド, 4.2 OPatchユーティリティ

ローリング・アップグレード, 1.8.1

オペレーティング・システム

データの移行, 3.1.8

Optimal Flexible Architecture。「OFA」を参照 オプティマイザ統計

ディクショナリ・オブジェクトに対する収集, B

収集対象表の作成, B.2

ORA_TZFILE

ダウングレード後の設定解除, 6.5

ORA-00904

"TZ_VERSION"

無効な識別子, 3.8.3

ORA-00942

表またはビューが存在しない, 3.8.3, 3.8.3

ORA-01408エラー・メッセージ, 3.9.5 ORA-01722

無効な数, 3.8.3

ORA-01822エラー・メッセージ, 3.9.6 Oracle Application Express

apexrelod.sqlファイル, 6.5

更新, 4.3.8

Oracle Application Expressの構成, 4.3.8 Oracle ASM

Oracle Grid Infrastructureとともにインストール, 3.1.3

Oracle Cluster Registry(OCR)

手動アップグレード, 4.5.5

Oracle Clusterware

アップグレード, 3.1.4

Oracle Data Guard

ブローカのプロパティの構成, 4.4.1.9

ローリング・アップグレード, 1.8.1

Oracle Database Express Edition

Oracle Databaseへのアップグレード, 1.11

Oracle Database XE

Oracle Databaseへのアップグレード, 1.11

Oracle Express Edition

アップグレード後の推奨作業, 4.4.3

Oracle Grid Infrastructureホーム, 3.1.4

ASMインスタンスのアップグレード, 1.8.1, 3.12

Oracleホーム

複数, 1.4.2.1

Oracle Net Configuration Assistant, 3.5 Real Application Clusters

OPatchを使用したローリング・アップグレード, 1.8.1

アップグレード, 3.1.4

Oracleのリリース番号, 1.4 Oracle Restart

単一インスタンス・データベース, 3.1.4

Oracle Streams

ダウンストリーム取得

アップグレード, 3.1.9

Oracle Universal Installer, 1.2 Oracle XML Database

バイナリのXML記憶域, A.2.12

オラクル社が提供するアカウント

パスワードの変更, 4.5.1

ORADIM

ダウングレード, 6.5

アップグレード, 3.8.3

オリジナルのエクスポート・ユーティリティ

下位互換性, 7.2.2

オリジナルのエクスポート/インポート

データ・ポンプ・エクスポート/インポートとの対比, 7.1

使用のタイミング, 7.1

P

パスワード

大/小文字区別, 4.4.1.2

パッチ・セット・リリース

ダウングレード, 6.1

フィジカル・スタンバイ・データベース

ローリング・アップグレードの実行, 1.8.1, 3.1.6

PLS-00306エラー, 6.5 PL/SQLネイティブ・コンパイル, A.2.13.1 アップグレード後の状態ツール, 3.8.3, 3.8.3, 3.8.3, 3.8.3.1, 3.8.3.1 プリコンパイラ

アプリケーション

変更, 5.3.3.3.1

アップグレード選択肢, 5.3.3

アプリケーションのアップグレード, 5.3 優先読取りの障害グループ

設定, 4.8.3

アップグレードの準備

オプティマイザ統計の収集, B

R

リカバリ・カタログ

アップグレード, 4.3.3

リリース

定義, 1.4

複数, 1.4.2

アップグレード・パス, 2.1.2

ロールバック・セグメント

自動UNDO管理への移行, 4.4.1.8

ローリング・アップグレード

方法, 1.8

Oracle Real Application ClustersおよびOPatch, 1.8.1

クラスタ化されたASMインスタンス, 3.12

ロジカル・スタンバイ・データベース, 3.1.6

ロジカル・スタンバイ・データベースおよびSQL Applyの使用, 1.8.1

フィジカル・スタンバイ・データベース, 1.8.1, 3.1.6

SQL Applyおよびロジカル・スタンバイ・データベース, 1.8.1, 3.1.6

同一コンピュータ上で複数のOracleホームの実行, 1.4.2

S

スケジュール

AutoTask, A.2.5

スキーマ

システム・コンポーネント統計の収集, B.1

スクリプト

ダウングレード, 6.5

再実行, 6.5

アップグレード, 3.4, 3.8.3, 3.8.3

セキュリティ

大/小文字を区別するパスワード, 4.4.1.2

サーバー・パラメータ・ファイル

移行, 4.5.3

SESSION_CACHED_CURSORS

動作の変更点, A.4.22

SESSION_CACHED_CURSORS初期化パラメータ

互換性, A.4.22

共有プールのサブプール, A.4.27 Oracle Database 10gリリース1(10.1)のSHARED_POOL_SIZE, A.4.27 単一インスタンスのASMのアップグレード

ASM

単一インスタンスのアップグレード, 4.7.2

SPFILE

HARD互換のストレージを使用するシステムのアップグレード, 4.5.6.1

SPNC_COMMANDSファイル

リリース10.1, A.4.20

SQLアクセス・アドバイザ, A.2.17 SQL Apply

ローリング・アップグレードの実行, 1.8.1, 3.1.6

SQL管理ベース(SMB), 2.1.5.6.3 SQLパフォーマンス・アナライザ, 2.1.5.6.2 SQL計画ベースライン, A.2.11 SQL計画の管理, 2.1.5.6.3, 2.1.5.6.3, A.2.11 SQLチューニング・セット(STS), 2.1.5.6.3 SQL*Plus

スクリプト

アップグレード, 5.4

Standard Edition

Enterprise Editionへの移行, 1.9

初期データベース, A.2.18

STARTUP UPGRADEコマンド, 6.5 統計

ディクショナリ・オブジェクトに対する収集, B

システム・コンポーネント・スキーマに対する収集, B.1

表の作成, B.2

DBMS_STATS PL/SQLプロシージャを使用したインポート, B.2

統計表

アップグレード, 4.3.5

状態ツール

アップグレードおよびアップグレード後用, 3.8.3, 3.8.3, 3.8.3, 3.8.3.1, 3.8.3.1

サブプール, A.4.27 SYSASM権限, A.2.6 SYSASMロール

ASMファイルのアクセス制御, 3.1.4.5

システム・コンポーネント・スキーマ

統計の収集, B.1

T

テスト

アップグレードに対するアプリケーション, 2.3, 4.4.1.11

計画の作成, 2.1.5

アップグレードの機能, 2.1.5.3

アップグレードの高可用性, 2.1.5.4

アップグレードの統合, 2.1.5.5

アップグレードの最小機能, 2.1.5.2

アップグレードのパフォーマンス, 2.1.5.6

アップグレード処理, 2.2

アップグレード済のテスト・データベース, 2.3

データベース・リプレイの使用, 2.1.5.6.1

アップグレードのボリューム/ロード・ストレス, 2.1.5.7

タイムゾーン・ファイル

ダウングレード後の設定解除, 6.5

タイムゾーン・ファイルのバージョンの不一致, 3.9.6 TIMESTAMP WITH TIME ZONEデータ型, 3.4.1.5 トラブルシューティング

アップグレード, 3.9

U

UNDO_MANAGEMENT初期化パラメータ, 4.4.1.8

デフォルト, A.2.20

Upgrade Companion

My Oracle SupportからWebサイトへのリンク, はじめに, 1.1, 1.1, 2.1.5.4, 3.1.8

アップグレード方法

選択, 2.1.3

Database Upgrade Assistant, 1.2, 2.1.3.1

エクスポート/インポート, 2.1.3.3, 7.3

手動, 2.1.3.2, 3.8

サイレント・モード, 3.7.2

アップグレード・パス, 2.1.2 アップグレードの状態ツール, 3.8.3, 3.8.3, 3.8.3, 3.8.3.1, 3.8.3.1 アップグレード

中止, 3.11

アプリケーション, 5, 5

互換性規則, 5.3.2

オプション, 5.3.3

再リンク, 5.3.2

ASM, 3.1.4 バックアップ計画, 2.1.6 バイナリのXML記憶域, A.2.12 初期化パラメータ, 3.8.2 新しい管理手順, 4.4.1.6 Oracle Application Express, 4.3.8 Oracle Clusterware, 3.1.4 Oracle Formsアプリケーション, 5.5 Oracle Real Application Clusters, 3.1.4 ORADIM, 3.8.3 アップグレード後の処理, 4 準備, 2.1 リカバリ・カタログ, 4.3.3 ローリング・アップグレード, 1.8 CATUPGRD.SQLスクリプトの実行, 3.8.3 スクリプト, 3.4, 3.8.3, 3.8.3 SQL*Plusスクリプト, 5.4 統計表, 4.3.5 テスト, 2.1.5 トラブルシューティング, 3.9 Database Upgrade Assistantの使用, 3.6 utlu112s.sql

例, 3.8.3, 3.8.3, 3.8.3, 3.8.3.1, 3.8.3.1

W

ワード・サイズ

64ビット・ソフトウェア, 1.7

ワークロード

取得およびリプレイ, 2.1.5.6.1

X

xsrelod.sqlスクリプト, 6.5

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。