Oracle® Database

アップグレード・ガイド

12cリリース1 (12.1)

B71306-08(原本部品番号:E41397-13)

2017年7月

Oracle Databaseアップグレード・ガイド 12c リリース1 (12.1)

B71306-08

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

原本著者: Cathy Shea、Douglas Williams

協力者: Drew Adams、Sanjay Bharadwaj、Ashmita Bose、Vickie Carbonneau、XiaoBin Chen、Jonathan Creighton、Ian Dai、Rhonda Day、Mike Dietrich、Joseph Errede、Winston Huang、Patricia Huey、Prakash Jashnani、Mark Jefferys、Sumit Jeloka、Maria Kaval、Alex Keh、Yash Khandelwal、Reema Khosla、Peter Knaggs、Paul Lane、Cindy Lim、Brian McCarthy、David McDermid、Matthew McKerley、Valarie Moore、Louise Morin、Sandeep Nimmakuri、Carol Palmer、Satish Panchumarthy、Robert Pang、Gurumurthy Ramamurthy、Bert Rich、Mark Richwine、Craig Santelman、Samit Sathe、Neeraj Shodhan、Khethavath Singh、Carol Tagliaferri、Srividya Tata、Andrew Wesley

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

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

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

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の登録商標です。

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

Oracle Databaseアップグレード・ガイドのこのリリースでの変更

- 新機能

- 非推奨となった機能

- サポートが終了した機能

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

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

- 1.1.1 アップグレードおよびデータ移行方法と処理

- 1.1.2 Oracle Databaseのアップグレード用スクリプト

- 1.1.3 ログ・ファイルの場所とDIAGNOSTIC_DESTの概要

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

- 1.3 直接のアップグレードをサポートするOracle Databaseのリリース

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

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

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

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

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

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

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

- 1.7.1 Oracle Databaseの互換性の概要

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

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

- 1.7.1.3 互換性およびOracle Database File System (DBFS)

- 1.7.1.4 Oracle Databaseのアップグレードでのダウングレードおよび互換性の概要

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

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

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

- 1.7.2 Oracle Databaseのアップグレードの相互運用性の概要

- 1.8 Optimal Flexible Architecture (OFA)およびOracle Databaseのインストール

- 1.9 32ビットOracle Databaseから64ビットOracle Databaseへの変換

- 1.10 Oracle ASMおよびOracle RACデータベースのローリング・アップグレードの概要

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

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

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

- 1.13 Oracle Database Express Edition (Oracle Database XE)からOracle Databaseへの移行

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

- 2.1 Oracle Databaseのアップグレードを準備するための作業

- 2.1.1 Oracle Databaseの新機能の理解

- 2.1.2 Oracle Databaseのアップグレード・パスの決定

- 2.1.3 Oracle Databaseのアップグレード方法の選択

- 2.1.3.1 Oracle Databaseのアップグレードを自動化(DBUA)する方法

- 2.1.3.2 手動、コマンドラインでOracle Databaseをアップグレードする方法

- 2.1.3.3 Oracle Databaseのアップグレード時のデータの移行でエクスポート/インポートする方法

- 2.1.4 アップグレード時のOracleホームの新しい場所の選択

- 2.1.5 Oracle Databaseのアップグレードでのテスト計画の開発

- 2.1.5.1 アップグレード・テスト

- 2.1.5.2 最小テスト

- 2.1.5.3 機能テスト

- 2.1.5.4 高可用性テスト

- 2.1.5.5 統合テスト

- 2.1.5.6 パフォーマンス・テスト

- 2.1.5.7 Oracle Databaseのアップグレードでのボリューム/ロード・ストレス・テスト

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

- 2.2 Oracle Databaseをアップグレードする場合の要件

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

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

- 2.2.3 Oracle Enterprise Manager Database Controlの構成およびデータの保存

- 2.2.4 emremove.sqlを使用したDB Controlの手動による削除

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

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

- 2.2.6 Oracle Grid InfrastructureおよびOracle Clusterwareのアップグレードの概要

- 2.2.6.1 アップグレード時にローカル・ノード上で実行している必要のあるOracle Clusterware

- 2.2.6.2 DBUAを使用したOracle Real Application Clusters (Oracle RAC)データベースのアップグレードの概要

- 2.2.6.3 アップグレードとアクセス不可能ノードの概要

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

- 2.2.6.5 ASMを使用するOracle RACおよびOracle Databaseのアップグレードに関する推奨事項

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

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

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

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

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

- 2.2.11 Oracle GoldenGateおよびオンライン・データベース・アップグレードの概要

- 2.2.11.1 Oracle GoldenGateを使用したOracle Databaseのアップグレード手順の概要

- 2.2.12 Oracle OLAPデータ・セキュリティ・ポリシーのアップグレードの概要

- 2.2.13 Oracle Label SecurityおよびOracle Database Vaultを使用しているデータベースのアップグレードの要件

- 2.2.13.1 Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件

- 2.2.13.2 Oracle Databaseリリース11.1.0.7でのolspreupgrade.sqlの実行

- 2.2.13.3 Oracle Databaseリリース10.2.0.5または11.2でのolspreupgrade.sqlの実行

- 2.2.14 Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件

- 2.2.14.1 既存のスタンドアロンOWB 11.2.0.3インストールへのOracle Database 12cのアクセスの追加

- 2.2.14.2 Oracle Databaseリリース11.2.0.3での既存のOWB 11.2.0.3インストールの機能の維持

- 2.2.14.3 可能な場合のスタンドアロンOWB 11.2.0.3インストールの使用

- 2.2.15 統合監査スキーマおよびロールの削除

- 2.3 新しいOracle Databaseソフトウェアのインストール

- 2.4 Oracle Databaseをアップグレードする場合のパッチ・セットの更新および要件

- 2.5 Oracle Databaseのアップグレード前情報ツールの概要

- 2.5.1 アップグレード前情報ツール(preupgrd.sql)の使用方法

- 2.5.2 Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項

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

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

- 2.5.2.3 以前のOracle Databaseリリースからのパスワードが指定されたデータベース・リンクの概要

- 2.5.2.4 TIMESTAMP WITH TIME ZONEデータ型に対するOracle Databaseの警告の概要

- 2.5.2.5 オプティマイザ統計の収集によるOracle Databaseの停止時間の短縮

- 2.5.2.6 utluiobjスクリプトを使用したOracle Databaseでの無効なオブジェクトの識別

- 2.5.2.7 アップグレード前にマテリアライズド・ビューのリフレッシュが完了したことの確認

- 2.5.2.8 アップグレード前にメディア・リカバリを必要とするファイルがないことの確認

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

- 2.5.2.10 アップグレード前に未処理の分散トランザクションの解決

- 2.5.2.11 アップグレード前にデータベースのごみ箱の消去

- 2.5.2.12 アップグレード時にスタンバイ・データベースとプライマリ・データベースの同期化

- 2.5.2.13Oracle Application Expressデータベースのアップグレードについて

- 2.5.3 アップグレード前情報ツールのサンプル出力

- 2.6 アップグレードのためのOracle Databaseのバックアップ

- 2.7 アップグレードのための新しいOracleホームの準備

- 2.7.1 Windows上のOracleホームを準備するための前提条件

- 2.8 Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項

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

- 2.9.1 Oracle Call Interface (OCI)およびプリコンパイラ・アプリケーションのアップグレード

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

3 Oracle Databaseのアップグレード

- 3.1 Oracle Databaseのアップグレード計画

- 3.1.1 非CDBのOracle Databaseのアップグレード

- 3.1.2 以前のリリースのアップグレードおよびCDBへのPDBの接続

- 3.1.3 マルチテナント(CDB) Oracle Databaseのアップグレード

- 3.1.4 プラガブル・データベース(PDB)のアップグレード

- 3.2 Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード

- 3.2.1 DBUAの使用に関する推奨事項

- 3.2.1.1 アップグレード時のDBUAの停止の概要

- 3.2.2 DBUAによるOracle Databaseのアップグレードの処理方法

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

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

- 3.2.4 アップグレード時のWindows認証の概要

- 3.2.5 既存の12c Oracleホームからのデータベースの移動

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

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

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

- 3.3 Oracle Databaseのパラレル・アップグレード・ユーティリティの概要

- 3.3.1 新しいパラレル・アップグレード・ユーティリティ(catctl.pl)を実行するための一般的な手順

- 3.3.2 パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ

- 3.3.3 パラレル・アップグレード・ユーティリティの使用例

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

- 3.4.1 WindowsでOracle Databaseのアップグレード時に使用するORADIMの変数

- 3.5 マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード

- 3.6 データ・ディクショナリのアップグレード方法およびステータスの表示方法

- 3.6.1 データ・ディクショナリのパラレル・アップグレード

- 3.6.2 アップグレード・ステータスの設定に対する変更

- 3.6.3 utlrp.sql再コンパイル・スクリプト実行後のステータスの変更

- 3.7 以前のリリースのOracle Databaseでのcatupgrd.sqlスクリプトの概要

- 3.8 catuppst.sqlスクリプトの概要

- 3.9 データベースのトランスポートおよびアップグレードについて(フル・トランスポータブル・エクスポート/インポート)

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

- 3.10.1 Oracle Databaseのアップグレード・モードでの起動の概要

- 3.10.2 異なるORACLE_HOME所有者でのDBUAの実行

- 3.10.3 Oracle Databaseのアップグレード・スクリプトの終了エラー

- 3.10.4 無効なオブジェクト警告およびDBAレジストリ・エラー

- 3.10.5 無効なオブジェクトおよびアップグレード後ツールの不完全な使用

- 3.10.6 Oracle Databaseのアップグレードでのリソース制限

- 3.10.7 Oracle DatabaseでのSQL*Plusエディション・セッションの起動エラー

- 3.10.8 Oracle Database索引のORA-01408に対する手動の回避策

- 3.10.9 リリース11.1.0.7データベースでのDBCAプロセスに対するエラーORA-00018

- 3.10.10 エラーORA-00020 utlrp.sqlの実行中に処理の最大数が超過する

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

- 3.10.12 サーバーの再起動後のアップグレードの継続(ADVM/ACFSドライバ・エラー)

- 3.10.13 アップグレード後の状態ツールのコンポーネント・ステータスの理解

- 3.10.13.1 アップグレード後の状態ツール(utlu121s.sql)のアップグレード・サマリー・レポートのサンプル

- 3.10.14 Standard Editionの初期データベースおよびステータスがOPTION OFFのコンポーネント

- 3.10.15 アップグレード後のOracle ASMパスワード・ファイルの場所の調整

- 3.10.16 エラーORA-27248: sys.dra_reevaluate_open_failuresが実行されています

- 3.10.17 Oracle Databaseエンタープライズ・ユーザー・セキュリティ、OLS-OIDおよびプロビショニング・プロファイルのエラー

- 3.10.18 utl32k.sqlおよびMAX_STRING_SIZEでの32K移行エラー

- 3.10.19 CRSがすべてのノードで停止した場合のASMでのローリング移行状態の喪失

- 3.10.20 データ型のバージョニングによるバージョン間のレプリケーション(ORA-26656)

- 3.10.21 Oracle XML DBエラーORA-64123およびORA-14097

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

- 3.11.1 アップグレード(catctl.pl)スクリプトを使用したアップグレードの再実行

- 3.11.2 マルチテナント・データベース(CDB)のアップグレードの再実行のオプション

- 3.11.2.1 CDBのアップグレード全体の再実行

- 3.11.2.2 指定したCDBのみのアップグレードの再実行

- 3.11.2.3 除外リストを使用した他のPDBがオンライン中のアップグレードの再実行

- 3.11.2.4 CDBまたはPDBを指定するための包含リストを使用したアップグレードの再実行

- 3.11.2.5 -pを使用して失敗したアップグレードを特定のフェーズから再開する

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

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

- 4.2 Oracle Databaseのアップグレード後のOPatchコマンドの概要

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

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

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

- 4.3.3 新しい拡張データ型機能の有効化

- 4.3.4 パラレル実行サーバーの最大値および最小値の調整

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

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

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

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

- 4.3.9 Oracle XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成

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

- 4.3.11 AUTO_LEXERを使用したOracle Text索引の再構築

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

- 4.3.13 外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成

- 4.3.14 Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

- 4.3.15 SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認

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

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

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

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

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

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

- 4.6 Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

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

- 4.6.2 postupgrade_fixups.sqlスクリプトの実行

- 4.6.3 DBMS_STATSを使用した固定オブジェクトの統計の収集

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

- 4.6.5 Oracle Grid Infrastructureでの変更の理解

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

- 4.6.7 新機能の適宜追加

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

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

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

- 4.6.11 Oracle Data Guard Brokerの構成

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

- 4.6.13 アップグレードしたOracle Databaseの統合監査の使用への移行

- 4.6.13.1 Oracle Databaseでの統合監査の移行プロセスの概要

- 4.6.13.2 Oracle Databaseでの統合監査への移行

- 4.6.13.3 統合監査への移行後の古い監査レコードの管理

- 4.6.13.4 統合監査機能の削除

- 4.6.13.5 統合監査を使用しない場合のドキュメント参照

- 4.6.14 アップグレードされた本番Oracle Databaseのテスト

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

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

- 4.8.1 ASMディスク・グループでの共有パスワード・ファイルの作成

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

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

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

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

- 4.10 Oracle Application Expressパッケージ・アプリケーションのオプションでの更新

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

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

- 4.11.2 ORAPWDを使用したパスワード・ファイルの作成または移行

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

- 4.11.4 Oracle Textのアップグレード

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

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

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

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

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

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

- 5.1 新しいOracle Databaseリリースでのアプリケーションのアップグレードの概要

- 5.2 Oracle Databaseの異なるリリースでのアプリケーションの互換性の問題

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

- 5.4 Oracle Databaseでのソフトウェアのアップグレードおよびクライアントとサーバー構成

- 5.4.1 Oracle Databaseのクライアントおよびサーバー・ソフトウェアのソフトウェア・アップグレードのタイプ

- 5.4.1.1 Oracle Databaseのメジャー・リリースのアップグレード

- 5.4.1.2 Oracle Databaseのメンテナンス・リリースのアップグレード

- 5.4.2 Oracle Databaseで使用可能なクライアントおよびサーバーの構成

- 5.4.2.1 異なるコンピュータ上に存在するOracle Databaseクライアントおよびサーバー

- 5.4.2.2 同じコンピュータ上の異なるOracleロケーションに存在するOracle Databaseクライアントおよびサーバー

- 5.4.2.3 同じOracleロケーション上に存在するOracle Databaseクライアントおよびサーバー

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

- 5.5.1 Oracle Databaseサーバー・ソフトウェアのアップグレードに対する規則

- 5.5.1.1 クライアント環境を変更しない場合、再リンクは不要

- 5.5.1.2 Oracle Databaseサーバーの新/旧リリースでアプリケーションの実行が可能

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

- 5.5.2.1 アプリケーションは、より新しいライブラリにリンクできる

- 5.5.2.2 静的にリンクされたアプリケーションを常に再リンクさせる必要がある

- 5.5.2.3 動的にリンクされたアプリケーションの再リンク

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

- 5.6.1 オプション1: アプリケーションを変更しない

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

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

- 5.6.3.1 プリコンパイラ・アプリケーションの変更

- 5.6.3.2 OCIアプリケーションの変更

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

- 5.7.1 数値リテラルの評価

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

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

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

- 6.2 Oracle Databaseのダウングレード時の非互換性の確認

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

- 6.4 Oracle Databaseをダウングレードする前に必要な手順の実行

- 6.5 CDBまたは非CDBのOracle Databaseのダウングレード

- 6.6 単一のプラガブルOracle Database (PDB)のダウングレード

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

- 6.7.1 Oracle DatabaseダウングレードでのOracle XML DB認証の推奨事項

- 6.7.2 リリース11.1.0.7にダウングレードする際のネットワーク・リスナーの再作成

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

- 6.7.4 Oracle Clusterwareの構成のリストア

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

- 6.7.5.1 Enterprise Manager Database Controlをリストアするためのemdwgrdユーティリティの実行

- 6.7.6 以前のバージョンへのOracle Application Expressのリストア

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

- 6.8.1 Oracle Multimediaのダウングレードおよびimrelod.sqlスクリプトのエラー

- 6.8.2 Oracle Database Vaultおよびdvrelod.sqlスクリプトのエラー

- 6.8.3 アップグレードの成功または失敗後のGrid Infrastructureスタンドアロン(Oracle Restart)のダウングレード

- 6.8.4 Oracle ACFSおよびOracle Grid Infrastructureのダウングレードの問題

- 6.8.5 ダウングレード後のデータベース・リンクのパスワードの問題

- 6.8.5.1 Oracle Data Pumpのエクスポートを使用した、既存のすべてのデータベース・リンクが含まれるダンプ・ファイルの作成

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

- 7.1 データの移行でのデータ・ポンプおよびエクスポート/インポートの概要

- 7.2 Oracle Databaseのアップグレード時のデータ・ポンプを使用したデータの移行

- 7.2.1 ネットワーク・リンクを使用したOracle Database全体のインポート

- 7.3 Oracle Databaseのダウングレード時のデータ・ポンプの要件

8 Oracle Database 12cで非推奨となった機能とサポートが終了した機能

- 8.1 Oracle Databaseの変更点

- 8.1.1 非CDBアーキテクチャの非推奨

- 8.1.2 catupgrd.sqlスクリプトの非推奨および新しいcatctl.plユーティリティの導入

- 8.1.3 Oracle Enterprise Manager Database Controlのサポート終了

- 8.1.4 Oracleベースの削除およびクリーンアップに関する変更点

- 8.1.4.1 スタンドアロン削除ツールの変更点

- 8.1.4.2 CLEANUP_ORACLE_BASEプロパティのサポート終了

- 8.1.4.3 -cleanupOBaseの非推奨

- 8.1.5 非推奨およびサポート終了のパラメータ

- 8.1.5.1 LOG_ARCHIVE_LOCAL_FIRST

- 8.1.5.2 SEC_CASE_SENSITIVE_LOGON

- 8.1.5.3 FILE_MAPPING

- 8.1.5.4 O7_DICTIONARY_ACCESSIBILITYパラメータのDELETE_CATALOG_ROLE

- 8.1.5.5 RDBMS_SERVER_DN

- 8.1.6 非推奨となったビュー

- 8.1.7 Oracle Streamsの非推奨

- 8.1.8 非推奨となったアドバンスト・レプリケーション

- 8.1.9 1文字SRVCTL CLIオプションの非推奨

- 8.1.10 Microsoft Windowsプラットフォームでのサポートが終了した機能

- 8.1.10.1 WindowsでのOracle COM Automationのサポート終了

- 8.1.10.2 Oracle Objects for OLEのサポート終了

- 8.1.10.3 Oracle Counters for Windows Performance Monitorのサポート終了

- 8.1.10.4 Oracle Data Provider for .NETの変更点

- 8.1.11 WindowsでのOracle Cluster File System (OCFS)のサポート終了

- 8.1.11.1 Oracle Databaseリリース10.2または11.1およびOCFSとRAWデバイスのアップグレードの概要

- 8.1.11.2 OCFS用のcluvfy comp cfsのサポート終了

- 8.1.12 クラスタ管理での管理ユーザーの格納されたリストの非推奨

- 8.1.13 RAW記憶域デバイスのサポート終了

- 8.1.14 QOSCTL Quality of Service (QoS)コマンドの-checkpasswdの非推奨

- 8.1.15 VARCHAR2、NVARCHAR2およびRAWデータ型の変更点

- 8.1.16 JPublisherの非推奨

- 8.1.17 Oracle JDBCおよびSQLJの変更点

- 8.1.17.1 サーバー内部SQLJの非推奨

- 8.1.17.2 非推奨となったOracleバッチ更新

- 8.1.17.3 非推奨となったEndToEndMetricsに関連するAPI

- 8.1.17.4 非推奨となったストアド・アウトライン

- 8.1.17.5 非推奨となったoracle.sqlパッケージの具象クラス

- 8.1.17.6 非推奨となったdefineColumnTypeメソッド

- 8.1.17.7 非推奨となったCONNECTION_PROPERTY_STREAM_CHUNK_SIZEプロパティ

- 8.1.17.8 暗黙的接続キャッシュのサポート終了

- 8.1.18 Oracle Call Interfaceの変更点

- 8.1.19 resource_limitパラメータのデフォルトの変更

- 8.2 Oracleビジネス・インテリジェンスおよびデータ・ウェアハウスの変更点

- 8.2.1 Oracle Warehouse Builder (OWB)はOracle Databaseでインストールされない

- 8.2.2 チェンジ・データ・キャプチャのサポート終了

- 8.2.3 Oracle Data Miningのサポートが終了した機能

- 8.2.4 Oracle Data Miningモデルのアップグレードに対する変更点

- 8.2.5 OLAPカタログ(AMD)のサポート終了

- 8.3 Oracle Database Securityの変更点

- 8.3.1 セキュリティ監査機能の変更点

- 8.3.2 Oracle Label Securityで非推奨となった機能とパラメータ

- 8.3.3 非推奨となったDBMS_NETWORK_ACL_ADMIN PL/SQLパッケージのプロシージャ

- 8.3.4 IGNORECASEおよびSEC_CASE_SENSITIVE_LOGONの非推奨

- 8.3.5 SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨

- 8.3.5.1 SQLNET.ALLOWED_LOGON_VERSIONパラメータが設定されていないシステムのアップグレード

- 8.3.6 AUDIT_ADMINおよびAUDIT_VIEWERロールの注意

- 8.3.7 NTLMプロトコルを使用したWindows NTS認証の非推奨

- 8.3.8 透過的データ暗号化に対する公開鍵インフラストラクチャの非推奨

- 8.3.9 Secure Sockets Layer (SSL)の暗号スイートのサポート終了

- 8.3.10 データベースのRules Manager (RUL)およびExpression Filter (EXF)のサポート終了

- 8.3.11 Oracle Data Guard Brokerの変更点

- 8.3.12 Oracle Data Pumpのエクスポート・ユーティリティの変更点

- 8.3.13 Oracle Database Vaultの変更点

- 8.3.13.1 非推奨となったデフォルトのルール・セット

- 8.3.13.2 非推奨となったデフォルトのレルム

- 8.3.13.3 非推奨となったAPI

- 8.3.14 Oracle Databaseのセマンティク・テクノロジの変更点

- 8.3.14.1 Oracle Databaseのセマンティク・テクノロジのVPDサポート

- 8.3.14.2 Oracle Databaseのセマンティク・テクノロジのバージョン対応モデルのサポート

- 8.4 Oracleグローバリゼーション・サポートの変更点

- 8.4.1 CSSCANおよびCSALTERのサポート終了

- 8.5 Oracle Multimediaの変更点

- 8.6 Oracle Net Servicesの変更点

- 8.6.1 Oracle Netの接続プーリングのサポート終了

- 8.6.2 Oracle Namesのサポート終了

- 8.6.3 Oracle Net Listenerパスワードのサポート終了

- 8.6.4 Oracle Net ServicesのSQLNET.KERBEROS5_CONF_MITパラメータのサポート終了

- 8.6.5 Oracle Net ServicesのOracle Names制御ユーティリティのサポート終了

- 8.6.6 非推奨となったOracle Net Services用のNT LAN Manager (NTLM)プロトコル

- 8.7 Oracle XML Databaseの変更点

- 8.7.1 Oracle XML DBは必須でアンインストールできない

- 8.7.2 Oracle XML Databaseの非推奨となった機能

- 8.8 Oracle Textの変更点

- 8.8.1 Oracle TextおよびOracle XML DBでのCTXXPATHのサポート終了

- 8.8.2 テキスト索引のALTER INDEX OPTIMIZEのサポート終了

- 8.8.3 テキスト索引のSYNC [MEMORY memsize]のサポート終了

A 以前のリリースのOracle Databaseの変更点

- A.1 Oracle Database 11gリリース2 (11.2)での動作の変更

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

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

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

- A.1.4 非推奨となったXML DB構造体

- A.1.5 Oracle Databaseで非推奨のCursor_sharing=similar

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

- A.1.7 データ・マイニングJava APIの非推奨

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

- A.1.9 Oracle Database 11gリリース2 (11.2)でサポート終了の初期化パラメータ

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

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

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

- A.1.13 LOG_ARCHIVE_DEST_nパラメータの変更

- A.2 Oracle Database 11gリリース1 (11.1)での動作の変更

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

- A.2.2 Oracle Database 11gリリース1 (11.1)でサポート終了の初期化パラメータ

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

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

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

- A.2.6 Oracle ASM管理用の新しいSYSASM権限とOSASMグループ

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

- A.2.8 COMPUTE STATISTICS句およびESTIMATE STATISTICS句

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

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

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

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

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

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

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

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

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

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

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

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

- A.2.18 Standard Editionの初期データベース

- A.2.19 コア・ダンプの位置

- A.2.20 UNDO_MANAGEMENTの新しいデフォルト値

- A.2.21 LOG_ARCHIVE_DEST_nパラメータ

- A.2.22 SHARED_POOL_SIZEパラメータ

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

- A.2.24 自動診断リポジトリ

- A.3 Oracle Database 10gリリース2 (10.2)での動作の変更

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

- A.3.2 Oracle Database 10gリリース2 (10.2)でサポート終了の初期化パラメータ

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

- A.3.4 SQL

- A.3.5 CONNECTロール

- A.3.6 タイムゾーン・ファイル

- A.3.7 FAILED_LOGIN_ATTEMPTSに対する新しい制限

索引

はじめに

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

また、『Oracle Databaseアップグレード・ガイド』では、Oracle Database(Standard Editionともいう)およびOracle Database Enterprise Edition製品の様々な機能についても説明します。Oracle DatabaseおよびOracle Database Enterprise Editionには、同等の基本機能があります。ただし、Oracle Database 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 (http://support.oracle.com)の「Oracle Upgrade Companion」

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

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

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

- Oracle Databaseにバンドルされるユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

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

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

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

Oracle Databaseアップグレード・ガイドのこのリリースでの変更

Oracle Databaseの新しいリリースでは、パフォーマンス、自動化およびレポート作成のアップグレードに対する改善が提供されています。

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

- 新機能

- 非推奨となった機能

- サポートが終了した機能

新機能

Oracle Database 12cには、多くの新しい機能が含まれており、その一部はアップグレードに直接影響します。アップグレード処理の新しい機能を次に示します。

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

- データベースのアップグレードでのパラレル処理

- 拡張されたアップグレード前およびアップグレード後のサマリー・レポート

- Oracle Grid Infrastructureのアップグレードの拡張機能

- プラガブル・データベース

- アップグレード時のOracle XML Databaseのインストール

関連項目:
Oracle Database 12cの新機能の詳細は、『Oracle Database新機能ガイド』を参照してください。

アップグレード前情報ツール

Oracle Database 12cでは、新しいアップグレード前情報ツールが作成されています。この新しいユーティリティによって、アップグレードの前と後の両方に存在する可能性のある問題に対処するための修正スクリプトが提供されます。Database Upgrade Assistant (DBUA)およびアップグレード前情報ツールは、アップグレードするデータベースの詳細なチェックを行い、問題が発見されるとそれを修正するための特別なスクリプトが生成されます。

アップグレード前フェーズで、修正スクリプトを対話形式で実行して、検出された問題を解決できます。アップグレード後修正スクリプトは、アップグレード処理の結果に応じて生成されます。クリティカルな問題が発見されると、DBUAによって適切なスクリプトの実行が要求されます。

関連項目:
「アップグレード前情報ツール(preupgrd.sql)の使用方法」

データベースのアップグレードでのパラレル処理

Oracle Database 12cでは、catupgrd.sqlアップグレード・ユーティリティがcatctl.plパラレル・アップグレード・ユーティリティで置き換えられました。アップグレード・スクリプトおよび処理を並行して実行できるため、CPU性能を最大限に活用してアップグレード時間が短縮されます。データベースのアップグレードを、パラレル・モードまたはシリアル・モードで実行することを選択できます。以前のリリースでは、シリアル・モードのみが使用でき、これは、使用可能なCPU性能に関係なく、アップグレード・スクリプトと処理が順番に実行されることを意味します。

Database Upgrade Assistant (DBUA)はパラレル・アップグレード・ユーティリティを最大限に活用し、DBUAはデフォルトでパラレル・アップグレード・モードで実行されます。パラレル処理では、データベースが存在するシステムのCPUのパワーを最適に使用することによって、データベース・アップグレードの時間が短縮されます。

関連項目:
「Oracle Databaseのパラレル・アップグレード・ユーティリティの概要」

アップグレード処理中にDBUAの再起動が可能

このリリースには、アップグレード中の障害からのリカバリ用や障害が発生した時点からのアップグレードの再開用の、より多くのオプションがあります。たとえば、Oracle Database 12cでOracle Recovery Manager (RMAN)サポートおよび保証付きリストア・ポイント機能が導入されました。DBUAで検出された問題を修正して、アップグレード処理に戻ることができます。

- アップグレード処理を追跡する実績ロギングを使用することで、アップグレードが失敗した場合にデータベースをリストアするための保証付きリストア・ポイントを使用するためのオプションがあります。DBUAによってリストア・ポイントが自動的に作成されます。

- DBUAのアップグレード前手順(バックアップおよびリストア、リスナー移行を含む)でエラーが発生した場合、DBUAを再起動できます。

- エラーの発生が原因でアップグレード後手順が失敗した場合は、アップグレードを終了するための手動手順がDBUAによって表示されます。アップグレード後手順が停止した場合、保存されたアップグレード後手順を遅延して、アップグレードを手動で終了できます。アップグレード後手順には、データの移動、移行後の処理、タイム・ゾーン・ファイルのアップグレードまたはOracle Enterprise Managerの構成が含まれます。

- アップグレードが失敗した場合にデータベースをリストアするためにOracle RMANを使用するオプションは、このリリースで改善されています。このような場合、DBUAを使用することで、自身のバックアップからデータベースをリストアすることが可能です。

- RMANバックアップを使用すると、Oracle Automatic Storage Management (Oracle ASM)を使用するデータベースのバックアップがDBUAでサポートされます。

拡張されたアップグレード前およびアップグレード後のサマリー・レポート

DBUAではアップグレードの前後にHTMLレポートが生成されます。これらのレポートにはコンポーネントのステータスが含まれ、さらに問題を修正するためのアクションを使用できる可能性のある無効なオブジェクトを含む、データベース・オブジェクトまでドリルダウンする機能が提供されます。

関連項目:
「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」

Oracle Grid Infrastructureのアップグレードの拡張機能

Oracle Database 12cでのOracle Grid Infrastructureのアップグレードには、rootスクリプトの自動化プロシージャ、フル・リリース・アップグレードおよびパッチ・アップグレードを実行するための改善された機能および改善された安定性と使い勝手のよさを提供するためのステータス・チェックおよびアップグレード・チェックポイントに対する拡張が含まれています。

関連項目:
Oracle Grid Infrastructureのアップグレードの詳細は、ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

プラガブル・データベース

プラガブル・データベース(PDB)は、Oracle Database 12cの新機能です。Oracle Databaseは、マルチテナント・アーキテクチャを使用しているため、マルチテナント・コンテナ・データベース(CDB)を構成したり、1つのPDBを含めることができます。Oracle Multitenantオプションを購入すると、CDB内に複数のPDBを含めることができます。マルチテナント・アーキテクチャの主な利点の1つは、CDBに対してアップグレードまたはパッチを適用でき、そのアップグレードやパッチがそのCDB内のすべてのPDBに実装されることです。これによってアップグレードの管理が非常に容易になります。

関連項目:
PDBを使用する際の概要およびドキュメント・ロードマップについては、『Oracle Database概要』を参照してください。

アップグレード時のOracle XML Databaseのインストール

Oracle XML Database (Oracle XML DB)は、Oracle Databaseの必須コンポーネントになりました。これをアンインストールすることはできず、新しいデータベースの作成時にこれを含まないためのオプションはありません。アップグレード時にOracle XML DBが見つからない場合、Oracle XML DBはSYSAUX表領域に自動的にロードされます。アップグレードされたOracle DatabaseにはOracle XML DBが含まれます。

関連項目:
Oracle XML DBの新機能の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

非推奨となった機能

アップグレード処理に直接影響する非推奨になった1つ以上の機能に加え、このリリースには、Oracle Databaseの様々な機能の非推奨とそれらの機能に対する代替機能が含まれています。

- catupgrd.sqlアップグレード・スクリプトはOracle Database 12cでは非推奨です。パラレル・アップグレード・ユーティリティ(catctl.pl)によってcatupgrd.sqlが置き換えられました。詳細は、「catupgrd.sqlスクリプトの非推奨および新しいcatctl.plユーティリティの導入」を参照してください。

- 新しいOracle Database 12cリリースにアップグレード後のOracle Databaseの動作に影響する変更および非推奨については、第8章「Oracle Database 12cでの非推奨となった機能とサポートが終了した機能」に記載されています。

- 以前のリリースの動作に影響する変更および非推奨については、付録A「以前のリリースのOracle Databaseの変更点」に記載されています。

サポートが終了した機能

Oracle Database 12cでサポートが終了した機能の包括的なリストは、第8章「Oracle Database 12cでの非推奨となった機能とサポートが終了した機能」に記載されています。データベース環境に影響する変更について、この章全体を確認することをお薦めします。

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

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

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

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

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

- 直接のアップグレードをサポートするOracle Databaseのリリース

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

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

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

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

- Optimal Flexible Architecture (OFA)およびOracle Databaseのインストール

- 32ビットOracle Databaseから64ビットOracle Databaseへの変換

- Oracle ASMおよびOracle RACデータベースのローリング・アップグレードの概要

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

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

- Oracle Database Express Edition (Oracle Database XE)からOracle Databaseへの移行

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

アップグレードによって、既存のOracle Database環境(インストール済コンポーネントおよび関連するアプリケーション)がOracle Database 12c環境に変換されます。データベースのデータ・ディクショナリは、新しいリリースにアップグレードされます。アップグレードによってユーザー・データが直接影響を受けることはありません。アップグレード中に、データへのアクセス、データの変更または移動が行われることはありません。

データを移行することは、1つのOracle Databaseから、データの移行または移動用に事前に作成された別のデータベースにデータを移動することです。データを移行するのは、新しいハードウェアやオペレーティング・システム・プラットフォーム、または新しいキャラクタ・セットにデータベース環境を移動する必要がある場合です。最新リリースにアップグレードすることは、移行には含まれません。アップグレード処理は、データの移行後に個別に行われます。

『Oracle Databaseアップグレード・ガイド』に記載されているアップグレード手順はすべてのオペレーティング・システムに適用されますが、例外として、オペレーティング・システム固有の詳細項目が必要になる可能性があります。この場合、オペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照するように指示されます。

関連項目:
アップグレード時のデータ移行の詳細は、「Oracle Databaseのアップグレード時のデータ・ポンプを使用したデータの移行」を参照してください。

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

- アップグレードおよびデータ移行方法と処理

- Oracle Databaseのアップグレード用スクリプト

- ログ・ファイルの場所とDIAGNOSTIC_DESTの概要

1.1.1 アップグレードおよびデータ移行方法と処理

アップグレード処理を自動化し、時間を最も効率的に使用するための機能および製品が提供されています。Oracle Databaseでは、データベースを新しいリリースにアップグレードするための次の方法がサポートされています。

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

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

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

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

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

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

1.1.2 Oracle Databaseのアップグレード用スクリプト

アップグレード処理では、アップグレードの前後およびアップグレード中に実行するツールおよびスクリプトのセットが提供されます。表1-1、「アップグレード、アップグレード後およびダウングレード・スクリプト」に、各種のスクリプトおよびツールとその説明をリストします。これらのツールの一部は、UPGRADEモードで実行することはできません。

関連項目:
ログ・ファイルの保存場所については、「ログ・ファイルの場所とDIAGNOSTIC_DESTの概要」を参照してください。

表1-1 アップグレード、アップグレード後およびダウングレード・スクリプト

スクリプト

説明

catcon.pl

UPGRADEモードで実行する必要があります。このスクリプトは、CDBをアップグレードする際に使用されます。

catctl.pl

UPGRADEモードで実行する必要があります。Oracle Database 12cでは、catupgrd.sqlアップグレード・ユーティリティがcatctl.plパラレル・アップグレード・ユーティリティで置き換えられました。アップグレード・スクリプトおよび処理を並行して実行できるため、CPU性能を最大限に活用してアップグレード時間が短縮されます。DBUAではこのツールが使用されます。「Oracle Databaseのパラレル・アップグレード・ユーティリティの概要」を参照してください。

catdwgrd.sql

これは、ダウングレード・スクリプトで、アップグレードする前の以前のリリースへダウングレードする手順で使用します。「CDBまたは非CDBのOracle Databaseのダウングレード」を参照してください。

catnoamd.sql

UPGRADEモードでは実行しないでください。アップグレード後にのみ、このスクリプトを実行します。catnoamd.sqlスクリプトは、OLAPカタログのコンポーネント(AMDとも呼ばれます)を削除します。「OLAPカタログ(AMD)のサポート終了」を参照してください。

catnoexf.sql

アップグレード・プロセスによって、このスクリプトが実行されますが、アップグレード前にcatnoexf.sqlスクリプトを実行できます。このスクリプトをUPGRADEモードで実行しないでください。catnoexf.sqlスクリプトによって、このリリースでサポートが終了したExpression Filter (EXF)およびデータベースRules Manager (RUL)コンポーネントが削除されます。「データベースのRules Manager (RUL)およびExpression Filter (EXF)のサポート終了」を参照してください。

catuppst.sql

UPGRADEモードでは実行しないでください。ORACLE_HOME/rdbms/adminディレクトリにあるcatuppst.sqlを実行し、データベースをUPGRADEモードにする必要がない残りのアップグレード操作を実行します。Oracleパッチ・セット更新(PSU)がOracleホームにインストールされている場合は、このスクリプトによってそのPSUがデータベースに自動的に適用されます。DBUAではcatuppst.sqが自動的に実行されるため、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」に記載されている手動アップグレードとは別に、このスクリプトのみを実行する必要があります。「catuppst.sqlスクリプトの概要」を参照してください。

重要: このスクリプトの実行は必須です。

注意: 手動でアップグレードする場合、catuppst.sql手順を実行しないと、データベースのパフォーマンスが時間とともに低下します。

emdwgrd

このスクリプトをUPGRADEモードで実行しないでください。emdwgrdユーティリティは、リリース11gデータベースのOracle Enterprise Manager Database Control (DB Control)構成ファイルおよびデータを保存します。Oracle Database 12cのダウングレードが必要な場合にDB Controlをリストアできるようにするには、アップグレード前にemdwgrdを実行しておきます。

関連項目: Oracleサポート・ドキュメントID 1484775.1 ( http://support.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1484775.1)

関連項目: 「Oracle Enterprise Manager Database Controlの構成およびデータの保存」

emremove.sql

emremove.sqlスクリプトは、Oracle Enterprise Manager関連のスキーマおよびオブジェクトを削除します。このスクリプトを使用して、DB Controlを手動で削除します。emremove.sqlをアップグレード処理の前に実行することで、停止時間が最小化されます。パラレル・アップグレード・ユーティリティおよびDBUAが自動的にこのスクリプトを実行するため、これはオプションのアップグレード前手順です。「emremove.sqlを使用したDB Controlの手動による削除」を参照してください。

重要: ダウングレードしてDB Controlをリストアするオプションを使用するためにDB Controlの構成およびデータの保持が必要な場合は、「Oracle Enterprise Manager Database Controlの構成およびデータの保存」に記載されているemdwgrdを使用した手順を最初に行う必要があります。

olspreupgrade.sql

このスクリプトをUPGRADEモードで実行しないでください。olspreupgrade.sqlスクリプトは事前処理スクリプトで、Oracle Label Security (OLS)およびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする場合に必要です。「Oracle Label SecurityおよびOracle Database Vaultを使用しているデータベースのアップグレードの要件」を参照してください。

postupgrade_fixups.sql

postupgrade_fixups.sqlスクリプトは、Oracle Databaseに付属しています。アップグレード後に、postupgrade_fixups.sqlを実行します。このスクリプトは、DBUAによって自動的に実行されますが、アップグレード後にいつでもこのスクリプトを実行することができます。「postupgrade_fixups.sqlスクリプトの実行」を参照してください。

preupgrd.sql

preupgrd.sqlアップグレード前情報ツールは、Oracle Databaseに付属しています。データベースを分析するために、preupgrd.sqlをアップグレード前に実行します。アップグレード前情報ツールでは、DBUAが確認する項目のプレビューが提供され、ソース・データベースでフラグ付けされている問題を解決するために実行できる修正スクリプトが生成されます。(このスクリプトによってutlu121i.sqlスクリプトが置き換えられます。)「Oracle Databaseのアップグレード前情報ツールの概要」を参照してください。

utlrp.sql

utlrp.sqlを使用して、ストアドPL/SQLおよびJavaコードを再コンパイルします。DBUAではこのスクリプトが自動的に実行されます。手動でアップグレードする場合、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」の説明に従って、このスクリプトを実行する必要があります。

utlu121s.sql

utlu121s.sqlアップグレード後の状態ツールは、Oracle Databaseに付属していて、DBA_REGISTRY内の各コンポーネントのバージョンおよびアップグレード経過時間が表示されます。アップグレード後の状態ツールは、データベースのアップグレード後にいつでも実行できます。「アップグレード後」を参照してください。

utluiobj.sql

utluiobj.sqlを使用して、アップグレード処理によって新たに無効になったオブジェクトのみを表示します。「utluiobjスクリプトを使用したOracle Databaseでの無効なオブジェクトの識別」を参照してください。

1.1.3 ログ・ファイルの場所とDIAGNOSTIC_DESTの概要

アップグレード・スクリプトによって作成された診断ログ・ファイルの場所は、環境変数およびパラメータの設定に応じて異なります。DIAGNOSTIC_DEST初期化パラメータは自動診断リポジトリ(ADR)の場所を設定し、このリポジトリは、データベースの外部に格納されているディレクトリ構造です。

DIAGNOSTIC_DEST初期化パラメータが省略されるかNULLの場合は、データベースによって次のデフォルトの設定が使用されます。

- 環境変数ORACLE_BASEが設定されている場合、DIAGNOSTIC_DESTはORACLE_BASEで指定されたディレクトリにデフォルト設定されます。そのため、生成されたスクリプトおよびログ・ファイルはOracle_Base/cfgtoollogs/tool_name/SID/upgradenに作成されます(nは、このシステムで実行したアップグレードの続き番号を表します)。
たとえば、アップグレード中にORACLE_BASEが定義されているシステムでDBUAによって作成されたログは、次の場所にあります。

ORACLE_BASE/cfgtoollogs/dbua/SID/upgraden

実際のアップグレードを実行する前には、Oracle_Base/cfgtoollogs/dbua/logsにDBUAログが保存されます。

- ORACLE_BASEが定義されていない場合、生成されたスクリプトおよびログ・ファイルはORACLE_HOME/cfgtoollogs/tool_name/SID/upgradenに作成されます(nは、このシステムで実行したアップグレードの続き番号を表します)。

- Oracle Database 11g以上では、アラート・ログを含むすべての診断データがADRに格納されるため、初期化パラメータのBACKGROUND_DUMP_DESTおよびUSER_DUMP_DESTが非推奨になりました。これらのパラメータは、ADRの場所を指定する初期化パラメータDIAGNOSTIC_DESTに置き換えられています。

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

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

サポートWebサイトでは、アップグレード前の要件、アップグレード処理、アップグレード後、互換性および相互運用性に関する最新情報、ディスカッションおよびベスト・プラクティスが提供されています。

Oracle Databaseリリースの最新情報は、My Oracle Support (http://support.oracle.com)を参照してください。Note IDまたは「データベース・アップグレード」などのキーワードで検索できます。My Oracle Supportの使用方法のヘルプは、http://docs.oracle.com/cd/E25290_01/index.htmにあります。

表1-2 My Oracle SupportでのOracle Databaseのアップグレードに関する情報

参照内容

参照先

すべてのナレッジ・ベースおよびOracle Database 12cのアップグレードに関する情報

http://support.oracle.comで検索条件を入力します。

My Oracle Support (MOS)およびサポート・ノートの使用方法の詳細は、http://docs.oracle.com/cd/E25290_01/index.htmを参照してください。

Oracle Database 11gリリース2 (11.2)への個別アップグレードの実行

My Oracle Support (http://support.oracle.com">>http://support.oracle.com)のID 1462240.1「Oracle Upgrade Companion」を参照してください。以前のリリースへのアップグレードで使用できるその他のCompanionも提供しています。

アップグレード前情報ツールのダウンロードおよび実行

My Oracle Support (http://support.oracle.com)の「Oracle Database Pre-Upgrade Utility」(ID 884522.1)。

1.3 直接のアップグレードをサポートするOracle Databaseのリリース

現行のOracle Databaseがリリース10.2.0.5、11.1.0.7またはリリース11.2.0.2以上の場合、Oracle Database 12cへの直接のアップグレードを実行できます。現行のOracle Databaseがリリース10.2.0.5より前またはリリース11.2.0.1の場合は、Oracle Database 12cへの直接のアップグレードはサポートされていません。この場合は、新しいOracle Database 12cリリースにアップグレードする前に、中間リリースにアップグレードするか、エクスポート/インポートなどの代替のアップグレード方法を使用する必要があります。

関連項目:
ダイレクトおよび中間アップグレード・パスの詳細は、「Oracle Databaseのアップグレード・パスの決定」を参照してください。

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

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

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

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

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

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

- 手順4: 本番Oracle Databaseの準備および保存

- 手順5: 本番Oracle Databaseのアップグレード

- 手順6: 新しい本番Oracle Databaseのチューニングおよび調整

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

図1-1 Oracle Databaseのアップグレード手順のワークフロー

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

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

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

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

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

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

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

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

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

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

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

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

- 結果を確認し、テストでの相違点を記録します。

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

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

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

手順4: 本番Oracle Databaseの準備および保存

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

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

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

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

手順5: 本番Oracle Databaseのアップグレード

- Oracle Databaseの新しいリリースに本番データベースをアップグレードします。
第3章「Oracle Databaseのアップグレード」では、DBUAを使用または手動アップグレードを実行する場合の手順5について説明します。

- アップグレードの後、本番データベースの全体バックアップおよびその他のアップグレード後の処理を行います。
第4章「Oracle Databaseのアップグレード後の作業」では、アップグレード後の手順5のバックアップ手順および手順6のその他のアップグレード後の処理について説明します。

手順6: 新しい本番Oracle Databaseのチューニングおよび調整

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

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

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

- すべてのアプリケーションがテストされ、適切に動作するまでは、本番ユーザーを新しいリリースにアップグレードしないでください。

第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」では、アプリケーションの更新について説明します。

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

『Oracle Databaseアップグレード・ガイド』では、Oracle Databaseの異なるリリース間での移動について説明します。リリース番号の最初の部分はメジャー・リリース番号を示します。Oracle Databaseのメンテナンス・リリースはリリース番号の2つ目の部分の変更で示されます。パッチ・リリースは4つ目の部分の変更で示されます。

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

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

関連項目:

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

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

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

『Oracle Databaseアップグレード・ガイド』にデータベースのメジャー・リリース番号に関する説明が記載されている場合、その説明は、そのデータベースのメジャー・リリースに含まれるすべてのリリースに適用されます。

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

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

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

- Oracle Databaseは、以前のリリースとは別の新しいOracleホームにインストールする必要があります。
1つのOracleホームに複数のリリースをインストールすることはできません。複数のOracleホームを作成する場合、OFAを採用することをお薦めします。「Optimal Flexible Architecture (OFA)およびOracle Databaseのインストール」を参照してください。

- 本番で実行するには、データベース・サーバーが、メジャー、メンテナンスおよびパッチ・リリース番号と一致している必要があります。メジャー・リリース番号と一致しているだけでは十分ではありません。

- Oracle Databaseサーバーの以降のリリースは以前のデータベースとアクセスできますが、アップグレードの目的に限定されます。たとえば、Oracle Database 12cデータベース・サーバーは、アップグレード・モードで起動された場合にOracle Database 10gリリース2 (10.2.0.5)データベースにアクセスできます。

関連項目:
ご使用のオペレーティング・システムでの複数のOracle Databaseリリースの実行および適用される可能性のある制限の詳細は、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

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

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

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

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

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

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

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

異なるコンピュータ上のOracleホームにOracle Database 12cおよびOracle Database 11gデータベースをインストールし、いずれかまたはすべてのデータベースに接続するOracle Database 11gクライアントがあるOracle Database 12cをインストールできます。ただし、最新リリースを最初にインストールし、その後に以前のリリースを古い順にインストールする必要があります。これにより、各インストールがOracleインベントリを認識します。

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

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

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

- Oracle Databaseの互換性の概要

- Oracle Databaseのアップグレードの相互運用性の概要

1.7.1 Oracle Databaseの互換性の概要

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

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

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

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

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

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

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

- 互換性およびOracle Database File System (DBFS)

- Oracle Databaseのアップグレードでのダウングレードおよび互換性の概要

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

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

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

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

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

注意:

- Oracle Database 12cをアップグレードする前に、COMPATIBLEパラメータをOracle Database 12cの最小設定である11.0.0以上に設定する必要があります。

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

- COMPATIBLEパラメータを増やした後に、データベースはダウングレードできません。

注意:
Oracle Databaseリリース10.2からアップグレードする場合、COMPATIBLEの値を11.0.0以上に設定する必要があります。これは、アップグレード時に行う必要があります。COMPATIBLE初期化パラメータ値を増加した後に10.2にダウングレードすることはできないため、アップグレードの準備が完了するまで、この変更は行わないでください。

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

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

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

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

Oracle Databaseのリリース

デフォルト値

最小値

最大値

Oracle Database 12c

12.0.0

11.0.0

12.1.0

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

11.2.0

10.0.0

11.2.0

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

11.0.0

10.0.0

11.1.0

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

10.2.0

9.2.0.

10.2.0

1.7.1.3 互換性およびOracle Database File System (DBFS)

Oracle Database 12c以上では、Oracle Database File System (DBFS)のファイルおよびフォルダに、Oracle XML DB Repositoryからリポジトリ・パス/dbfsでアクセスできます。この機能によって、DBFSファイルおよびフォルダに対するFTPおよびHTTP(S)/WebDAVアクセスが提供されます。DBFSファイル・システムは、Webを介して共同で編集および管理でき、WindowsプラットフォームでのDBFSファイル・システムに対するファイル・システムのようなアクセスが拡張されます。COMPATIBLE初期化パラメータを12.0.0に設定することで、DBFSに対する最新の拡張機能へのアクセスが可能になります。

関連項目:
DBFSの使用方法の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

1.7.1.4 Oracle Databaseのアップグレードでのダウングレードおよび互換性の概要

Oracle Database 12cにアップグレードする前に、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。COMPATIBLE初期化パラメータがこの値に設定されている場合にかぎり、Oracle Database 12cのサブセットの機能のみが使用できます。

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

重要:
COMPATIBLEパラメータを増やすと、データベースをダウングレードできません。

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

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

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

- COMPATIBLE初期化パラメータを11.0.0に設定してOracle Database 12cデータベースを実行すると、Oracle Database 11gと互換性のあるデータベース構造がディスクに生成されます。つまり、COMPATIBLE初期化パラメータの設定によって、新機能を有効または無効にできます。データベースの互換性を損なう新機能をCOMPATIBLE初期化パラメータによって使用しようとすると、エラーが発生します。ただし、互換性を損なう変更をディスクに行わない新機能はすべて使用できます。

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

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

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

データベースの互換性レベルは、COMPATIBLE初期化パラメータの値に対応します。

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

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

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

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

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

1.7.2 Oracle Databaseのアップグレードの相互運用性の概要

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

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

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

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

1.8 Optimal Flexible Architecture (OFA)およびOracle Databaseのインストール

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

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

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

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

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

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

- データ・ディクショナリの空き領域の断片化を排除し、その他の断片化を分離し、リソース競合を最小化します。

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

関連項目:

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

- データファイルおよびテンプレートの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

1.9 32ビットOracle Databaseから64ビットOracle Databaseへの変換

以前は32ビットOracle Databaseインストールを使用していて64ビットOracle Databaseソフトウェアをインストールすると、Oracle Database 12cへのアップグレード中にデータベースは自動的に64ビットに変換されます。

1.10 Oracle ASMおよびOracle RACデータベースのローリング・アップグレードの概要

ローリング・アップグレードは、Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM) (まとめて Oracle Grid Infrastructureと称される)では動作しますが、Oracle Databaseソフトウェアでは動作しません。Oracle Real Application Clusters (Oracle RAC)環境では、ローリング・アップグレードを使用してOracle Databaseのメジャー・リリース、メンテナンス・リリースまたはパッチ・リリースへのアップグレードはできません。ただし、Oracle RAC環境では、ほとんどのデータベース・パッチ(個別パッチと呼ばれることもある)およびすべてのデータベース・パッチ・セット更新および重要なパッチ更新(PSUおよびCPU)は、ローリング・パッチ・インストールを使用して適用できます。

関連項目:
「Oracle Databaseのローリング・アップグレードの実行方法の概要」

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

表1-4は、ローリング・アップグレードの様々な実行方法の概要と適切なドキュメントへの参照情報を示しています。

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

方法

説明

参照

Oracle Enterprise Manager Cloud Control

Oracle Database 12c以上では、データベースのローリング・アップグレードを実行するためのCloud Controlサポートが提供されています。

Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプ

Oracle Data Guard SQL Apply

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

「Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件」

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

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

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

Oracle ClusterwareおよびOracle Universal Installer(OUI)

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

ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』およびご使用のオペレーティング・システム固有のOracle Clusterwareインストール・ガイド

Oracle Automatic Storage Management (Oracle ASM)

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

ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』

『Oracle Automatic Storage Management管理者ガイド』のOracle ASMのローリング・アップグレードの使用方法に関する説明

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

Oracle Databaseの新しいリリースより前のリリースのStandard Editionデータベースを使用している場合、まず、第3章「Oracle Databaseのアップグレード」に従ってアップグレードする必要があります。次に、Oracle Enterprise EditionソフトウェアをインストールすることによってOracle Enterprise Editionデータベースに移行できます。1つのエディションから別のエディションに移行するには、Enterprise EditionとStandard Editionの両方でOracle Databaseの同じリリースを使用する必要があります。たとえば、両方のリリースがリリース12.1 (または別のリリース・レベル)である必要がありますが、変更を実行するには、両方のエディションで同じである必要があります。

注意:

この手順を実行すると、Oracle Standard Editionソフトウェアが削除され、その結果としてOracleホーム下に存在するデータベース・ファイルが削除されます。そのため、現行のOracleホーム下のデータベース・ファイルをバックアップしてください。

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

1. Oracle Standard Editionサーバー・ソフトウェアとOracle Enterprise Editionサーバー・ソフトウェアのリリース番号が同じかどうかを確認します。

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

3. オペレーティング・システムがWindowsの場合、OracleServiceSID(SIDはインスタンス名)を含むすべてのOracleサービスを停止します。Oracle Databaseサービスの停止の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

4. 保持する必要のある現行のOracleホーム下のデータベース・ファイルをすべてバックアップします。データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5. Standard Editionサーバー・ソフトウェアを削除します。(この手順を実行すると、Oracleホーム下に存在するすべての既存のデータベース・ファイルが削除されます。)
Oracleホームから削除ツールを実行します。この削除ツールは、インストール後に別のコマンド(deinstall)としてOracleホーム・ディレクトリから使用できます。これはORACLE_HOME\deinstallにあります。

WindowsでOracleホームを削除するには、次の構文を使用します。

setup.exe –deinstall –home path_of_Oracle_home_to_be_deinstalled

LinuxおよびUNIXでOracleホームを削除するには、次の構文を使用します。

$ ./runInstaller –deinstall –home path_of_Oracle_home_to_be_deinstalled

注意:
Oracle Database 12c以上では、削除ツールはデータベース・インストール・メディアに統合されています。削除ツールは、-deinstallおよび-homeオプションを指定して、LinuxおよびUNIXではrunInstaller、Windowsではsetup.exeを使用して、Oracle Database、Oracle Database ClientまたはOracle Grid Infrastructureインストール・メディアのベース・ディレクトリから実行できます。オペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

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

7. 既存のデータベースが存在する場合、ORACLE_SIDでこの既存のデータベースを指定します。
既存のデータベースがWindows上にある場合、ORADIMを使用してDBを再作成する必要があります。

関連項目:
Windows上のOracleサービスの詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

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

9. catalog.sqlおよびcatproc.sqlスクリプトを実行して、すべてのEnterprise Editionオブジェクトが作成されていることを確認します。

データベースがOracle Database Enterprise Editionに変換されました。データベースをOracle Database 12cにアップグレードする準備ができました。第2章「Oracle Databaseのアップグレードの準備」に進み、アップグレード処理を継続します。

関連項目:
My Oracle Support (http://support.oracle.com)のNote ID 117048.1「How to Convert Oracle Database from Standard to Enterprise Edition」

1.12 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を使用したデータの移行」

1.13 Oracle Database Express Edition (Oracle Database XE)からOracle Databaseへの移行

Oracle Database Express Edition (Oracle Database XE)はOracle Databaseのエントリレベルのエディションで、ダウンロードがすばやく、インストールおよび管理が簡単です。Oracle Database XEは、開発、デプロイおよび配布用に一定のライセンス制限付きで無料で提供されています。Oracle Database XEでは、コストのかかる複雑な移行をすることなく、Oracleの他のエディションへのアップグレードを容易にします。Oracle Database XEは、任意の数のCPUを持つ任意のサイズのコンピュータに対して、コンピュータに1つのデータベースをインストールできます。サポートは、Oracle従業員およびコミュニティの専門家によって監視される無料のOracleオンライン・フォーラムで提供されます。

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

1. リリース11202のOracle Database XEをrootユーザーでインストールします。

/u01/app/oracle/product/11.2.0/xe

2. SQL Plusを起動し、次の手順を実行して、前提条件チェックの警告を回避し、DBUAの対話形式のフェーズ中にデータベースのアップグレードを確実に成功するようにします。

Set ORACLE_HOME
Set ORACLE_SID
SQL> alter system set job_queue_processes=64;
SQL> alter database datafile '/u01/app/oracle/oradata/XE/system.dbf'
autoextend on next 640k maxsize unlimited;

3. リリース11.2.0.2のOracle Database XEホームで、アップグレード前に、rootユーザーとして次のディレクトリ、サブディレクトリおよびファイルに777個の権限を付与します。

cd /u01/app/oracle
$ls
admin diag fast_recovery_area oradata product

adminディレクトリの場合、次のディレクトリおよびファイルに777個の権限を付与します。

chmod 777 admin
cd admin
chmod 777 XE
chmod 777 *
$ls
adump  dbs  dpdump  pfile

cd dpdump
chmod 777 dp.log

cd ..
cd adump
chmod 777 * ( Change permissions of *.aud)

diagディレクトリの場合、次のように777個の権限を付与します。これはOracleホームから実行し、diagに移動します。

cd diag
chmod -R 777 *

fast_recovery_areaディレクトリの場合、次のディレクトリおよびファイルに777個の権限を付与します。fast_recovery_areaフォルダはOracleホームの下にあります。最初にOracleホームに戻ってから、次のコマンドを実行します。

chmod 777 fast_recovery_area
cd fast_recovery_area
chmod 777 XE
cd XE
chmod 777 onlinelog

oradataの場合、次のディレクトリに777個の権限を付与します。oradataフォルダはOracleホームの下にあります。最初にOracleホームに戻ってから、次のコマンドを実行します。

chmod -R 777 oradata

Oracle productディレクトリの場合、次のディレクトリおよびファイルに777個の権限を付与します。

chmod 777 11.2.0
cd 11.2.0
chmod 777 xe
cd xe
chmod 777 dbs
cd dbs
chmod 777 * ( changes permissions of these files hc_XE.dat  init.ora  lkXE
@ orapwXE  spfileXE.ora)

4. Oracle Database 12cをインストールしたディレクトリの下に、データベースのアップグレード時にログ・ファイルが書き込まれるログ・ディレクトリ(例: /scratch/logdir。logdirに777個の権限を付与)を作成します。
また、バックアップ・ファイルが格納されるバックアップ・フォルダ(例: /scratch/backup。backupフォルダに777個の権限を付与)も作成します。

5. 次のパラメータを使用してDBUAを起動します。DBUAの実行の詳細は、「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」を参照してください。

./dbua -logDir /scratch/logdir -backupLocation /scratch/backup

既存のリスナーはrootユーザーによって作成されていてアップグレードで使用できないため、プロンプトが表示されたら、新しい名前およびポートの新しいリスナーを作成します。

6. DBUAの対話形式のフェーズ中に必要な入力値を指定し、完了したら、「終了」をクリックします。

関連項目:

- ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』

- Oracleオンライン・フォーラム(http://forums.oracle.com)の「Oracle Database Express Edition (XE)」

- 第3章「Oracle Databaseのアップグレードの概要」

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

Oracle Databaseをアップグレードする前に、要件および推奨事項を理解する必要があります。この章では、アップグレードに備えて新しいOracleソフトウェアをインストールするなどのアップグレード前の作業に関する情報および手順について説明しています。

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

- Oracle Databaseのアップグレードを準備するための作業

- Oracle Databaseをアップグレードする場合の要件

- 新しいOracle Databaseソフトウェアのインストール

- Oracle Databaseをアップグレードする場合のパッチ・セットの更新および要件

- Oracle Databaseのアップグレード前情報ツールの概要

- アップグレードのためのOracle Databaseのバックアップ

- アップグレードのための新しいOracleホームの準備

- Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項

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

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

関連項目:
「Oracle Databaseのアップグレード・ツールおよびアップグレード処理の概要」

2.1 Oracle Databaseのアップグレードを準備するための作業

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

データベースのアップグレードの準備をするために、次の作業を実行します。

- Oracle Databaseの新機能の理解

- Oracle Databaseのアップグレード・パスの決定

- Oracle Databaseのアップグレード方法の選択

- アップグレード時のOracleホームの新しい場所の選択

- Oracle Databaseのアップグレードでのテスト計画の開発

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

2.1.1 Oracle Databaseの新機能の理解

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

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

関連項目:
『Oracle Database新機能ガイド』および「新機能」

2.1.2 Oracle Databaseのアップグレード・パスの決定

Oracle Database 12cの最新リリースにアップグレードするために必要なパスは、現行のデータベースのリリース番号によって異なります。現行のOracle Databaseがリリース10.2.0.5、11.1.0.7または11.2.0.2以上の場合、新しいリリースへの直接のアップグレードを実行できます。リリース12.1.0.1から12.1.0.2へは直接アップグレードできます。

現行のOracle Databaseが10.2.0.5より前のリリースまたはリリース11.2.0.1の場合は、Oracle Databaseの現行のリリースから最新リリースへの直接のアップグレードはサポートされていません。この場合、Oracle Database 12cにアップグレードする前に、中間リリースにアップグレードする必要があります。

たとえば、アップグレード元となるデータベースでOracle Database 9iを実行している場合は、次の手順に従います。

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

2. 『Oracle Databaseアップグレード・ガイド』(このマニュアル)の指示に従って、Oracle Database 10g リリース2 (10.2.0.5)を新しいOracle Database 12cへ直接アップグレードします。

表2-1に、Oracle Databaseのリリースごとに必要なアップグレード・パスを示します。Oracle Database 12cに完全にアップグレードする前に、ご使用のデータベースのアップグレード・パスおよび指定されたドキュメントを使用して中間アップグレードを実行します。

表2-1 Oracle Database 12cのアップグレード・パスの例

現行リリース

ダイレクトまたは中間アップグレード・パス

12.1.0.1、11.2.0.2以上

11.1.0.7

10.2.0.5

直接のアップグレードがサポートされています。現行の『Oracle Databaseアップグレード・ガイド』(このマニュアル)を使用してアップグレードを実行します。

11.2.0.1

11.1.0.6

10.2.0.2、10.2.0.3および10.2.0.4

10.1.0.5

9.2.0.8以下

Oracle Database 12cへの直接のアップグレードはサポートされていません。

解決策: 新しいOracle Database 12cへアップグレードする前に、(リリース12.1に直接アップグレード可能な) Oracle Databaseの中間リリースにアップグレードします。これには、Oracle Data Pumpのエクスポート/インポートを使用したアップグレードは含まれません。Oracle Databaseの中間リリースのドキュメントの指示に従って、中間リリースへアップグレードします。次に、第3章「Oracle Databaseのアップグレード」の指示に従って、中間リリースのデータベースを新しいOracle Database 12cリリースにアップグレードします。

次に例を示します。

- 11.2.0.1または11.1.0.6からアップグレードする場合は、先にOracle Database 11g Release 2 (11.2.0.2)にアップグレードする必要があります。

- 10.2.0.2、10.2.0.3、10.2.0.4または10.1.0.5からアップグレードする場合は、先に10.2.0.5以上にアップグレードする必要があります。

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

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

2.1.3 Oracle Databaseのアップグレード方法の選択

データベースのアップグレードには、最良の方法としてDatabase Upgrade Assistant (DBUA)を使用することをお薦めします。ただし、企業の複雑さを支えるご使用のデータベースを完全にアップグレードするための様々な方法が提供されています。データのアップグレードと移行の違いに関する定義および説明は、「Oracle Databaseのアップグレード・ツールおよびアップグレード処理の概要」を参照してください。

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

- Oracle Databaseのアップグレードを自動化(DBUA)する方法

- 手動、コマンドラインでOracle Databaseをアップグレードする方法

- Oracle Databaseのアップグレード時のデータの移行でエクスポート/インポートする方法

2.1.3.1 Oracle Databaseのアップグレードを自動化(DBUA)する方法

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

Oracle Real Application Clusters (Oracle RAC)環境では、DBUAは、すべてのデータベースをアップグレードするわけではありません。DBUAは、クラスタ内のすべてのノードにあるすべてのデータベース・ファイルおよび構成ファイルをアップグレードします。

2.1.3.2 手動、コマンドラインでOracle Databaseをアップグレードする方法

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

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

2.1.3.2.1 アップグレード前

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

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

関連項目:
「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」

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

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

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

アップグレードしているデータベースのリリースに応じて、追加のアップグレード前の手順(アップグレードに向けたパラメータ・ファイルの調整、サポートが終了した初期化パラメータの削除およびアップグレードの問題が発生する可能性のある初期化パラメータの調整)が必要な場合があります。

2.1.3.2.2 アップグレード後

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

関連項目:
「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」

2.1.3.3 Oracle Databaseのアップグレード時のデータの移行でエクスポート/インポートする方法

DBUAまたは手動のコマンドライン・アップグレードとは異なり、Oracle Data Pump ExportおよびImportユーティリティは、現行のデータベースのデータのコピーを新しいリリースの新しいデータベースに物理的に移行します。データ・ポンプ・エクスポートおよびインポートは、パフォーマンスの向上と新しいデータ型の確実なサポートの点で推奨されています。

エクスポート・ダンプ・ファイルの内容をロードする前に、新しいデータベースが存在している必要があるか、新しいOracleホームにデータベースが作成されている必要があります。

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

注意:

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

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

2.1.3.3.1 アップグレードしたOracle Databaseでのエクスポート/インポートの影響

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

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

2.1.3.3.2 Oracle Databaseのデータ移行でのエクスポート/インポートの利点

Oracle Databaseのアップグレード時のエクスポート/インポートを使用したデータ移行では、パフォーマンスを向上するためのデータベースの圧縮および再構築といった利点があります。

エクスポート/インポートを使用したデータの移行:

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

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

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

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

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

- アップグレードするデータベースをサポートしていないオペレーティング・システムまたはハードウェア・プラットフォーム上に、アップグレードしたデータベースを確立できます。

- ネットワーク・ベースのデータ・ポンプ・インポートにより、新規Oracle Databaseは、アップグレード対象の古いデータベースからネットワークを介して直接ロードできます。したがって、ダンプ・ファイルが介在する必要はありません。

2.1.3.3.3 エクスポート/インポートを使用したデータ移行およびアップグレードの時間要件

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

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

2.1.4 アップグレード時のOracleホームの新しい場所の選択

新しいリリースのOracle Databaseに、現行のリリースのOracleホームとは別のOracleホームの場所を選択する必要があります。新しいソフトウェアを現行のリリースと同じOracleホームの場所にインストールすることはできません。

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

2.1.5 Oracle Databaseのアップグレードでのテスト計画の開発

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

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

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

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

- 最小テスト

- 機能テスト

- 高可用性テスト

- 統合テスト

- パフォーマンス・テスト

- Oracle Databaseのアップグレードでのボリューム/ロード・ストレス・テスト

2.1.5.1 アップグレード・テスト

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

2.1.5.2 最小テスト

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

2.1.5.3 機能テスト

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

2.1.5.4 高可用性テスト

Oracle Databaseの高可用性テストでは、アップグレードしたシステムが、Recovery Time Objective (RTO)およびRecovery Point Objective (RPO)のビジネス要件を満たしていることを確認します。

- Oracle RAC環境では、ストレス・テスト中にノードまたはインスタンスの挿入に失敗した場合、この事実からOracle RACのリカバリ可能性が変化したかどうかを評価することができます。

- 停止時間を最小化するために、フォールバック計画および手順をテストすることをお薦めします。

- 割り当てた時間内にアップグレード処理が実行されるように、データベースのパフォーマンスおよび安定性を確認し、パフォーマンスの問題を解決することをお薦めします。

関連項目:
My Oracle Support(http://support.oracle.com/)のNote 1462240.1「Upgrade Companion」

2.1.5.5 統合テスト

Oracle Databaseの統合テストでは、システムのコンポーネント間で相互作用をテストします。

統合テストを計画するときは、次のことを考慮する必要があります。

- Oracle Database 12cのインスタンスで稼働するPro*C/C++アプリケーションは、新しいソフトウェアで問題がないことを確認するためにテストする必要があります。Pro*C/C++アプリケーションの詳細は、『Pro*C/C++プログラマーズ・ガイド』を参照してください。

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

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

- 2つのコンポーネントがOracle NetまたはOracle Net Servicesを使用して接続されている場合は、ストレス・テストとともにその接続のテストも行う必要があります。Oracle Net Servicesのアップグレードに関する推奨事項については、『Oracle Database Net Servicesリファレンス』を参照してください。

2.1.5.6 パフォーマンス・テスト

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

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

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

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

- SQL計画管理

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

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

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

関連項目:

- ワークロードの取得およびリプレイ方法の詳細は、『Oracle Database Testingガイド』を参照してください。

- 自動ワークロード・リポジトリの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

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

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

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

2.1.5.6.3 SQL計画管理

新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、通常、SQL文に対して若干の計画変更がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。SQL計画管理は、一定期間におけるSQL文の実行計画を記録および評価する予防的メカニズムであり、効率的であることが確認されている既存の計画で構成されたSQL計画のベースラインを構築します。SQL計画のベースラインは、システムで発生している変更に関係なく、対応するSQL文のパフォーマンスを保持するために使用されます。

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

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

- カーソル・キャッシュからのSQL管理ベースのバルク・ロード

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

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

カーソル・キャッシュからのSQL管理ベースのバルク・ロード

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

1. Oracle Databaseのソース・リリースでは、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはOracle Enterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。

2. データベースをアップグレードします。

関連項目:
共有SQL領域からPL/SQLまたはOracle Enterprise Managerを使用して計画をロードする方法の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

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

実行計画またはSQL計画のベースラインのバルク・ロードは、SQLチューニング・セットを使用して実行できる場合があります。これは、カーソル・キャッシュから直接ロードするため、または自動ワークロード・リポジトリから履歴計画をロードするためのSQL Management Base (SMB)がないOracle Database 10gからアップグレードを行う場合に役立ちます。

1. Oracle Databaseのソース・リリースで、各SQL文の実行計画を含むSTSを作成します。

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

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

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

関連項目:
実行計画またはSQL計画のベースラインのバルク・ロードの詳細な手順は、『Oracle Database SQLチューニング・ガイド』を参照してください。

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

すべての重要なSQL問合せをOracle Databaseのテスト環境でテストおよびチューニングしてから、そのSQL実行計画をOracle Databaseの本番環境に移動できます。または、アップグレード前Oracle Databaseの本番環境からSQL問合せの計画を実行してから、アップグレード後の本番環境にそれらを移動できます。

1. Oracle Database 12cのテスト・システムで、すべてのテストとチューニングを完了してから、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計画ベースラインを展開します。

関連項目:

- ステージング表からの計画のロードの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

- データ・ポンプの使用については、『Oracle Databaseユーティリティ』を参照してください。

2.1.5.7 Oracle Databaseのアップグレードでのボリューム/ロード・ストレス・テスト

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

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

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

関連項目:
ストレス・テストでのデータベース・リプレイの使用の詳細は、『Oracle Database Testingガイド』を参照してください。

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

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

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

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

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

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

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

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

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

ヒント:
RMANを使用したバックアップ計画の実装の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.2 Oracle Databaseをアップグレードする場合の要件

オペレーティング・システムおよびデータベース環境のOracleコンポーネントに応じた、注意する固有の情報および要件があります。

次の各項目では、アップグレードの実行に関するシステムの推奨事項および要件について説明します。

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

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

- Oracle Enterprise Manager Database Controlの構成およびデータの保存

- emremove.sqlを使用したDB Controlの手動による削除

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

- Oracle Grid InfrastructureおよびOracle Clusterwareのアップグレードの概要

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

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

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

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

- Oracle GoldenGateおよびオンライン・データベース・アップグレードの概要

- Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件

- Oracle OLAPデータ・セキュリティ・ポリシーのアップグレードの概要

- Oracle Label SecurityおよびOracle Database Vaultを使用しているデータベースのアップグレードの要件

- Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件

- 統合監査スキーマおよびロールの削除

関連項目:

- Oracle Net Servicesのアップグレードに関する推奨事項については、『Oracle Database Net Servicesリファレンス』を参照してください。

- ご使用のオペレーティング・システム固有のアップグレードの準備の詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください。

- ローリング・アップグレードの詳細は、「Oracle ASMおよびOracle RACデータベースのローリング・アップグレードの概要」を参照してください。

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

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

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

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

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

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

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

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

2.2.3 Oracle Enterprise Manager Database Controlの構成およびデータの保存

新しいリリースにアップグレード後にダウングレードしてOracle Enterprise Manager Database Control (DB Control)をリストアできるようにする必要がある場合は、データベースをアップグレードする前に、構成ファイルおよびデータを保存する必要があります。Oracle Database 12c以上では、アップグレード処理の一部としてDB Controlは削除されます。データベースをアップグレードする前にDB Controlの制御ファイルとデータのコピーを保存するためのemdwgrdユーティリティが提供されています。これは、ダウングレードできるようにし、以前のデータベースからDB Controlの構成ファイルをリストアする場合に必要です。

emdwgrdユーティリティは、新しいOracle Database 12cリリースのORACLE_HOME/binディレクトリにあります。emdwgrdユーティリティは、LinuxとUNIX用のemdwgrdとemdwgrd.plおよびWindows用のemdwgrd.batとemdwgrd.plで構成されています。ユーティリティを実行する前に、Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームからスクリプトを起動する必要があります。emdwgrdユーティリティでは、ORACLE_HOMEがアップグレード対象のリリースのOracleホームに設定されている必要があります。

emdwgrdを使用してDB Controlのファイルとデータを保存するには、次の手順を実行します。

1. 新しいOracle Database 12cリリースのソフトウェアをインストールします。

関連項目:
「新しいOracle Databaseソフトウェアのインストール」

2. ORACLE_HOMEを古いOracleホームに設定します。

3. ORACLE_SIDを、アップグレードするデータベースのSIDに設定します。

4. PATH、LD_LIBRARY_PATHおよびSHLIB_PATHが、アップグレードするデータベースのOracleホームを指すように設定します。

5. 新しいOracle Database 12cリリースのOracleホームに移動します。

6. 次のように、emdwgrdを実行します。

- 単一インスタンスのデータベースの場合は、次のコマンドを実行します。このとき、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

次に、emdwgrdを次のように実行します。

emdwgrd -save -cluster -sid old_SID -path save_directory

Oracleホームが共有デバイス上にある場合は、前述のコマンドラインに-sharedを追加します。

7. アップグレードするデータベースのSYSパスワードを入力します。

注意:
データベースをアップグレードした後に、DBUAバックアップおよびリストア処理を使用して、以前のOracle Enterprise Manager Database Control環境に戻すことも可能です。ただし、アップグレードしてからリストアするまでの間に蓄積されたユーザー・データは、すべて失われます。データベースの制御ファイルおよびデータを保存しておくことで、データベースとDB Controlの両方をダウングレードできます。アップグレードしてからダウングレードするまでの間に蓄積されたDB Controlのデータはすべて失われますが、すべてのユーザー・データが保持されます。

2.2.4 emremove.sqlを使用したDB Controlの手動による削除

アップグレード処理中の停止時間を最小化するには、アップグレード前準備の一部として、オプションでemremove.sqlスクリプトを実行できます。emremove.sqlスクリプトは、Oracle Enterprise Manager関連のスキーマおよびオブジェクトを削除します。このスクリプトは、処理の完了までに6つのフェーズがあるため、完了に数分かかる場合があります。このスクリプトは、SYSMANがあり、関連するセッションがSQL*Plus、Oracle Enterprise Managerまたはその他のクライアントからアクティブの場合に、さらに長くかかる場合があります。

重要:
ダウングレードおよびDB Controlをリストアする場合は、「Oracle Enterprise Manager Database Controlの構成およびデータの保存」に従って、DB Controlの構成およびデータをバックアップする必要があります。

DB Controlを手動で削除するためにemremove.sqlを実行するには、次の手順を行います。

1. DB Controlアプリケーションをただちに停止します。

$ emctl stop dbconsole

2. SQL*Plusを起動し、SYSDBAとしてSYSアカウントを使用してデータベースに接続します。

3. オプションの手順です。このスクリプトをサイレント・モードで実行する場合は、これを設定しないでください。実行中のemremove.sqlの進行状況を確認するには、次の変数を設定します。

SET ECHO ON;
SET SERVEROUTPUT ON;

4. emremove.sqlを実行します。このスクリプトは、新しいOracle Database 12cのOracleホームのORACLE_HOME/rdbms/admin/にあります。

$ @emremove.sql

5. emremove.sqlの完了後、ファイル・システムからORACLE_HOME/HOSTNAME_SIDディレクトリおよびORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SIDディレクトリを手動で削除する必要があります。

注意:
DB Controlがリリース10.2.0.3から10.2.0.4にアップグレードされた場合は、次のディレクトリもファイル・システムから削除する必要があります。
ORACLE_HOME/HOSTNAME_SID.upgrade

ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SID.upgrade

6. Windowsプラットフォームでは、通常、OracleDBConsoleSIDという名前のDatabase Consoleサービスも削除します。

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

Oracle Grid InfrastructureのOracle Universal Installer (OUI)を使用してOracle ASMインスタンスをアップグレードすることをお薦めします。OUIは、以前のリリース・レベルのOracle ASMインスタンスを検出すると、自動的にアップグレード・モードに切り替わります。Oracle Database 11g以上を実行している環境では、クラスタ化されたOracle ASMインスタンスに対してローリング・アップグレードを実行することもできます。Oracle ASMのローリング・アップグレードの実行手順の詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

関連項目:
Oracle ClusterwareまたはOracle Automatic Storage Managementのローリング・アップグレードの詳細は、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

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

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

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

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

2.2.6 Oracle Grid InfrastructureおよびOracle Clusterwareのアップグレードの概要

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

関連項目:
Oracle ClusterwareおよびOracle Automatic Storage Managementのアップグレードの実行方法の詳細は、オペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』および付録を参照してください

Oracle Clusterware、Oracle Grid InfrastructureおよびOracle ASMインスタンスのアップグレードに関する推奨事項を次に示します。

- Oracle Databaseをアップグレードするには、Oracle Grid Infrastructureソフトウェアを新しいGridホームに、およびOracle Database 12cソフトウェアを新しいOracleホームにインストールする必要があります。これは、スタンドアロン・サーバー(Oracle Restart)用のOracle Grid Infrastructureにも適用されます。サポートされているリリースからのみアップグレードできます。「Oracle Databaseのアップグレード・パスの決定」を参照してください。

- Windows x64プラットフォームで、Oracle Clusterwareをリリース10.2.0.5および11.1.0.7からリリース12.1にアップグレードするには、Oracle Clusterwareで11.2.0.3への個別アップグレードを実行する必要があります。Oracle Clusterwareのリリース11.2.0.3へのアップグレード後に、Oracle Cluster Registry (OCR)および投票ファイル(VDSK)をOracle ASMに移動する必要があります。その後、Oracle Clusterwareをリリース11.2.0.3からリリース12.1にアップグレードできます。

- WindowsまたはRAWデバイスのOCFSにOracle Clusterwareファイルを格納するOracle Databaseリリース10.2.0.5またはリリース11.1.0.7環境をアップグレードする場合、Oracle Database 12cへ直接アップグレードすることはできません。「Oracle Databaseリリース10.2または11.1およびOCFSとRAWデバイスのアップグレードの概要」を参照してください。

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

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

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

ORACLE_HOME/bin/localconfig delete

- Oracle Clusterwareのアップグレード時に、OUIによってOracle ASM Configuration Assistant (ASMCA)が自動的にコールされ、Oracle Grid Infrastructureホームへのアップグレードが実行されます。Grid Infrastructureホームは、各ノードに対してローカルにできます。

- 単一インスタンス構成では、Oracle ASMおよびOracle Restartは、Oracle Grid Infrastructureホームから実行されます。このため、Oracle ASMおよびOracle Restartは、Oracle Grid Infrastructure 12cに同時にアップグレードされます。

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

関連項目:
ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』

2.2.6.1 アップグレード時にローカル・ノード上で実行している必要のあるOracle Clusterware

Oracle Database 12c以上では、Oracle Real Application Clustersの非ローリング・アップグレードで、ローカル・ノード上のOracle Clusterwareが起動および稼働している必要があります。ローカル・ノード上のOracle Clusterwareスタックは稼働している必要があります。

Oracle Databaseの以前のリリースでは、クラスタの非ローリングは、アップグレード処理の開始前に、OUIによってすべてのスタック停止で、ISROLLINGがfalseに設定されていることを意味します。クラスタ・ノードのいずれかが起動していた場合は、ISROLLLINGはtrueに設定されました。ただし、Oracle Database 12cでは、ローリングは、アップグレード前にローカル・スタックが起動していて、その他のスタックは停止している必要があるという意味です。この状況においてのみ、OUIによってISROLLINGがfalseに設定されます。

ローカル・ノード上のOracle Clusterwareを起動するには、次の手順を実行します。

1. Oracle Clusterwareスタックが稼働しているノード上でOUIインストーラを実行するか、端末を開きます。

2. rootまたは管理者としてログインします。

3. Oracle Clusterwareホーム(Gridホーム)にディレクトリを変更(cd)し、次のコマンドを入力してOracle Clusterwareを起動します。

# crsctl start crs

2.2.6.2 DBUAを使用したOracle Real Application Clusters (Oracle RAC)データベースのアップグレードの概要

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

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

関連項目:
ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』

2.2.6.3 アップグレードとアクセス不可能ノードの概要

『Oracle Grid Infrastructureインストレーション・ガイド』のアップグレードの付録で説明する強制クラスタ・アップグレード・コマンドを使用する場合、この項の情報を適用します。

Oracle Database 12c以上では、アクセス不可能ノードの削除(以前のリリースでは必要)の代替手段として、アクセス不可能ノードを追加するオプションがあります。このノードに新しいOracle Database 12cソフトウェアをインストールしておく必要があります。

アクセス不可能ノードまたは到達不可能ノードで、次のコマンドを実行すると、このノードをアップグレードし、クラスタに追加することができます。

rootcrs.pl -join -existingNode upgraded_node

このコマンドのupgraded_node変数は、すでにアップグレードされているクラスタ内のノードの1つを参照します。-existingNode引数は、アップグレードされたノードを指定する必要があります。

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

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

時間の同期には2つの方法があります。

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

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

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

2.2.6.5 ASMを使用するOracle RACおよびOracle Databaseのアップグレードに関する推奨事項

Oracle ASMは、Oracle Grid Infrastructureコンポーネントのインストール時にインストールされます。Oracle ASMは、Oracle RACとともにクラスタにインストールされた場合はOracle Clusterwareと、スタンドアロン・サーバーにインストールされた場合はOracle RestartとOracleホームを共有します。新しいOracle Databaseのソフトウェアがシステム上にインストールされる前に、Oracle Grid InfrastructureをアップグレードするためのrootスクリプトによってOracle ASM Configuration Assistant (ASMCA)が起動され、Oracle ASMが新しいリリースにアップグレードされます。

既存のOracle ASMインスタンスがある場合は、Oracle Grid Infrastructureをインストールするとき、またはインストール後にASMCAを使用してアップグレードできます。Oracle Database 12cの新しいソフトウェアのインストール時に、クラスタが検出されると、Oracle Universal Installer (OUI)によってスクリプトroot.shが実行されます。OUIでは、クラスタのノード上でrootスクリプトの実行作業を自動化するためのオプションが提供されています。OUIによるroot.shスクリプトの自動的な実行を可能にするための情報およびパスワードの入力が求められます。今後は、クラスタのノード上でroot.shスクリプトの実行作業を自動化するためのオプションが使用できます。

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

Oracle Automatic Storage Management (Oracle ASM)環境では、共有ASMパスワード・ファイルを作成できます。パスワード・ファイルは、ORAPWDユーティリティによって作成されます。ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。SYSASM権限を使用して、データベース管理の職責とストレージ管理の職責を分離することをお薦めします。さらに、Oracle ASMおよび各データベースに対して異なるオペレーティング・システム資格証明を作成することもできるようになっています。これにより、データベース管理の職責とストレージ管理の職責をさらに厳重に分離することが可能になります。たとえば、あるノード上のOracle ASMを使用しているデータベースがn個ある場合、SYS権限を持つメンバーのオペレーティング・システム資格証明グループをn+1セット構成できます(つまり、各データベース用のSYSDBA権限を持つOSDBAグループが1つずつと、Oracle ASMインスタンス用のSYSASM権限を持つOSASMグループが1つです)。

関連項目:
Oracle ASMのシステム認証の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

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

Oracle Databaseでは以前のリリースで作成されたファイル・ヘッダーを読み取ることができるため、アップグレード時にそれらに対して処理を行う必要はありません。アップグレード中に、表領域がスキーマ・ベースの表領域(SYSAUX、SYSTEM、XDB、HTMLDB、CTXSYSなど)でないかぎり、表領域を読取り専用またはオフライン・モードに設定します(それ以外の場合、アップグレードに失敗します)。オフラインのデータ・ファイルのファイル・ヘッダーは、後でオンラインにしたときに更新され、読取り専用の表領域のファイル・ヘッダーは、読取り/書込みに変更されたときに更新されます。

まれに、キュー表がアップグレード用に読取り専用に設定された表領域に存在する場合、その表領域を読取り/書込みに設定しなおす必要があります。これらのキュー・オブジェクトの再作成は、アップグレード後に再度試行できます。

関連項目:
データベース間での表領域の転送の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

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 Data Guard SQL Applyを使用して、新しいOracle Databaseリリースへのローリング・アップグレードを実行できます。ロジカル・スタンバイでは、アップグレードの進行中のアーカイブ・ログを受け入れます。スタンバイ・データベースがアップグレード・モードでオープンされている間にプライマリ・データベースのREDOを継続して受信するために、アップグレードのターゲットであるスタンバイ・データベースを有効化することによって、Data Guardデータベースのローリング・アップグレード処理中にデータ保護が維持されます。SQL Applyを使用したローリング・アップグレードによって、追加の障害保護が提供されます。

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

- Oracle Database 12cでのActive Data Guardを使用したローリング・アップグレード
Oracle Database 12cではDBMS_ROLLING PL/SQLパッケージが提供され、これにより、Data Guard構成のデータベース・ソフトウェアのローリング方式でのアップグレードが可能です。Active Data Guardを使用したローリング・アップグレードでは、Data Guardのフィジカル・スタンバイ・データベースおよびSQL Applyプロセスを使用します。これは、Oracle Databaseリリース12.1以上のローリング・アップグレードでサポートされます。DBMS_ROLLINGを使用したローリング・アップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。

注意:
Oracle Database 12c以上では、Oracle Enterprise Manager Cloud Controlで、Data Guard構成のデータベースのローリング・アップグレードを実行するためのオプションが提供されています。手順は、Cloud Control内のオンライン・ヘルプに記載されています。

関連項目:

- Oracle Data Guard Broker構成におけるアップグレードおよびダウングレードの詳細は、『Oracle Data Guard Broker』を参照してください。

- スタンバイ・データベースを使用したアップグレードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

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

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

関連項目:

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

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

2.2.10 異なるオペレーティング・システムへのデータの転送

DBUAを使用している場合またはOracle Databaseを手動でアップグレードしている場合は、オペレーティング・システム間でデータベースのデータは直接、移行または転送できません。たとえば、DBUAを使用して、Solaris上のOracle DatabaseのデータをWindows上のOracle 12cデータベースには移行できません。使用しているオペレーティング・システム・プラットフォーム固有の手順に従う必要があります。プラットフォーム間のデータの転送については、『Oracle Database管理者ガイド』を参照してください。

プラットフォーム間でのデータの転送がサポートされているプラットフォームを確認するには、SQL*Plusを使用して次の問合せを実行します。

SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME;

注意:
ソース・プラットフォームとターゲット・プラットフォームでエンディアンが異なる場合、RMAN CONVERT DATABASEは使用できません。この処理では、ソースとターゲット・プラットフォームの両方が同じエンディアン値である必要があります。使用可能なオプションは、データ・ポンプ・レプリケーション、データ・ポンプ・エクスポート/インポートまたはトランスポータブル表領域、とRMAN CONVERT TABLESPACEの使用です。プラットフォームでエンディアンが同じ場合は、変換は必要なく、データは同じプラットフォーム上にある場合と同様に転送できます。

関連項目:

- プラットフォーム間でのデータの転送の詳細は、『Oracle Database管理者ガイド』を参照してください。

- RMAN CONVERT DATABASEコマンドおよびRMAN CONVERT TABLESPACEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- 第7章「Oracle Data Pumpを使用したデータの移行」

2.2.11 Oracle GoldenGateおよびオンライン・データベース・アップグレードの概要

Oracle GoldenGateレプリケーション環境では、オンライン・データベース・アップグレードを実行して、最新のOracle Databaseのリリースにアップグレードできます。Oracle GoldenGateレプリケーション環境を使用すると、アップグレード時の停止時間が最小化されます。Oracle GoldenGateはプラットフォームの移行に加えて、アプリケーションおよびデータベースのアップグレードなどの、計画メンテナンス中の停止時間を最小化するための優れた方法です。Oracle GoldenGateはOracleおよびサード・パーティのデータベース管理システム用のOracle Databaseとは別に販売されているOracle製品です。

関連項目:
詳細はOracle GoldenGateドキュメントを参照してください。

2.2.11.1 Oracle GoldenGateを使用したOracle Databaseのアップグレード手順の概要

Oracle GoldenGateを使用したOracle Database 12cへのアップグレードは、次の高度な手順で構成されています。特に指定がないかぎり、手順は、Oracle GoldenGateのドキュメント・ライブラリを参照してください。

1. 以前のリリースのデータベース・ソフトウェアを実行中のスタンバイ・データべースを、既存のデータベースのバックアップを使用して設定します。

2. スタンバイ・データベースをOracle Database 12cにアップグレードします。「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」を参照してください。

3. スタンバイ・データベースを本番データベースと同期化します。

4. アクティブ・モードまたはライブ・モードで環境をテストします。

5. アプリケーションをスタンバイ・データベースに切り替えます。

6. スタンバイ・データベースでアプリケーションの包括的なテストを行った後で、プライマリ・データベースをOracle Database 12cにアップグレードします。データベースのアップグレードのテストの詳細は、『Oracle Database Testingガイド』を参照してください。テストの後、第3章「Oracle Databaseのアップグレード」を参照してください。

2.2.12 Oracle OLAPデータ・セキュリティ・ポリシーのアップグレードの概要

Oracle Database 12cでは、Oracle OLAPは、Oracle Database 11gリリースで使用されていたExtensible Data Security (XDS)のかわりに、Oracle Real Application Security (ORAS)を使用して、OLAPデータ・セキュリティ・ポリシーを格納します。Oracle Databaseをリリース11gからリリース12cにアップグレードする場合、XDSデータ・セキュリティ・ポリシーはすべて自動的にORASに変換されます。

注意:
リリース11gのOracle Databaseインスタンスで定義されたデータ・セキュリティ・ロールは、自動的にORASに変換されません。11gデータベースをOracle Database 12cにアップグレードする前に、11gデータベースで定義されたすべてのデータ・セキュリティ・ロールを削除する必要があります。アップグレード後に、Analytic Workspace Manager 12cを使用して、再度データ・セキュリティ・ロールを定義できます。
11gデータ・セキュリティ・ロールを削除せずに、11gデータベースをOracle Database 12cにアップグレードする場合、データ・セキュリティ・ロールを含むデータ・セキュリティ・ポリシーは、Oracle Database 12cデータベースで無効になります。

関連項目:
『Oracle OLAPユーザーズ・ガイド』

2.2.13 Oracle Label SecurityおよびOracle Database Vaultを使用しているデータベースのアップグレードの要件

Oracle Label Security (OLS)およびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする場合は、最初にOLS事前処理スクリプト(olspreupgrade.sql)を実行してaud$表のコンテンツを処理する必要があります。OLSアップグレードでは、aud$表が、SYSTEMスキーマからSYSスキーマに移動されます。olspreupgrade.sqlスクリプトは、この移動に必要な事前処理スクリプトです。

注意:

Oracle Label SecurityおよびOracle Database Vaultを使用するOracle Databaseリリース12.1より前のデータベースをアップグレードする前には、olspreupgrade.sqlスクリプトを実行する必要があります。Oracle Databaseリリース12.1にアップグレード後に、データベースのパッチまたはアップグレードをするためのOLS事前処理の手順を実行する必要はありません。

olspreupgrade.sqlスクリプトでは、SYSスキーマに一時表PREUPG_AUD$が作成され、SYSTEM.aud$レコードがSYS.PREUPG_AUD$に移動されます。安全性のため、olspreupgrade.sqlスクリプトを実行する前に、『Oracle Databaseセキュリティ・ガイド』の記載に従って、監査証跡をアーカイブすることをお薦めします。Oracle Label Securityがデータベースにインストールされていて、以前のリリースからアップグレードする場合は、アップグレードの前にOLS事前処理スクリプトを実行する必要があります。

この項には次のトピックが含まれます:

- Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件

- Oracle Databaseリリース11.1.0.7でのolspreupgrade.sqlの実行

- Oracle Databaseリリース10.2.0.5または11.2でのolspreupgrade.sqlの実行

関連項目:
OLS事前処理スクリプトの詳細は、Oracle Label Security管理者ガイドを参照してください。

2.2.13.1 Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件

Oracle Database Vaultを使用しているデータベースをアップグレードする前に、特定の要件、特にCDBのアップグレードについて、注意する必要があります。

- Oracle Databaseリリース11.2以前からOracle Database 12cにアップグレードするとき、現在のOracleホームでOracle Database Vaultを有効にしている場合は、新しいターゲットのOracleホームではOracle Database Vaultはデフォルトで無効化されます。

- Oracle Databaseリリース12.1.0.1からリリース12.1.0.2にアップグレードする場合、アップグレード処理を開始する前に、リリース12.1.0.1のOracleホームで、Oracle Database Vaultを手動で無効にする必要があります。

- CDBをアップグレードする場合、次の注意の記載に従って、DV所有者としてdvsys.dbms_macadm.disable_dvを実行する必要があります。

重要:

CDBrootおよびPDBでOracle Database Vaultを無効にするには、DV所有者として次のようにdvsys.dbms_macadm.disable_dvを実行します。

SQL> execute dvsys.dbms_macadm.disable_dv();

CDBを停止して再起動し、読取り/書込み状態でPDBを開きます。

アップグレードが完了したら、新しいOracleホームでOracle Database Vaultを再度有効にします。

関連項目:
Oracle Database Vaultを無効および有効にする手順は、『Oracle Database Vault管理者ガイド』を参照してください。

2.2.13.2 Oracle Databaseリリース11.1.0.7でのolspreupgrade.sqlの実行

アップグレード対象の以前のリリースにOracle Label Securityがインストールされている場合は、OLS事前処理olspreupgrade.sqlスクリプトを実行する必要があります。Oracle Database Vaultがリリース11.1.0.7データベースにインストールされていない場合は、この項の手順2、3、6および7をスキップできます。

アップグレード前にリリース11.1.0.7データベースでOLS事前処理スクリプトを実行するには、次の手順を実行します。

1. 新しくインストールしたOracleホームからアップグレードするデータベースのOracleホームにORACLE_HOME/rdbms/admin/olspreupgrade.sqlスクリプトをコピーします。

2. SQL*Plusを起動し、アップグレードするデータベースにDVOWNERで接続します。

3. 次の文を実行します。

SQL> EXEC dbms_macadm.add_auth_to_realm('Oracle Database Vault','SYS',NULL, 0);

4. システム・プロンプトで、次のように入力します。

CONNECT SYS AS SYSDBA

5. OLS事前処理スクリプトを実行します。

ORACLE_HOME/rdbms/admin/olspreupgrade.sql

OLS事前処理スクリプトの実行中も、データベース上でアプリケーションを継続して実行できます。

6. olspreupgrade.sqlの実行に成功したら、SQL*Plusを起動して、データベースにDVOWNERで接続します。

7. 次の文を実行します。

SQL> EXEC dbms_macadm.delete_auth_from_realm('Oracle Database Vault','SYS');

2.2.13.3 Oracle Databaseリリース10.2.0.5または11.2でのolspreupgrade.sqlの実行

アップグレード対象の以前のリリースにOracle Label Securityがインストールされている場合は、OLS事前処理olspreupgrade.sqlスクリプトを実行する必要があります。Oracle Database Vaultがリリース10.2.0.5または11.2データベースにインストールされていない場合は、この項の手順2、3、6および7をスキップできます。

アップグレード前にリリース10.2.0.5または11.2データベースでOLS事前処理スクリプトを実行するには、次の手順を実行します。

1. 新しくインストールしたOracleホームからアップグレードするデータベースのOracleホームにORACLE_HOME/rdbms/admin/olspreupgrade.sqlスクリプトをコピーします。

2. SQL*Plusを起動し、アップグレードするデータベースにDVOWNERで接続します。

3. 次の文を実行します。

SQL> GRANT DV_PATCH_ADMIN to SYS;

4. システム・プロンプトで、次のように入力します。

CONNECT SYS AS SYSDBA

5. OLS事前処理スクリプトを実行します。

ORACLE_HOME/rdbms/admin/olspreupgrade.sql

OLS事前処理スクリプトの実行中も、データベース上でアプリケーションを継続して実行できます。

6. olspreupgrade.sqlの実行に成功したら、SQL*Plusを起動して、データベースにDVOWNERで接続します。

7. 次の文を実行します。

SQL> REVOKE DV_PATCH_ADMIN from SYS;

2.2.14 Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件

OWBはOracle Database 12cのソフトウェアの一部としてインストールされず、以前のリリースに存在したOWBコンポーネントは、Oracle Databaseのアップグレード処理の一部としてアップグレードされません。ただし、Oracle Database 12cではOWBリリース11.2.0.3を使用できます。リリース11.2.0.3より前のOWBリリースは、Oracle Database 12cでは動作しません。

OWBのリリース11.2.0.3は、次の方法でOracle Database 12cで使用できます。

- 既存のスタンドアロンOWB 11.2.0.3インストールへのOracle Database 12cのアクセスの追加

- Oracle Databaseリリース11.2.0.3での既存のOWB 11.2.0.3インストールの機能の維持

- 可能な場合のスタンドアロンOWB 11.2.0.3インストールの使用

2.2.14.1 既存のスタンドアロンOWB 11.2.0.3インストールへのOracle Database 12cのアクセスの追加

OWB 11.2.0.3をOracle Database 12cとともに使用できるようにするパッチ更新が提供されています。既存のスタンドアロンOWB 11.2.0.3インストールがある場合、Oracle Database 12cでOWBにアクセスできるようにします。

Oracle Database 12cのアクセスを既存のスタンドアロンOWB 11.2.0.3インストールに追加するには、次の手順を実行します。

1. 実行中のOWBランタイム・サービス、ブラウザおよびName AddressサーバーからすべてのOWBアプリケーションを停止します。

2. Oracle Database 12cソフトウェアをインストールし、第3章「Oracle Databaseのアップグレード」に記載されているデータベースのアップグレード手順に従います。

3. OWB累積パッチ16568042をOWBリリース11.2.0.3インストールに適用します。(OWBに対するパッチは、Oracle Database 12cのインストールの前後どちらでも適用できます。)
このパッチを入手するには、My Oracle Support (http://support.oracle.com)にアクセスし、「Patches」をクリックしてパッチ・リクエスト番号16568042を検索してください。

4. パッチのREADME.txtファイルのインプレース移行手順に従います。

5. スタンドアロンのOracleホームからOWBリリース11.2.0.3の実行を継続します。

2.2.14.2 Oracle Databaseリリース11.2.0.3での既存のOWB 11.2.0.3インストールの機能の維持

スタンドアロンのインストールが使用可能でないプラットフォーム(Solaris、HP、AIXなど)上でOWBリリース11.2.0.3が稼働している場合は、Oracle Database 12cへの移行後にOracle Databaseリリース11.2.0.3ソフトウェアをインプレースで保持する必要があります。

Oracle Databaseリリース11.2.0.3と統合されたOWBを実行するには、次の手順を実行します。

1. 実行中のOWBランタイム・サービス、ブラウザおよびName AddressサーバーからすべてのOWBアプリケーションを停止します。

2. Oracle Database 12cソフトウェアをインストールし、第3章「Oracle Databaseのアップグレード」に記載されているデータベースのアップグレード手順に従います。

3. Oracle Database 12cのインストール後に、Oracle Databaseリリース11.2.0.3を削除しないでください。このOracleホームからOWBを実行します。

4. Oracle Databaseリリース11.2.0.3のOracleホームにパッチ16568042を適用します。これはOWBインストールにパッチを適用します。(OWBに対するパッチは、Oracle Database 12cのインストールの前後どちらでも適用できます。)
このパッチを入手するには、My Oracle Support (http://support.oracle.com)にアクセスし、「Patches」をクリックしてパッチ・リクエスト番号16568042を検索してください。

5. パッチのREADME.txtファイルのインプレース移行手順に従います。

6. 統合されたOracle Databaseリリース11.2.0.3のOracleホームからOWBを実行します。

2.2.14.3 可能な場合のスタンドアロンOWB 11.2.0.3インストールの使用

スタンドアロン・インストールが可能なプラットフォーム(LinuxおよびWindows)上でOWB 11.2.0.3が稼働している場合は、スタンドアロン・ソフトウェアをインストールして、Oracle Databaseリリース11.2.0.3ソフトウェアを削除できます。

OWBを統合されたインストールからスタンドアロン・インストールに変換するには、次の手順を実行します。

1. 実行中のOWBランタイム・サービス、ブラウザおよびName AddressサーバーからすべてのOWBアプリケーションを停止します。

2. OWBスタンドアロン・クライアントを自身のOWBホーム・ディレクトリにインストールします。

3. owb/bin/adminディレクトリ全体を、古いOWBインストールから新しいOWBインストールのowb/bin/adminディレクトリにコピーします。この手順によって、ファイルとサブディレクトリすべてが新しいOWBの場所にコピーされます。

4. Control Centerホーム値を再設定するために、OWBSYSユーザーとして次のSQL文を実行します。プロンプトが表示されたら、新しいOWB_HOMEのディレクトリの場所を入力します。

sqlplus OWBSYS/OWBSYS_PASSWORD
% New_OWB_HOME/owb/UnifiedRepos/reset_owbcc_home.sql

5. Oracle Database 12cソフトウェアをインストールし、第3章「Oracle Databaseのアップグレード」に記載されているデータベースのアップグレード手順に従います。

6. OWB累積パッチ16568042をOWBスタンドアロン・リリース11.2.0.3インストールに適用します。(OWBに対するパッチは、Oracle Database 12cのインストールの前後どちらでも適用できます。)
このパッチを入手するには、My Oracle Support (http://support.oracle.com)にアクセスし、「Patches」をクリックしてパッチ・リクエスト番号16568042を検索してください。

7. パッチのREADME.txtファイルのインプレース移行手順に従います。

8. スタンドアロンのOracleホームの場所からOWBリリース11.2.0.3を実行します。

2.2.15 統合監査スキーマおよびロールの削除

AUDSYSスキーマとAUDIT_ADMINロールおよびAUDIT_VIEWERロールを削除します。この段階で、AUDSYSスキーマは存在しません。

1. SYSDBAシステム権限を持つユーザーSYSでSQL*Plusにログインします。

sqlplus sys as sysdba
Enter password: password

2. AUDSYSスキーマが存在する場合、データベースを移行モードで起動してAUDSYSユーザーを削除します。

SQL> startup migrate pfile=$T_WORK/t_init1.ora
ORACLE instance started.
SQL> drop user audsys cascade;

User dropped.

3. AUDSYSスキーマ(存在する場合)およびAUDIT_ADMINロールおよびAUDIT_VIEWERロールを削除します。

DROP USER AUDSYS CASCADE;
DROP ROLE AUDIT_ADMIN;
DROP ROLE AUDIT_VIEWER;

2.3 新しいOracle Databaseソフトウェアのインストール

次の手順では、新しいOracle Databaseリリースのソフトウェアのインストール方法を説明します。

重要:
ソースおよびターゲットのOracleホームを異なるユーザーが所有している場合は、Database Upgrade Assistant (DBUA)を使用してデータベースをアップグレードできません。これを行うと、エラーPRKH-1014が返されます。ソースおよびターゲットのデータベースの所有者が同じであることを確認するか、または「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」に記載されている手動の手順を実行します。

このリリースの新しいOracle Databaseソフトウェアをインストールするには、次の手順を実行します。

1. Oracle RACデータベースをアップグレードする場合は、記述されている順番で次の手順を実行する必要があります。

1. ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』の記載に従って、最初にOracle Clusterwareをアップグレードします。

注意:
Oracle RAC以外のデータベースをアップグレードする場合は、DBUAを実行する前にOracle Net Configuration Assistant(NETCA)を実行する必要があります。「Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項」を参照してください。Oracle RACデータベースをOracle Clusterwareアップグレードの一部としてアップグレードする場合は、OUIによって自動的にNETCAが実行され、ネットワーク・リスナーがアップグレードされます。そのため、NETCAを個別に実行しないでください。

2. Oracle Grid Infrastructureのインストール・メディアをマウントします。

3. アップグレードを行う各ノードでオペレーティング・システムの前提条件チェックを実行し、ノードがOracle Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)に必要なシステムの前提条件を満たしていることを確認します。

4. 必要に応じて、以前のリリースのOracle Clusterwareソフトウェアが最新のパッチ・バージョンになるように、パッチのアップグレードを実行します。

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でチェックされる項目のタイプを確認し、データベースに存在する可能性のある問題を事前に確認できます。アップグレード前情報ツールは、検出された前提条件の問題の修正に役立ちます。(「Oracle Databaseのアップグレード前情報ツールの概要」を参照してください。)インストールの完了後、単独でDBUAを実行できます。

- Oracle Label Security、Oracle Database Vault、またはこれらの両方を使用する場合、データベース・エディションの選択ページで「Enterprise Edition」を選択し、「オプションの選択」をクリックして、コンポーネント・リストから一方または両方のコンポーネントを有効にします。「Oracle Label SecurityおよびOracle Database Vaultを使用しているデータベースのアップグレードの要件」を参照してください。

Oracle Databaseソフトウェアのインストールが正常に完了したら、「終了」ボタンをクリックしてOracle Universal Installerを閉じます。

関連項目:

- 「Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項」

- 「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」

2.4 Oracle Databaseをアップグレードする場合のパッチ・セットの更新および要件

Oracle Database 12cのソフトウェアには、Oracle Databaseのすべての最新パッチと更新を含む完全なリリースが含まれます。アップグレード後に、データベース管理の一部として、パッチおよびパッチ・セットの更新を確認することをお薦めします。

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

関連項目:

- My Oracle Support (http://support.oracle.com)のNote ID 854428.1「Patch Set Updates for Oracle Products」

- My Oracle Support (http://support.oracle.com)のNote ID 730365.1「Oracle Database Upgrade Path Reference List」(ダウンロード情報、パッチ番号および他のノートへのリンクが示された、最も入手しやすいOracle Databaseリリースのアップグレード・リファレンス・リストが含まれています)

2.5 Oracle Databaseのアップグレード前情報ツールの概要

Oracle Database 12cのソフトウェアをインストールした後、新しいリリースにアップグレードする前にデータベースを分析する必要があります。これは、アップグレード対象のデータベースの環境からpreupgrd.sqlアップグレード前情報ツールを実行することによって行います。アップグレード前情報ツールを実行することで、DBUAが確認する項目のプレビューおよび修正が必要なすべてに関する情報が提供されます。アップグレード前情報ツールでは、ソース・データベースでフラグ付けされた問題を解決するために実行できる修正スクリプトが生成されます。

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

- アップグレード前情報ツール(preupgrd.sql)の使用方法

- Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項

- アップグレード前情報ツールのサンプル出力

注意:
手動でアップグレードを行い、アップグレード前情報ツールを最初に実行しなかった場合は、catctl.plスクリプトがエラーで終了する可能性があります。アップグレード前に修正する問題が警告されるため、このツールの実行は必須です。

2.5.1 アップグレード前情報ツール(preupgrd.sql)の使用方法

Oracle Database 12cでpreupgrd.sqlアップグレード前情報ツールが導入されました。新しいpreupgrd.sqlスクリプトによって、以前のバージョンのアップグレード前情報ツールが置換されます。新しいアップグレード前情報ツールでは、前提条件のアップグレード・チェックのデフォルトの動作が次のように強化されました。

- アップグレード前情報ツールの出力が含まれるログ・ファイル(preupgrade.log)が作成されます。

- ソース・データベースでSQL*Plusを使用して修正可能な問題をリストし、説明するためのpreupgrade_fixups.sqlスクリプトが作成されます。これは、実行すると、簡単な問題の解決も試みます。

- データベースのアップグレード後に修正可能な問題に対処するためのpostupgrade_fixups.sqlスクリプトが作成されます。第4章「Oracle Databaseのアップグレード後の作業」を参照してください。

Oracle_Baseが定義されている場合、生成されたスクリプトおよびログ・ファイルはOracle_Base/cfgtoollogs/に作成されます。Oracle_Baseが定義されていない場合は、生成されたスクリプトおよびログ・ファイルはORACLE_HOME/cfgtoollogs/に作成されます。

ソース・データベース上でアップグレード前情報ツールを実行するには、次の手順を実行します。

1. Oracle Database 12cをインストールした新しいOracleホームのrdbms/adminディレクトリから、ソース・データベース(アップグレード対象のデータベース)への接続時にアクセス可能なディレクトリに、preupgrd.sqlおよびutluppkg.sqlをコピーします。可能な場合、これは一時ディレクトリにします。

2. アップグレード対象データベースの環境の所有者としてシステムにログインします。

重要:
アップグレード対象のデータベースの環境にアップグレード前情報ツール(preupgrd.sqlおよびutluppkg.sqlが含まれる)をコピーして、その環境から実行する必要があります。

3. SQL*Plusを起動して、アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。

SQL> CONNECT / AS SYSDBA

4. (推奨)次のシナリオについて、アップグレード前情報ツール(preupgrd.sql)を実行します。

1. ソースOracleホームの非CDBをアップグレードする前です。

SQL> @$ORACLE_HOME/rdbms/temp/preupgrd.sql

2. ソースOracleホームのCDBをアップグレードする前です。
CDBでpreupgrd.sqlを実行する場合、すべてのPDBが開いていることを確認します。すべてのPDBを開くには、次を実行します。

SQL> alter pluggable database all open;

次のように、catcon.plおよびpreupgrd.sqlを実行します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -d
$ORACLE_HOME/rdbms/admin -l <output directory for catcon logs> -b preupgrd
preupgrd.sql

<catconログの出力ディレクトリ>にあるログ・ファイルpreupgrd0.logには、preupgrd.sqlの画面出力が含まれています。アップグレード前の結果および修正スクリプトの場所は、preupgrd0.logを参照してください。

3. ソースOracleホームでPDBを切断する前です。(詳細は、「プラガブル・データベース(PDB)のアップグレード」を参照してください。)
preupgrd.sqlを単一のPDBで実行している場合、次のようにCDBに接続し、PDBに切り替えます。

alter session set container = PDB1;

修正スクリプトおよびログ・ファイルが、ソース・データベースのpreupgradeディレクトリに生成されます。PDBの出力のみを表示するには、cfgtoollogs/SID/preupgrade/pdbfilesを参照します。PDBファイルは最初にpreupgrade/pdbfilesに書き込まれ、次にcfgtoollogs/SID/preupgradeディレクトリのpreupgrade.log、preupgrade_fixups.sql、およびpostupgrade_fixups.sqlに連結されます。

5. 生成された修正スクリプトおよびログ・ファイルを表示して確認します(保存場所は、ORACLE_BASEが定義されている場合は$ORACLE_BASE/cfgtoollogs/db_unique_name/preupgrade、ORACLE_BASEが定義されていない場合は$ORACLE_HOME/cfgtoollogs/db_unique_name/preupgradeです)。

6. スクリプトを確認した後、ソース・データベースでpreupgrade_fixups.sqlを実行することをお薦めします。preupgrade_fixups.sqlスクリプトは、アップグレード前プロセスによって報告された問題の解決を試みます。
修正スクリプトで自動的に解決できない問題には、** USER ACTION REQUIRED **というフラグが付けられます。

7. 手動の手順を完了する必要があるフラグ付けされた問題を修正します。実行するアクションの詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。

8. 警告に対処し、解決するために必要な回数だけ、アップグレード前情報ツールを実行します。

2.5.2 Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項

Oracle Databaseの新しいリリースにアップグレードする前に、アップグレード前情報ツールによって表示された情報および警告の分析を行うことをお薦めします。

関連項目:
My Oracle Support (http://support.oracle.com)の次のサポート・ノート

- Note 472937.1「Information On Installed Database Components」

- Note 753041.1「How to Diagnose Components with NON VALID Status」

次の各項では、警告および適切な対処法について説明します。

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

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

- 以前のOracle Databaseリリースからのパスワードが指定されたデータベース・リンクの概要

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

- オプティマイザ統計の収集によるOracle Databaseの停止時間の短縮

- utluiobjスクリプトを使用したOracle Databaseでの無効なオブジェクトの識別

- アップグレード前にマテリアライズド・ビューのリフレッシュが完了したことの確認

- アップグレード前にメディア・リカバリを必要とするファイルがないことの確認

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

- アップグレード前に未処理の分散トランザクションの解決

- アップグレード前にデータベースのごみ箱の消去

- アップグレード時にスタンバイ・データベースとプライマリ・データベースの同期化

- Oracle Application Expressデータベースのアップグレードについて

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

Oracle Database 12c以上では、Oracle DatabaseのReal Application Securityを使用したUTLパッケージ(UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびUTL_INADDR)のアクセス制御が実装されたため、Oracle XML DBは必要ありません。

ACLおよびネットワーク・ユーティリティ・パッケージを更新するには、次の手順を実行します。

1. ログイン中のユーザーに、DBMS_LDAP.initで指定されたホストおよびポートのconnect権限があることを確認します。DBMS_LDAP PL/SQLパッケージおよびHttpUriType型の新しい動作では、Oracle Databaseの新しいリリースにアップグレードした後にアクセス制御リスト(ACL)を作成または更新する必要があります。
たとえば、アプリケーションがDBMS_LDAPパッケージに依存している場合は、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」が発生する可能性があります。このエラーを防ぐには、ログイン中のユーザーは、DBMS_LDAP.initで指定されたホストおよびポートのconnect権限を持っている必要があります。

2. UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPおよびUTL_INADDRパッケージのいずれかまたはすべてがインストールされている場合は、これらのパッケージが新しいOracle Database 12cリリースに対応した最新バージョンになるように、アップグレードの実行後にこれらのパッケージを再インストールする必要がある場合があります。

関連項目:
アクセス制御リストの構成の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

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

ネットワーク・ユーティリティ・パッケージの依存性を評価し、適切なアクセス制御リスト(ACL)を追加することによってアクセスを提供する必要がある場合があります。

ネットワーク・ユーティリティ・パッケージに対するアクセスのステータスを確認し、ネットワーク・ユーティリティ・パッケージのACLを追加するには、次の手順を実行します。

1. 「アップグレード前情報ツール(preupgrd.sql)の使用方法」の説明に従って、アップグレード前情報ツールを実行します。

2. アップグレード前情報ツールの出力(preupgrade.log)で、次のようなメッセージを確認します。

WARNING: --> Database contains schemas with objects dependent on network packages.
.... Refer to the Database 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)を構成する場合は、「外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成」に示されているスクリプトの例を参照してください。このスクリプトには、DBMS_NETWORK_ACL_ADMINパッケージを使用してアクセス制御リストに対して権限の作成、割当ておよび追加を行う方法が示されています。

5. アップグレードが完了した後、特定の必要な権限を付与する必要があります。アクセス権は、元のデータベースでの使用方法に基づいて決定します。

関連項目:
アクセス制御リストの構成の詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

2.5.2.3 以前のOracle Databaseリリースからのパスワードが指定されたデータベース・リンクの概要

この情報は、アップグレードの実行後に元のデータベース・リリースにダウングレードする場合にのみ重要となります。Oracle Database 12cへのアップグレード中に、データベース・リンク内のすべてのパスワードは暗号化されます。

- アップグレード元のリリースにダウングレードするには、ダウングレードする前に、暗号化されたパスワードが指定されたすべてのデータベース・リンクを削除する必要があります。したがって、ダウングレードしたデータベースにはデータベース・リンクは存在しません。

- 元のリリースにダウングレードできるようにしておく必要があると予想される場合は、影響を受けるデータベース・リンクの情報をSYS.LINK$表から保存しておくことで、ダウングレード後にデータベース・リンクを再作成できます。

- 以前のリリースの詳細は、アップグレードする前のOracle Databaseリリース用の元のドキュメントを参照してください。プラットフォーム固有の以前のリリースのOracleインストレーション・ガイドを参照することもできます。

関連項目:
認証およびデータベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。

2.5.2.4 TIMESTAMP WITH TIME ZONEデータ型に対するOracle Databaseの警告の概要

Oracle Database 12cに付属のタイムゾーン・ファイルは、一部のタイムゾーン地域の変換ルールに対して行われた変更を反映するために更新されています。これらの変更は、TIMESTAMP WITH TIME ZONEデータ型の既存のデータに影響する場合があります。

データベースをアップグレードする前に、最新のタイムゾーン・ファイルがあることを確認することをお薦めします。アップグレード対象のデータベースのタイムゾーン・ファイルのバージョンが、Oracle Databaseの新しいリリースで使用可能なタイムゾーン・ファイルの最新バージョンでない場合は、アップグレード前情報ツールによって、警告が表示されて続行方法が説明されます。表2-2、「タイムゾーン・ファイルのバージョンの修正を行う場合の選択肢」は、警告と、タイムゾーン・ファイルのバージョンの不一致を解決する方法の概要を示しています。

注意:

タイムゾーン・ファイルのバージョンが一致していない場合、データベースに格納されているTIMESTAMP WITH TIME ZONE型のデータは、アップグレード中に破損する可能性があります。

表2-2 タイムゾーン・ファイルのバージョンの修正を行う場合の選択肢

アップグレード中のデータベースのタイムゾーン・バージョン

タイムゾーン・ファイルの修正方法

新しいデータベース・リリースに含まれている最新バージョンより前のバージョンの場合、アップグレード前情報ツールには「Database is using a time zone file older than version n」と表示されます。

データベースのアップグレードの完了後。

DBMS_DST PL/SQLパッケージを使用して、『Oracle Databaseグローバリゼーション・サポート・ガイド』のタイムゾーン・ファイルおよびTIMESTAMP WITH TIME ZONEデータのアップグレード手順に関する説明に従ってください。

関連項目: DBMS_DST PL/SQLパッケージの詳細は『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』およびMy Oracle Support (http://support.oracle.com)のNote ID 1509653.1 「Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST」

新しいデータベース・リリースに含まれているバージョンより新しいバージョンの場合、アップグレード前情報ツールには、「Database is using a time zone file greater than version n.」と表示されます。

データベースのアップグレードの開始前。

使用しているタイムゾーン・ファイルのバージョンに適したRDBMS DSTパッチを使用して、Oracleホームにパッチを適用する必要があります。アップグレードする各データベースにパッチを適用します。適用しない場合、データベースをアップグレードすることなくアップグレード・スクリプトが終了します。RDBMS DSTパッチはMy Oracle Supportから入手できます。http://support.oracle.comのNote ID 412160.1を参照してください。

関連項目:

- My Oracle Support(http://support.oracle.com)のサポート・ノート「Updated DST Transitions and New Time Zones in Oracle Time Zone File Patches」(ID 412160.1)

- タイムゾーン・ファイルおよびTIMESTAMP WITH TIME ZONEデータのアップグレードの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

2.5.2.5 オプティマイザ統計の収集によるOracle Databaseの停止時間の短縮

統計が不足しているかOracle Databaseのアップグレード中に大幅に変更された表に対して統計収集が発生します。データベースを実際にアップグレードする前に統計を収集します。データベースに多数のディクショナリ表が含まれている場合は、アップグレードの開始前夜に統計を収集することをお薦めします。

停止時間を短縮するには、次を行います。

- これらの統計の収集にはDBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用することをお薦めします。たとえば、次のSQL文を入力します。

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

関連項目:
構文およびGATHER_DICTIONARY_STATSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

2.5.2.6 utluiobjスクリプトを使用したOracle Databaseでの無効なオブジェクトの識別

データベースのアップグレード前に検出された無効なSYSオブジェクトまたはSYSTEMオブジェクトは、アップグレード前情報ツールpreupgrd.sqlを実行した後に、registry$sys_inv_objsという名前の表に格納されます。また、データベースのアップグレード前に検出されたSYSまたはSYSTEM以外の無効なオブジェクトは、registry$nonsys_inv_objsに格納されます。

アップグレード前の無効なオブジェクトおよびアップグレードが原因で無効になったオブジェクトを識別するには、次の手順を実行します。

- $ORACLE_HOME/rdbms/admin/からutluiobj.sqlを実行します。
アップグレードの前および後にutluiobj.sqlスクリプトを実行すると、アップグレード後に無効になったオブジェクトとアップグレード前に無効だったオブジェクトを比較できます。これは、データベースの健全性チェックに似ています。アップグレード後に無効なオブジェクトが増えた場合は、問題が発生したことを示しています。

- 無効なオブジェクトを修正するか、My Oracle Supportに問い合せてください。

注意:
アップグレード・プロセスの一環として、最初にアップグレード前情報ツールを実行するようにしてください。DBUAは、前提条件チェックのフェーズでこのツールを実行します。このツールは、アップグレードの前に手動で実行することができます。アップグレード前情報ツールが1度も実行されていない場合は、表registry$sys_inv_objsが存在しないというエラーが表示されます。アップグレード前情報ツールによってregistry$sys_inv_objsが作成され、データが挿入されます。「アップグレード前情報ツール(preupgrd.sql)の使用方法」を参照してください。

関連項目:
PL/SQLパッケージのプロシージャを使用した無効なオブジェクトの手動での再コンパイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

2.5.2.7 アップグレード前にマテリアライズド・ビューのリフレッシュが完了したことの確認

Oracle Databaseをアップグレードする前に、すべてのマテリアライズド・ビューがリフレッシュを完了するまで待機する必要があります。システムに問い合せて、進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを判断することができます。

進行中のマテリアライズド・ビューのリフレッシュがあるかどうかを判断するには、次を行います。

- 次のSQL問合せを実行します。

SQL> SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s
WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;

関連項目:

- マテリアライズド・ビューを管理するためのDBMS_MVIEWパッケージの使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- データベースから既存のマテリアライズド・ビューを永続的に削除するためのDROP MATERIALIZED VIEW文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

2.5.2.8 アップグレード前にメディア・リカバリを必要とするファイルがないことの確認

Oracle Databaseをアップグレードする前に、メディア・リカバリを必要とするファイルがないことを確認する必要があります。システムに問い合せてファイルのリストを取得し、必要に応じてこれらのファイルのリカバリを行うことができます。

メディア・リカバリを必要とするファイルのリストを取得するには、次を行います。

- 次の文を実行します。

SQL> SELECT * FROM v$recover_file;

関連項目:
ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.5.2.9 アップグレード前にバックアップ・モードのファイルがないことの確認

Oracle Databaseのバックアップ時にバックアップ・モードのファイルがあってはいけないため、バックアップが完了するまで待機する必要があります。システムに問い合せてバックアップ・モードのファイルのリストを表示できます。その後、バックアップが完了するまで待機、または必要のないバックアップを中止することで適切な対処を行います。

バックアップ・モードのファイルのリストを取得するには、次を行います。

- 次の文を実行します。

SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

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

2.5.2.10 アップグレード前に未処理の分散トランザクションの解決

Oracle Databaseをアップグレードする前に、未処理の分散トランザクションを解決する必要があります。これを行うには、最初に問合せによって保留中のトランザクションを確認してから、トランザクションをコミットします。保留中のすべての分散トランザクションがコミットされるまで待機する必要があります。

未処理の分散トランザクションを解決するには、次の手順を実行します。

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;

ヒント:
分散トランザクションの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

2.5.2.11 アップグレード前にデータベースのごみ箱の消去

Oracle Databaseのアップグレード処理を開始する前に、データベース内のすべてのユーザーのゴミ箱を空にしておく必要があります。PURGE文を使用して、アイテムおよびその関連オブジェクトを削除して、記憶域の領域を解放します。SYSDBA権限がある場合は、RECYCLEBINのかわりに、DBA_RECYCLEBINを指定することによって、データベース全体のすべてのゴミ箱を消去できます。Oracle Database 12c以上では、SYSDBA権限を付与する必要なく、新しいPURGE DBA_RECYCLEBINシステム権限を使用して同じアクションを実行できます。

PURGE DBA_RECYCLEBIN文は、システム全体のごみ箱からすべてのオブジェクトを削除する特別なPURGEコマンドで、各ユーザーのごみ箱を空にすることと同じです。以前のリリースでは、この文にはSYSDBA管理者権限が必要であり、これは、義務の分離および最低限の権限の点で非常に望ましくないものです。義務の分離を順守するために、Oracle Database 12cでは新しいシステム権限であるPURGE DBA_RECYCLEBINが導入され、これによって、SYSDBA管理者権限を持たずにPURGE DBA_RECYCLEBINを実行することが可能です。

データベースのごみ箱を空にするには、次のコマンドを実行します。

SQL> PURGE DBA_RECYCLEBIN

注意:

アップグレード処理を行う際は、ORA-00600エラーの発生の回避とアップグレード時間の短縮のために、ごみ箱を空にしておく必要があります。

関連項目:

- ゴミ箱内のオブジェクトの消去の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

- データベース管理に対する義務の分離の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

2.5.2.12 アップグレード時にスタンバイ・データベースとプライマリ・データベースの同期化

スタンバイ・データベースが存在する場合は、Oracle Databaseをアップグレードする前に、プライマリ・データベースと同期化する必要があります。

スタンバイ・データベースが存在するかどうかを確認して、そのスタンバイ・データベースと同期化するには、次の手順を実行します。

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オプションを使用して、スタンバイ・データベースのリカバリを開始します。

関連項目:
フィジカル・スタンバイ・データベースとプライマリ・データベースの同期の詳細は、『Oracle Data Guard概要および管理』を参照してください。

2.5.2.13Oracle Application Expressデータベースのアップグレードについて

Oracle Application Expressが含まれているデータベースをアップグレードする場合は、次のようになります。

- データベースのアップグレード時間を短縮するために、Oracle Application Expressを個別にアップグレードできます。

- open_cursorsには、最小値である150が必要です。Oracle Application Expressをアップグレードする場合、open_cursors = 150に設定することをお薦めします。それ以外の場合、次のエラーが表示される場合があります。

ORA-01000: maximum open cursors exceeded
ORA-06512: at "APEX_040200.WWV_FLOW_API", line 1594

2.5.3 アップグレード前情報ツールのサンプル出力

アップグレード前情報ツールでは、推奨事項が表示されますが、その推奨事項は自動的には実行されません(これは、修正スクリプトの実行方法およびタイミングをユーザーが制御できるようにするためです)。

次の例は、アップグレード対象のリリース11.2.0.3データベースでOracle Database 12cのアップグレード前情報ツール(preupgrd.sql)を実行することで、preupgrade.logに生成され、書き込まれた出力を示します。

Oracle Database Pre-Upgrade Information Tool 03-06-2014 12:18:01
Script Version: 12.1.0.2.0 Build: 006
**********************************************************************
Database Name:  MyDB
ContainerName:  Not Applicable in Pre-12.1 database
ContainerID:  Not Applicable in Pre-12.1 database
Version:  11.2.0.3.0
Compatible:  11.1.0
Blocksize:  8192
Platform:  Linux x86 64-bit
Timezone file:  V14
**********************************************************************
[Update parameters]
[Update Oracle Database 11.2.0.3.0 init.ora or spfile]

--> If Target Oracle is 32-bit, refer here for Update Parameters:
WARNING: --> "shared_pool_size" needs to be increased to at least 247463936
WARNING: --> "java_pool_size" needs to be increased to at least 67108864
WARNING: --> "db_cache_size" needs to be increased to at least 50331648
WARNING: --> "processes" needs to be increased to at least 300

--> If Target Oracle is 64-bit, refer here for Update Parameters:
WARNING: --> "shared_pool_size" needs to be increased to at least 494927872
WARNING: --> "java_pool_size" needs to be increased to at least 134217728
WARNING: --> "db_cache_size" needs to be increased to at least 50331648
WARNING: --> "processes" needs to be increased to at least 300
**********************************************************************
**********************************************************************
[Renamed Parameters]
[No Renamed Parameters in use]
**********************************************************************
**********************************************************************
[Obsolete/Deprecated Parameters]
[No Obsolete or Desupported Parameters in use]
**********************************************************************
[Component List]
**********************************************************************
--> Oracle Catalog Views                   [upgrade]  VALID
--> Oracle Packages and Types              [upgrade]  VALID
--> JServer JAVA Virtual Machine           [upgrade]  VALID
--> Oracle XDK for Java                    [upgrade]  VALID
--> Real Application Clusters              [upgrade]  INVALID
--> Oracle Workspace Manager               [upgrade]  VALID
--> Oracle Text                            [upgrade]  VALID
--> Oracle XML Database                    [upgrade]  VALID
--> Oracle Java Packages                   [upgrade]  VALID
--> Oracle Multimedia                      [upgrade]  VALID
--> Expression Filter                      [upgrade]  VALID
--> Rule Manager                           [upgrade]  VALID
**********************************************************************
[Tablespaces]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
minimum required size: 909 MB
--> SYSAUX tablespace is adequate for the upgrade.
minimum required size: 500 MB
--> TEMP tablespace is adequate for the upgrade.
minimum required size: 60 MB
--> UD1 tablespace is adequate for the upgrade.
minimum required size: 400 MB

[No adjustments recommended]

**********************************************************************
**********************************************************************
[Pre-Upgrade Checks]
**********************************************************************
WARNING: --> Process Count may be too low

Database has a maximum process count of 60 which is lower than the
default value of 300 for this release.
You should update your processes value prior to the upgrade
to a value of at least 300.
For example:
ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
or update your init.ora file.

INFORMATION: --> Older Timezone in use

Database is using a time zone file older than version 21.
After the upgrade, it is recommended that DBMS_DST package
be used to upgrade the 11.2.0.3.0 database time zone version
to the latest version which comes with the new release.
Please refer to My Oracle Support note number 977512.1 for details.

**********************************************************************
[Pre-Upgrade Recommendations]
**********************************************************************

*****************************************
********* Dictionary Statistics *********
*****************************************

Please gather dictionary statistics 24 hours prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
EXECUTE dbms_stats.gather_dictionary_stats;

^^^ MANUAL ACTION SUGGESTED ^^^

*****************************************
*********** Hidden Parameters ***********
*****************************************

Please review and remove any unnecessary hidden/underscore parameters prior
to upgrading.  It is strongly recommended that these be removed before upgrade
unless your application vendors and/or Oracle Support state differently.
Changes will need to be made in the init.ora or spfile.

^^^ MANUAL ACTION SUGGESTED ^^^

To view existing hidden parameters execute the following command
while connected AS SYSDBA:
SELECT name, value from SYS.V$PARAMETER WHERE name
LIKE '\_%' ESCAPE '\' order by name;

Or run the Pre-Upgrade Fixup Script to display the Hidden Parameters
currently set.

**********************************************************************
[Post-Upgrade Recommendations]
**********************************************************************

*****************************************
******** Fixed Object Statistics ********
*****************************************

Please create stats on fixed objects two weeks
after the upgrade using the command:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

^^^ MANUAL ACTION SUGGESTED ^^^

**********************************************************************
************  Summary  ************

0 ERRORS exist in your database.
1 WARNING that Oracle suggests are addressed to improve database performance.
1 INFORMATIONAL message that should be reviewed prior to your upgrade.

After your database is upgraded and open in normal mode you must run
rdbms/admin/catuppst.sql which executes several required tasks and completes
the upgrade process.

You should follow that with the execution of rdbms/admin/utlrp.sql, and a
comparison of invalid objects before and after the upgrade using
rdbms/admin/utluiobj.sql

If needed you may want to upgrade your timezone data using the process
described in My Oracle Support note 977512.1
***********************************

2.6 アップグレードのためのOracle Databaseのバックアップ

アップグレード前情報ツールを実行し、正常にデータベースを停止した後、Oracle Databaseをバックアップすることをお薦めします。停止時間を最小化するために、オンライン・バックアップを実行するか、保証付きリストア・ポイントを作成できます。Database Upgrade Assistant (DBUA)によって、バックアップおよびリストア・ポイントを指定できます。

重要:

Oracleソフトウェアを変更する前に、Oracleソフトウェアおよびデータベースのバックアップを作成することをお薦めします。Windowsオペレーティング・システム上で動作するOracleソフトウェアでは、Windowsレジストリもバックアップする必要があります。レジストリのバックアップがないと、Oracle Database 12cへのアップグレードが失敗して以前のソフトウェア・インストールに戻す場合に、Oracleソフトウェアを動作状態にリストアすることができません。

関連項目:

- オンライン・バックアップおよびバックアップ・モードの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- フラッシュバック・データベースとリストア・ポイントの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

アップグレード対象のデータベースのバックアップを実行するには、次の手順を実行します。

1. 次のように、Oracle 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';
}

関連項目:
RMANバックアップの実行方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

2.7 アップグレードのための新しいOracleホームの準備

アップグレードするデータベースをバックアップした後、新しい場所に新しいOracleホームを準備します。Oracle Database 12cのソフトウェアを新しい場所にインストールします。

関連項目:

- 「アップグレードのためのOracle Databaseのバックアップ」

- 「Windows上のOracleホームを準備するための前提条件」

アップグレードのために新しいOracleホームを準備するには、次の手順を実行します。

1. アップグレードするデータベースのOracleホームから、Oracle Database 12cの新しいOracleホームに、構成ファイルをコピーします。DBUAを使用している場合、構成ファイルは自動的にコピーされ、この手順は無視できます。
構成ファイルを新しいOracleホームに手動でコピーする必要があるのは、次の場合です。

1. パラメータ・ファイルが古い環境のOracleホームに存在する場合は、新しいOracleホームへコピーします。デフォルトでは、パラメータ・ファイルを検索する場所は、LinuxまたはUNIXプラットフォームの場合はORACLE_HOME/dbsディレクトリで、Windowsオペレーティング・システムの場合はORACLE_HOME\databaseディレクトリです。パラメータ・ファイルは任意の場所に格納できますが、Oracle Database 12cにアップグレードした後は、古い環境のOracleホームには格納しないでください。

注意:
初期化パラメータを編集できるように、サーバー・パラメータ・ファイル(SPFILE)からテキストの初期化パラメータ・ファイル(PFILE)を作成する必要があります。初期化パラメータの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。Oracle RAC環境での初期化パラメータ・ファイルの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

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 12cの新しいOracleホームに移動またはコピーします。
パスワード・ファイルの名前と位置は、オペレーティング・システムによって異なります。LinuxまたはUNIXプラットフォームのデフォルトのパスワード・ファイルはorapwSIDで、ORACLE_HOME/dbsディレクトリにあります。Windowsオペレーティング・システムのデフォルトのパスワード・ファイルはpwdSID.oraで、ORACLE_HOME\databaseディレクトリにあります。どちらの場合も、SIDはOracleインスタンスのIDです。

2. 次の手順を実行して、Oracle Database 12cのパラメータ・ファイルを調整します。

1. サポートが終了した初期化パラメータを削除して、非推奨になった初期化パラメータを調整します。一部のパラメータはOracle Database 12cではサポートが終了しており、他のパラメータは非推奨となっています。Oracle Database 12cインスタンスを起動するすべてのパラメータ・ファイルから、サポートが終了したパラメータをすべて削除します。サポートが終了したパラメータは、Oracle Database 12cでエラーの原因となる可能性があります。また、新しいリリースで構文が変更になったパラメータも変更します。
アップグレード前情報ツールを使用すると、「非推奨パラメータ」および「サポートが終了したパラメータ」の各セクションに、検出された非推奨となったパラメータおよびサポートが終了したパラメータが表示されます。

関連項目:
非推奨またはサポートが終了した初期化パラメータについては、第8章「Oracle Database 12cでの非推奨となった機能とサポートが終了した機能」を参照してください。

2. 初期化パラメータの値をアップグレード前情報ツールによって示された最小値以上に調整します。

3. パラメータ・ファイルのすべてのパス名が完全に指定されていることを確認します。パラメータ・ファイルには相対パス名を使用しないでください。

4. パラメータ・ファイルにIFILEエントリがある場合、パラメータ・ファイルのIFILEエントリを変更して、手順1で指定したインクルード・ファイルの新しい場所を指定するようにします。次に、手順aからdでパラメータ・ファイルを編集したときと同じ方法で、IFILEエントリに指定されているファイルを編集します。

5. クラスタ・データベースをアップグレードしている場合は、SPFILEまたはinitORACLE_SID.oraファイルの変更が必要となることがあります。

これらの調整後、変更したすべてのファイルを保存します。

3. クラスタ・データベースをアップグレードしている場合は、CLUSTER_DATABASE初期化パラメータをfalseに設定します。アップグレード後に、この初期化パラメータの設定をtrueに戻す必要があります。

関連項目:

- CLUSTER_DATABASEの詳細は、『Oracle Databaseリファレンス』を参照してください。

- Oracle RACでの初期化パラメータ・ファイルの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

2.7.1 Windows上のOracleホームを準備するための前提条件

セキュリティ上の理由により、他のOracleホームのOracleホーム・ユーザーとして構成された異なるWindowsユーザー・アカウントでは、同一のOracleベースを共有することはできません。

次の推奨事項は、WindowsプラットフォームでOracle Databaseをアップグレードする前に適用されます。

- データベース・アップグレードは、ソースと宛先Oracleホームの両方で同じWindowsユーザー・アカウントがOracleホームのユーザーとして使用された場合にサポートされます。

- データベース・アップグレードは、アップグレード対象のデータベースのOracleホームでWindows組込みアカウントを使用する場合にサポートされます。Windows上のOracleホームのユーザーの組込みアカウント・オプションは、Oracle Database 12cより前のリリース(リリース11.2以下)でのみサポートされていました。

- Oracleホームのユーザーは、自身のOracleベースおよびOracleホームの外部にあるファイルにはアクセスできない可能性があります。したがって、アップグレード時に別のOracleベースを選択した場合は、Oracle Databaseサービスで古いOracleベースにあるファイルにアクセスできない可能性があります。データベースのアップグレードにDBUAを使用すると、Oracleホームのユーザーは、自身のOracleベースおよびOracleホームの外部にあるファイルにアクセスできます。
手動でのアップグレードまたは古いOracleベースのカスタム・ファイル(ウォレット、構成ファイルなど)を使用する前に、これらの外部ファイルに対してOracleホームのユーザーにアクセス権を付与するか、新しいOracleベースにこれらのファイルをコピーする必要があります。

関連項目:
Windows上のデータベース管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

2.8 Oracle Databaseのアップグレード時のOracle Net Servicesに関する推奨事項

Oracle Database 12cでは、新しい基礎となるネット・サービス・パラメータによってデータ圧縮が可能で、これにより、SQL TCP接続を介して転送されるセッション・データ・ユニットのサイズが縮小されます。

次のsqlnet.oraファイルの新しいパラメータで、圧縮、および優先圧縮方式を指定します。

- SQLNET.COMPRESSION

- SQLNET.COMPRESSION_LEVELS

- SQLNET.COMPRESSION_THRESHOLD

これらの新しいパラメータは以前のリリースではサポートされておらず、Oracle Database 12cでのみ使用可能です。

関連項目:
新しいsqlnet.ora圧縮パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

アップグレード元のデータベースでリスナーが設定されていない場合は、DBUAを実行する前に、Oracle Net Configuration Assistant (Net CA)を実行して、listener.oraファイルを含むOracle Databaseの新しいリリースのリスニング・プロトコルのアドレスおよびサービス情報を構成する必要があります。リリース11.2より前のリリースのOracle Databaseには、新しいバージョンのリスナーが必要です。新しいリスナーには、以前のOracle Databasesとの下位互換性があります。

DBUAを使用してOracle RACデータベースをアップグレードできます(この方法では、古いOracleホームから、新しいOracle Grid Infrastructureのホームに、リスナーが自動的に移行されます)。Oracle Grid Infrastructureホームでlsnrctlコマンドを使用してリスナーを管理する必要があります。以前のリリースのOracleホームの場所からlsnrctlコマンドを使用しないでください。

関連項目:
Oracle Net Configuration Assistantの使用方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

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

アップグレード前の処理、アップグレード処理およびアップグレード後の処理のすべてをテストするデータベース環境の完全な作業用コピーを作成することをお薦めします。現行の本番Oracle Databaseに影響を与えないテスト環境を作成できます。たとえば、Oracle Data Guardでは、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの作成が可能です。

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

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

- データ・ポンプ・エクスポート/インポートを使用する場合は、現行の本番データベースのサブセットを使用して、段階的にエクスポートおよびインポートします。

テスト環境を使用してデータベースのアップグレードを行います。ベスト・プラクティスは、ダウンサイズしたコピーまたはテスト・データに対してではなく、アップグレードするデータベースの正確なコピーに対してアップグレード処理のテストを実行することです。正確なコピーを実現できない場合は、テスト環境に移動する代表的なデータのサブセットを慎重に選択し、そのデータでアップグレードをテストします。

関連項目:

- データベースのアップグレードのテストの詳細は、『Oracle Database Testingガイド』を参照してください。

- データ・ポンプのエクスポートおよびインポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- アップグレード前のテストに関する詳細な情報およびポインタは、My Oracle Support (http://support.oracle.com)のNote ID 1462240.1「Oracle Upgrade Companion」を参照してください。

2.9.1 Oracle Call Interface (OCI)およびプリコンパイラ・アプリケーションのアップグレード

Oracle Databaseの新しいリリースで使用するすべてのOracle Call Interface (OCI)およびプリコンパイラ・アプリケーションをアップグレードします。現行の本番データベースをアップグレードする前に、これらのアプリケーションをサンプルのデータベースでテストすることをお薦めします。

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

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

現行のデータベースおよびOracle Databaseの新しいリリースにアップグレードしたテスト・データベースに対して、計画したテストを実行します。

- テスト結果を比較し、相違点を記録します。

- 問題が解決されるまで、必要な回数、テスト・アップグレードを繰り返します。

新しいOracle Databaseで既存のアプリケーションが正常に動作するかを確認するために、この新しくアップグレードされたテスト・データベースをテストします。

- 利用可能なOracle Databaseの機能を追加して、拡張された機能および新しい機能についてテストします。

- アプリケーションが現行のデータベースの場合と同様に動作することを確認します。

関連項目:

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

- データベースのアップグレードのテストの詳細は、『Oracle Database Testingガイド』を参照してください。

3 Oracle Databaseのアップグレード

最小の停止時間でOracle Databaseをアップグレードし、新しいリリースにアプリケーションを移行するための包括的なツールのセットが提供されています。

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

- Oracle Databaseのアップグレード計画

- Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード

- Oracle Databaseのパラレル・アップグレード・ユーティリティの概要

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

- マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード

- データ・ディクショナリのアップグレード方法およびステータスの表示方法

- 以前のリリースのOracle Databaseでのcatupgrd.sqlスクリプトの概要

- catuppst.sqlスクリプトの概要

- データベースのトランスポートおよびアップグレードについて(フル・トランスポータブル・エクスポート/インポート)

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

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

注意:

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

3.1 Oracle Databaseのアップグレード計画

Oracle Database 12c以上では、マルチテナント・アーキテクチャは、Oracle Databaseをプラガブル・データベースを含むマルチテナント・コンテナ・データベース(CDB)として機能させることができます。Oracle Database 12cより前のすべてのOracle Databaseリリースは、非CDBでした。マルチテナント・アーキテクチャの概要については、『Oracle Database概要』を参照してください。

このリリースでは、アップグレードに関する多くの計画が提供されています。以前のリリースをOracle Database 12cにアップグレードした後で、「以前のリリースのアップグレードおよびCDBへのPDBの接続」の説明に従って、アップグレードされたデータベースをCDBに接続できます。

重要:

COMPATIBLE初期化パラメータを12.1.0.2に設定すると、データベースをダウングレードできません。互換性が12.1.0.1に設定されている場合のみ、プラガブル・データベース(PDB)に対するダウングレードが可能になりますが、ダウングレードに関する制約がある可能性があります。第6章「以前のリリースへのOracle Databaseのダウングレード」を参照してください。

この項には次のトピックが含まれます:

- 非CDBのOracle Databaseのアップグレード

- 以前のリリースのアップグレードおよびCDBへのPDBの接続

- マルチテナント(CDB) Oracle Databaseのアップグレード

- プラガブル・データベース(PDB)のアップグレード

関連項目:
CDBの作成および構成に関する詳細は、『Oracle Database管理ガイド』を参照し、マルチテナント・アーキテクチャの概要については、『Oracle Database概要』を参照してください。

3.1.1 非CDBのOracle Databaseのアップグレード

非CDBのOracle Databaseでは、マルチテナント・アーキテクチャが使用されず、プラガブル・データベース(PDB)が含まれていません。Oracle Database Upgrade Assistant (DBUA)を使用するか、または手動で、データベースをアップグレードできます。「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」または「非CDBのOracle Databaseの手動でのアップグレード」の手順に従います。

3.1.2 以前のリリースのアップグレードおよびCDBへのPDBの接続

DBUAまたはパラレル・アップグレード・ユーティリティのいずれかを使用してOracle Databaseの以前のリリースをアップグレードした後、アップグレードしたデータベースをマルチテナント・コンテナ・データベース(CDB)に接続できます。アップグレードされたリリース12.1データベースは、既存のCDBに接続できます。第2章「Oracle Databaseのアップグレードの準備」で説明している必要なアップグレード前手順を実行するようにしてください。次の手順では、両方のデータベースが同じシステム上にあると想定しています。

関連項目:
SQL*Plusを使用したPDBの作成および削除の詳細は『Oracle Database管理者ガイド』、異なる要因を含む様々なシナリオの例は『Oracle Database管理者ガイド』を参照してください。

データベースをアップグレードしてCDBに接続するには、次の手順を実行します。

1. 新しいOracle Database 12cソフトウェアをインストールします。ご使用のオペレーティング・システム・プラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。

2. このガイドの説明に従ってデータベースをアップグレードします。第3章「Oracle Databaseのアップグレード」を参照してください。

3. COMPATIBLEパラメータを12.0.0に設定します(アップグレード・プロセスでそのように設定していない場合)。「Oracle DatabaseのCOMPATIBLE初期化パラメータ」を参照してください。

4. データベースが読取り専用モードであることを確認します。

SQL> startup mount
SQL> alter database open read only;

5. 切断されたPDBを接続するための前提条件を満たしていることを確認します。これらの要件が満たされているかどうかを判断するためにDBMS_PDB.CHECK_PLUG_COMPATIBILITYファンクションを使用する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

6. PDB用のXMLファイルを作成します。XMLファイルのルート名は、PDBの名前に一致させます。場所のpathは任意に指定できます。この場所は、XMLファイルが保存される場所です。

SQL> exec DBMS_PDB.DESCRIBE('path/PDB1.xml');

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

SQL> SHUTDOWN IMMEDIATE

8. データベースをCDBに接続します。

SQL> CREATE PLUGGABLE DATABASE PDB1 USING 'path/PDB1.xml' NOCOPY TEMPFILE REUSE;

この例では、PDBにはPDB1という名前が付いています。任意の名前を使用できますが、名前はそのCDBで一意である必要があります。

また、この例では、データファイルはデータベースがスタンドアロンであったときと同じ場所にそのまま残ると想定しています。データファイルを別の場所にコピーした場合(Oracle ASMとともに格納している場合など)、パラメータSOURCE_FILE_NAME_CONVERTを指定する必要があります。SOURCE_FILE_NAME_CONVERT句を使用する例については、『Oracle Database管理者ガイド』を参照してください。

TEMPFILE REUSEは、既存のTEMP表領域を再利用できることを指定します。

「プラガブル・データベースが作成されました。」と表示され、これで、アップグレードされたデータベースは、CDB用として準備ができたPDBになります。

9. 構成済のリスナーを使用してPDBに接続します。この例のPDBの名前はPDB1です。

SQL> sys/oracle@PDB1 as sysdba

かわりに、次のようにPDBに接続することもできます。

SQL> ALTER SESSION set container=PDB1;

10. ディクショナリをPDBタイプに変換します。adminディレクトリからnoncdb_to_pdb.sqlスクリプトを実行します。このスクリプトは、PDBを初めてオープンする前に実行する必要があります。

@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql

11. 新しいPDBを起動し、読取り/書込みモードでオープンします。Oracle Databaseで新しいPDBをCDBに統合するには、PDBを読取り/書込みモードでオープンする必要があります。STARTUP SQL*PlusコマンドでのPDBのオープン・モード変更の詳細は、『Oracle Database管理者ガイド』を参照してください。

SQL> STARTUP PLUGGABLE DATABASE PDB1 OPEN;

12. PDBをバックアップします。PDBのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

3.1.3 マルチテナント(CDB) Oracle Databaseのアップグレード

Oracle Database 12c以上では、プラガブル・データベース(PDB)の作成および管理を行うことができるマルチテナント・アーキテクチャが提供されます。非CDBデータベースのように、Oracle Database Upgrade Assistant (DBUA)を使用するか、または手動で、CDBをアップグレードできます。「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」または「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」の手順に従います。

3.1.4 プラガブル・データベース(PDB)のアップグレード

CDBには、0(ゼロ)、1またはそれ以上のプラガブル・データベース(PDB)を含めることができます。CDB全体をアップグレードせずに、1つのPDBをアップグレードできます。たとえば、リリース12.1.0.1のCDBからPDBを切断し、リリース12.1.0.2のCDBに接続した後、そのPDBをリリース12.1.0.2にアップグレードできます。DBUAを使用してPDBをアップグレードすることはできません。そのため、手動でPDBをアップグレードできます。この項の手順に従い、詳細は、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」を参照してください。

注意:
PDBは、バックアップしないとリカバリできません。CDBを作成してデータベースに接続する方法でアップグレードした後は、必ずPDBをバックアップしてください。PDBのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

手順1   リリース12.1.0.1 PDBの準備

この手順では、リリース12.1.0.2にアップグレードする必要のあるPDBを準備します。

1. リリース12.1.0.1環境で、アップグレードするPDBに切り替えます。たとえば、PDB1の場合は次のようになります。

SQL> alter session set container=PDB1;

2. リリース12.1.0.2環境からpreupgradeスクリプトを実行し、修正スクリプトを生成します。

@$ORACLE_HOME_12102/rdbms/admin/preupgrd.sql

preupgrade.logの出力には、修正スクリプトの場所が含まれています。ORACLE_BASEが定義されている場合、ログ・ファイルと修正スクリプトは、ORACLE_BASE/cfgtoollogsの下に作成されます。ORACLE_BASEが定義されていない場合、ファイルはORACLE_BASE/cfgtoollogsではなくORACLE_HOME/cfgtoollogsの下に作成されます。

PDBの出力のみを表示するには、cfgtoollogs/SID/preupgrade/pdbfilesを参照します。PDBファイルは最初にpreupgrade/pdbfilesに書き込まれ、次にcfgtoollogs/SID/preupgradeディレクトリのpreupgrade.log、preupgrade_fixups.sql、およびpostupgrade_fixups.sqlに連結されます。

3. 次のように修正スクリプトを実行します。

@$ORACLE_BASE/cfgtoollogs/CDB1/preupgrade/preupgrade_fixups.sql

注意:
preupgrade_fixups.sqlを実行する前にPDBに接続しておく必要があります。

4. アップグレード時の停止時間を短縮するには、次のようにオプティマイザ統計を収集します。

SQL> exec dbms_stats.gather_dictionary_stats;

この時点で、preupgrade.logからの追加の推奨事項も適用します。

5. CDBルート・コンテナに切り替えます。

SQL> alter session set container=CDB$ROOT;

6. 例PDB1のPDBを終了します。

SQL> alter pluggable database PDB1 close;

7. PDB1を切断し、ステージングすると、12.1.0.2 CDBへの接続が可能になります。完了したらこのCDBを終了します。次に例を示します。

SQL> alter pluggable database PDB1 unplug into '/stage/PDB1.xml';
SQL> exit

この時点で、「PDBの12.1.0.2 CDBへのプラグイン」の説明のとおりスタンドアロンPDBをリリース12.1.0.2 CDBにプラグインする準備ができました。

手順2   PDBの12.1.0.2 CDBへの接続

この手順では、手順1で準備したPDBをリリース12.1.0.2 CDBに接続します。この例では、PDB1というPDBを使用します。リリース12.1.0.2でDBCAを実行したとき、互換性パラメータはデフォルトで12.1.0.2に設定されていました。互換性パラメータを前のリリースに変更してある場合、アップグレードを実行するには、これを12.1.0.2に設定する必要があります。

1. リリース12.1.0.2 CDBに接続します。

SQL> alter session set container=CDB$ROOT;

2. ステージングされた12.1.0.1 PDBを使用して12.1.0.2 PDBを作成します。

SQL> create pluggable database PDB1 using '/stage/PDB1.xml'
file_name_convert=('/oradata/CDB1/PDB1', '/oradata/CDB2/PDB1');

関連項目:
SQL*PlusによるPDBの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. PDBをアップグレード・モードで開きます。

SQL> alter pluggable database PDB1 open upgrade;

4. SQL*Plusを終了して手順3のPerlスクリプトであるパラレル・アップグレード・ユーティリティを実行します。

SQL> Exit

手順3   PDBのアップグレード

この手順では、パラレル・アップグレード・ユーティリティと修正スクリプトを実行し、アップグレードを完了します。

1. コマンド・プロンプトから12.1.0.2 Oracleホームのadminディレクトリに移動します。

cd $ORACLE_HOME/rdbms/admin

2. パラレル・アップグレード・ユーティリティcatctl.plを実行します。通常catctl.plで使用する構文を使用しますが、アップグレードするPDBを指定する場合には、-c PDBnameオプションを使用する必要があります。PDB1を使用しているこの例に示すように、PDBの名前は大文字にします。

$ORACLE_HOME/perl/bin/perl catctl.pl -c "PDB1" -l /home/oracle/upgrade
catupgrd.sql

catctl.plの構文の詳細は、「パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ」を参照してください。

3. SQL*Plusにログインし、PDBを開始して必要なスクリプトおよびアップグレード後の修正スクリプトを実行します。

SQL> alter session set container=PDB1;
SQL> startup

4. utlrp.sqlを実行してオブジェクトをコンパイルします。

@?/rdbms/admin/utlrp.sql

5. アップグレード後の修正スクリプトを実行し、アップグレードを完了します。(PDBに接続していることを確認してください。)

$ORACLE_BASE/cfgtoollogs/CDB1/preupgrade/postupgrade_fixups.sql

ORACLE_BASEが設定されていない場合、ファイルは$ORACLE_BASE/cfgtoollogsではなく$ORACLE_HOME/cfgtoollogsの下に作成されます。

注意:

- PDBまたは他のスタンドアロン・データベースをサーバーAからサーバーBに移動する場合、postupgrade_fixups.sqlスクリプトを新しい場所にコピーし、新しい環境でアップグレード後にこれを実行する必要があります。

- 指定したPDBのアップグレード後の修正スクリプトはpreupgrade/pdbfiles/postupgrade_fixups.PDB NAME.sqlにあり、その内容はpreupgrade/postupgrade_fixups.sqlに連結されています。

複数のPDBをアップグレードするには、これらの手順を繰り返します。catctl.plを実行する場合、PDBのスペース区切りリストを使用して、すべてのPDBを一括して指定できます。次に例を示します。

$ORACLE_HOME/perl/bin/perl catctl.pl -c "PDB1 PDB2" -l /home/oracle/upgrade
catupgrd.sql

3.2 Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード

Database Upgrade Assistant (DBUA)では、Oracle Databaseのアップグレードを順を追って説明するためのグラフィカル・ユーザー・インタフェースが提供されています。DBUAは、CDBおよび非CDBのデータベース・システム用に動作します。

次の各項では、DBUAを使用したデータベースのアップグレードに関する推奨事項および手順を説明します。

- DBUAの使用に関する推奨事項

- DBUAによるOracle Databaseのアップグレードの処理方法

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

- アップグレード時のWindows認証の概要

- 既存の12c Oracleホームからのデータベースの移動

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

注意:
「サイレント・モードのDBUAを使用したOracle Databaseのアップグレード」に記載されているとおり、DBUAをユーザー・インタフェースを表示しないサイレント・モードで起動できます。これは、大きいロールアウトおよびスクリプトの場合に役立ちます。

3.2.1 DBUAの使用に関する推奨事項

DBUAを使用するときの手順は、マルチテナント・コンテナ・データベース(CDB)、プラガブル・データベース(PDB)、および非CDBの場合と同じです。CDBおよびPDBを使用する際の概要およびドキュメント・ロードマップについては、『Oracle Database概要』を参照してください。ただし、DBUAを実行する場合の考慮事項および推奨事項があります。この項では、推奨事項をまとめています。「アップグレード時のDBUAの停止の概要」も参照してください。

DBUAの使用に関する推奨事項は、次のとおりです。

- DBUAを使用してアップグレードを開始する前に、アップグレード前情報ツールを実行することを強くお薦めします。DBUAでは、前提条件の確認の一部としてアップグレード前情報ツールが実行されますが、事前にこのツールを実行することは、データベースを分析し、アップグレード時の停止時間を短縮可能なアクションを実行するためにお薦めします。詳細および手順は、「Oracle Databaseのアップグレード前情報ツールの概要」を参照してください。

- アップグレード時にアーカイブ・ログをONに設定します。DBUAによってアップグレード処理のログ・ファイルが作成および更新されるように、アーカイブ・ログをONに設定することをお薦めします。

- データベース・インスタンスが実行されていない場合、DBUAはインスタンスを起動しようとします。インスタンスが起動され、実行されている場合、DBUAはそのインスタンスに接続します。

- Oracle RACでは、DBUAを使用してクラスタ・データベースをアップグレードする場合は、CLUSTER_DATABASE初期化パラメータの設定をTRUEのままにする必要があります。

- DBUAを使用せずに手動でデータベースをリストアする場合は、DBUAを起動する前にORACLE_HOME/cfgtoollogs/dbua/logs/ディレクトリにあるWelcome_SID.txtファイルを削除します。このファイルが存在すると、DBUAでは、この操作が再実行操作であると認識されます。

- Oracle Database Vaultが有効になっている場合、「Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件」を参照してください。

3.2.1.1 アップグレード時のDBUAの停止の概要

アップグレードを中止し、データベースをリストアしない場合は、Oracle Database 12cのサーバーを使用してUPGRADEモードで既存のデータベースを起動するまで、DBUAを再起動できません。データベースをリストアしないかぎり、元のOracle Databaseのサーバーに戻ることはできません。かわりに、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」の説明に従って、手動(コマンドライン)アップグレードを続行する必要があります。

3.2.2 DBUAによるOracle Databaseのアップグレードの処理方法

Oracle Database 12cのソフトウェアをインストールし、既存のOracle Databaseのアップグレードを指定した場合は、DBUAが自動的に起動されます。また、「Oracle Databaseのアップグレードの再実行」に記載されているとおり、インストールの完了後にDBUAを個別で起動することもできます。

アップグレードの実行中、DBUAによって、各コンポーネントのアップグレード処理の進行状況が表示されます。DBUAは、詳細なトレース・ログおよびログ・ファイルを書き込み、後で参照するための完全なHTMLレポートを作成します。セキュリティを強化するために、DBUAは、アップグレード後のデータベースで、新しいユーザー・アカウントを自動的にロックします。その後、DBUAは、新しいOracleホームへの新しい構成ファイル(パラメータ・ファイルおよびリスナー・ファイル)の作成へと進みます。

DBUAは、アップグレード前のすべての手順が完了するまで、アップグレード処理を開始しません。詳細情報および手順の概要とそれらへのポインタが記載されている「Oracle Databaseのアップグレードを準備するための作業」を参照してください。

関連項目:
「DBUAによって起動されるアップグレード・スクリプト」

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

アップグレード時、DBUAは、新しく必要な表領域を自動的に変更または作成し、適切なアップグレード・スクリプトを起動します。

前提条件フェーズでは、DBUAはアップグレード前情報ツール(preupgrd.sql)を実行し、次の論理を使用して新しく必要な表領域を変更または作成します。

- データファイルが自動拡張可能で、十分なディスク領域がある場合、DBUAはアップグレードを続行します。

- データファイルを自動拡張できない場合、ファイルの自動拡張を可能にするようにDBUAから求められます。

- 表領域が自動拡張可能で、MAXSIZE初期化パラメータに調整が必要な場合、DBUAは同じことを要求して、MAXSIZEパラメータを調整します。

- 拡張できるディスク容量がない場合、DBUAはユーザーに領域を作成(データファイルを追加)するよう要求します。DBUAはファイルの作成場所を決定できないため、DBUAによる新しいデータファイルの追加は自動的に行われません。

DBUAは前提条件フェーズで検出された多くの問題に対処します。たとえば、DBUAは正しいタイムゾーン・ファイルが使用されていて、ネットワーク・アクセス制御リストのACLの調整を行うことを確認できます。

アップグレード・フェーズで、DBUAは、アップグレード処理をシリアルではなくパラレルに実行するcatctl.plを実行し、これにより、停止時間を可能なかぎり短縮するためにCPU性能が最適に活用されます。

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

DBUAのグラフィカル・ユーザー・インタフェースを使用したデータベースをアップグレードするための手順は、Oracle Database 12cソフトウェアがインストールされた新しいOracleホームから実行されます。WindowsシステムのDBUAを起動するのは、管理者のみである必要があります(「アップグレード時のWindows認証の概要」を参照してください)。

関連項目:

- ソフトウェアの場所の詳細は、「新しいOracle Databaseソフトウェアのインストール」を参照してください。

- 停止時間を最小化するためのアップグレードの準備の詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。

- 既存のデータベースの移動手順は、「既存の12c Oracleホームからのデータベースの移動」を参照してください。

Linux、UNIXまたはWindowsでDBUAを使用してデータベースをアップグレードするには、次の手順を実行します。

1. dbua実行可能ファイルは、ORACLE_HOME/binディレクトリにあります。新しいデータベース・ソフトウェアがインストールされたOracleホームからDBUAを起動します。

- LinuxまたはUNIXプラットフォームの場合は、Oracle Database 12cの新しいホームで、システム・プロンプトに次のコマンドを入力します。

dbua

- Windowsオペレーティング・システムの場合は、「スタート」→「プログラム」→「Oracle-HOME_NAME」→「Configuration and Migration Tools」→「Database Upgrade Assistant」の順に選択します。

DBUAの「操作を選択」ページが表示されます。

2. DBUAページのヘルプが必要な場合、またはDBUAの詳細を参照する場合は、「ヘルプ」をクリックしてオンライン・ヘルプを開きます。
「次へ」をクリックします。

「データベースの選択」ページが表示され、アップグレード可能なデータベースがリストされます。

ソース・データベースにオペレーティング・システムの認証がない場合は、DBUAによってSYSDBAユーザー名およびパスワードが要求されます。

関連項目:
既存の12.1 Oracleホームから新しい12.1 Oracleホームへのデータベースの移動手順は、「既存の12c Oracleホームからのデータベースの移動」を参照してください。

注意:

- Oracle Database 12c以上では、NTLMプロトコルを使用したWindows NTS認証は、セキュリティの理由からサポートされなくなりましたが、これは、Windowsシステムの認証に影響する可能性があります。Kerberos認証のみがサポートされている認証です。この場合、NTSは、Windows NTドメインおよびWindows NTコントローラを使用するドメインでも動作しません。

- Oracle Database 12c以上では、Oracle Databaseのサービスの実行に、ローカル・システム・アカウントではなく標準のWindowsユーザー・アカウントが使用されますが、これは、Windowsシステムのユーザー・アカウントに影響する可能性があります。この役割の分離によってWindowsでのセキュリティが強化されます。

Windowsシステムでのユーザー・アカウントの管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

3. 「ソース・データベースのOracleホームの指定」ドロップダウン・リストから、Oracle Database 12cにアップグレードするデータベースを選択します。DBUAによって、リリースの情報が表示され、選択したOracleホームに関連付けられているOracle Databaseが選択されます。
一度に1つのデータベースのみを選択できます。データベースがリストに表示されない場合は、etcディレクトリにあるoratabファイルにそのデータベース名のエントリが存在することを確認してください。

SYSDBA権限を所有していないユーザー・アカウントからDBUAを実行する場合は、ユーザー名およびパスワード資格証明を入力して、選択されたデータベースに対するSYSDBA権限を有効にする必要があります。

「次へ」をクリックします。

選択したデータベースがマルチテナント・コンテナ・データベース(CDB)の場合、DBUAによって「プラガブル・データベース」ページが表示されます。「プラガブル・データベース」ページでは、選択したCDBとともにアップグレードされる、CDBに含まれるプラガブル・データベースがリストされます。

「次へ」を再度クリックします。

DBUAによって、データベースの分析およびアップグレード前のチェックが実行され、必要に応じて警告が表示されます。次に、DBUAによるデータベースのチェックの例を示します。

- 空のデータベースのごみ箱。

- 無効なオブジェクト。

- 非推奨となったかサポートが終了した初期化パラメータ。

- タイム・ゾーン・データ・ファイルのバージョン。

DBUAによる分析が終了すると、「前提条件チェック」ページが表示されます。分析の完了までには数分かかります。

4. 「前提条件チェック」ページには、検証と結果、重大度、問題がある場合に結果が修正可能かどうかおよび実行可能なアクションが表示されます。検証結果を選択すると、「修正可能」列に結果が修正可能かどうかが表示されます。「アクション」ドロップダウン・リストには、実行可能なアクションがリストされます。たとえば、DBUAで「修正」を選択すると、問題を修正するためのスクリプトまたはコマンドが実行されます。
「検証」列で結果を選択すると、ページの下部領域に結果に関する情報がDBUAによって表示されます。

- テキスト情報領域で詳細へのリンクをクリックします。詳細情報が含まれた「検証の詳細」ボックスが表示されます。

- 検証エラーまたは警告があり、これらが修正可能な場合は、実行する「アクション」を選択できます。

「次へ」をクリックします。

「アップグレード・オプション」タブが選択された状態の「アップグレード・オプションの構成」ページが表示されます。

5. 「アップグレード・オプション」タブが選択された状態の「アップグレード・オプション」ページには、次のオプションがあります。
アップグレード並列度の選択

「アップグレード並列度」セクションでは、アップグレード処理の並列度を有効にします。このオプションでは、スクリプトおよび処理の実行を同時に処理するために使用可能なCPUの数に基づいて、アップグレードの実行に必要な時間を短縮します。

DBUAはデフォルトで、「アップグレード並列度」をCPUの数またはCPUの数が4つより少ない場合は2に設定します。このデフォルト値は、「並列度」ドロップダウン・リストから新しい値を選択して調整できます。

アップグレード後に無効なオブジェクトを再コンパイル

アップグレード完了後に、すべての無効なPL/SQLモジュールを再コンパイルします。アップグレード後に無効なオブジェクトを再コンパイルする際の並列度を指定します。DBUAでは、再コンパイルの並列度の推奨程度が提供され、これは使用可能なCPUの数より1つ少ない数に設定されます。並列度を利用することで、アップグレード時間を大幅に短縮できます。アップグレード後フェーズでDBUAによる無効なオブジェクトの再コンパイルを行わない場合は、データベースをアップグレードした後に無効なオブジェクトを手動で再コンパイルする必要があります。

タイム・ゾーン・データのアップグレード

このリリースのタイムゾーン・データ・ファイルを更新します。このオプションを選択しない場合は、アップグレード後にタイム・ゾーン構成ファイルを手動で更新する必要があります。

アップグレード前の統計の収集

アップグレード前に統計を収集することにより、アップグレード処理全体の時間が短縮されます。

アップグレード中にユーザーの表領域を読取り専用に設定

表領域を転送する必要があるデータベースをアップグレードしている場合は、選択を解除します。トランスポータブル表領域のファイル・ヘッダーは、書込み可能である必要があります。

診断先

DBUAが診断用に作成した出力の場所です。デフォルトを受け入れるか、フィールドにフルパスを入力するか、または「参照」をクリックして場所に移動することができます。

監査ファイル保存先

DBUAが監査ファイルを保存する場所です。デフォルトを受け入れるか、「参照」をクリックして別の場所に移動します。

(オプション)「カスタムSQLスクリプト」タブをクリックして、アップグレードの前後に実行するカスタムSQLスクリプトを指定します。

「カスタム・スクリプト」ページが表示されます。「カスタムSQLスクリプト」オプションを使用せずに、「次へ」をクリックすることもできます。

6. オプション: 「アップグレード前」および「アップグレード後」フィールドで、実行するカスタムSQLスクリプトの場所を参照します。いずれか1つまたは両方を指定するか、フィールドを空白にしてこのオプションをスキップすることができます。
「次へ」をクリックします。

管理オプション・ページが表示されます。

7. 「管理オプション」ページで、次の管理オプションを選択します。

- Enterprise Manager (EM) Database Expressの構成
Oracle Enterprise Manager Database Expressは、Oracle Database 12cに組み込まれているWebベースのデータベース管理アプリケーションです。EM Expressは、リリース10gおよび11gで使用可能だったDB Controlコンポーネントを置き換えます。EM Database Expressのポート番号(たとえば5502など)を入力します。

- Enterprise Manager (EM) Cloud Controlへの登録
Oracle Enterprise Manager Cloud Controlへの登録では、データベースおよび関連するリスナー、Oracle ASMディスク・グループおよびOracle Clusterwareなどのエンティティを管理対象ターゲットとして追加します。

このオプションを選択した場合は、次の各フィールドに情報を入力する必要があります。

- OMSホスト

- OMSポート

- EM管理ユーザー名

- EM管理パスワード

- DBSNMPユーザー・パスワード

「次へ」をクリックします。

単一インスタンスのデータベースまたはOracle Express Edition (XE)をアップグレードしている場合は、「データベース・ファイルの移動」ページが表示されます。

注意:
Oracle Real Application Clustersのデータベースをアップグレードしている場合は、「データベース・ファイルの移動」ページは表示されません。Oracle RACのアップグレードを続行するには、データベース・ファイルの移動およびネットワークの構成に関係する手順をスキップできます。

Oracle Expressデータベース(Oracle XE)をアップグレードする場合、「データベース・ファイルの移動」画面には、次のように、「グローバル・データベース名」および「SID」フィールドがある「データベース名の変更」が追加で含まれます。

8. 「データベース・ファイルの移動」ページで、オプションを１つ選択します。

- アップグレードの一部としてデータベース・ファイルを移動

- 高速リカバリ領域をアップグレードの一部として移動

Oracle XEデータベースをアップグレードする場合、「グローバル・データベース名」および「SID」を指定する必要があります。「データベース・ファイルの移動」の残りのオプションは、Oracle Databaseの場合と同じです。

注意:
高速リカバリ領域は、バックアップおよびリカバリに関連するファイルを格納するためのディスクの場所で、Oracleによって管理されます。高速リカバリ領域を使用すると、データベース・リカバリ・プロセスのスピード、信頼性および管理性が大幅に向上するため、高速リカバリ領域を構成することを強くお薦めします。「管理オプション」ページでローカル管理を有効にした場合、高速リカバリ領域の場所はOracle Enterprise Managerでも使用されます。

9. 「アップグレードの一部としてデータベース・ファイルを移動」を選択した場合は、データベース・ファイルの記憶域のタイプも構成する必要があります。
「記憶域のタイプ」ドロップダウン・リストで、「ファイルシステム」または「Oracle ASM」を選択します。

- 「ファイルシステム」を選択した場合は、データベース・ファイルがホスト・ファイル・システムに移動されます。

- 「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インストレーション・ガイド』を参照してください。

- ASMCAを使用したOracle ASMインスタンスの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- 「すべてのデータベース・ファイルに対して共通の位置を使用」または「マッピング・ファイルを使用してデータベース・ファイルの位置を指定」のいずれかを選択できます。「ファイルの場所」フィールドで場所を指定するか、場所を参照します。

- 「Oracle Managed Fileの使用」を選択した場合、「REDOログおよび制御ファイルの多重化」をクリックします。「場所」フィールドがある「REDOログおよび制御ファイルの多重化」ダイアログ・ボックスが表示されます。書込み先のオンラインREDOログおよび制御ファイルの場所を入力します。フォルト・トレランスを高めるために、異なるディスクにまたがって分散した複数の場所を使用します。

10. 「アップグレードの一部として高速リカバリ領域を移動」を選択した場合は、記憶域タイプおよび高速リカバリ領域の場所を構成し、この手順の説明に従って、割り当てられるサイズも指定する必要があります。

- データベース・ファイルの移動および高速リカバリ領域の移動オプションは、互いに独立しています。たとえば、Oracle ASMへのデータベース・ファイルの移動を選択して、ファイル・システム上の高速リカバリ領域のままにすることができます。

- 高速リカバリ領域に移動することを選択した場合、DBUAは、既存のアーカイブ済REDOログを新しい場所に物理的に移動しません。かわりに、DBUAは、データベースが新しいOracleホームから起動されたときに、DB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZE初期化パラメータに新しい場所および新しいサイズを設定します。

- Oracle Express EditionのデータベースがOracle Enterprise Editionにアップグレードされた場合は、高速リカバリ領域を構成する必要があります。高速リカバリ領域が現在構成されている場合は現在の設定が保持されますが、この値を上書きできるページが表示されます。

記憶域のタイプ

記憶域のタイプ・リストで、「ファイルシステム」または「Oracle ASM」を選択します。

「ファイルシステム」を選択した場合は、高速リカバリ領域はホスト・ファイル・システムになります。

「Oracle Automatic Storage Management」 (Oracle ASM)を選択した場合は、高速リカバリ領域はOracle ASM記憶域になり、ここは、現在システム上に存在している必要があります。Oracle ASMインスタンスがない場合は、Grid InfrastructureホームからAutomatic Storage Management Configuration Assistant(ASMCA)を使用してインスタンスを作成し、DBUAを再起動できます。

高速リカバリ領域の場所

ホスト・ファイル・システム上またはOracle ASM記憶域上の場所を参照します。

高速リカバリ領域のサイズ

高速リカバリ領域に割り当てるサイズを指定します。デフォルトは1024MBです。

「次へ」をクリックします。

表示される「ネットワーク構成」ページで、リスナーを選択します。

11. 「ネットワーク構成」ページの「リスナーの選択」領域には、「名前」、「ポート」、「Oracleホーム」および「移行」の列がある表が表示されます。リスナー名の左側には、リスナーを選択するためのボックスがあります。
ソースOracleホームから新しくアップグレードされたOracleホームに移行する1つ以上のリスナーを選択します。

1. DBUAによって、選択したリスナーがターゲットOracleホームのlistener.oraファイルに追加され、開始されます。

2. DBUAによって、古い(ソース)listener.oraファイルからアップグレードされたデータベースのエントリが削除されます。

3. DBUAによって、ソースとターゲット両方のOracle Database環境で、listener.oraファイルが再ロードされます。

注意:
他のデータベースが同じリスナーに登録されている場合、リスナーの移行中に、それらの新しいクライアント接続リクエストが影響を受ける可能性があります。

「新規リスナーの作成」を選択して、新規リスナーを作成します。名前およびポート番号を指定します。

「次へ」をクリックします。

DBUAによって、「リカバリ・オプション」ページが表示されます。DBUAは、アップグレード前手順で、リスナーの移行を実行します。

12. 「リカバリ・オプション」ページで、アップグレード処理で問題が発生した場合に使用するリカバリ・メソッドを選択します。
次のリカバリ・オプションおよび構成が使用できます。

- RMANバックアップの使用

- フラッシュバックおよび保証付きリストア・ポイントの使用

- 独自のバックアップおよびリストア計画

RMANバックアップの使用

「新規オフラインRMANバックアップの作成」を選択した場合、「バックアップの場所」フィールドにバックアップの場所へのフル・パスを入力します。

「最新の使用可能なRMANバックアップの使用」を選択し、アップグレードの前にRMANバックアップの作成を選択しなかった場合は、DBUAによって、存在する最新のRMANバックアップのタイム・スタンプが表示されます。このバックアップのリストアに既存のスクリプトの実行を選択するには、タイム・スタンプの隣の「スクリプトのリストア」を選択できます。

フラッシュバックおよび保証付きリストア・ポイントの使用

「新規保証付きリストア・ポイントの作成」を選択すると、DBUAがアップグレード処理に入る前にDBUAによってリストア・ポイントが作成されます。

「データベースをフラッシュバック」を以前に有効化し、フラッシュバック保存ターゲットを使用して高速リカバリ領域を構成した場合は、「使用可能な保証付きリストア・ポイントの使用」を選択して、ドロップダウン・リストから名前付きSCNを選択します。現在のリストア・ポイントの設定は保持されます。必要に応じて、DBUAによって、これらの値を上書きできるページが表示されます。

独自のバックアップおよびリストア計画

独自のバックアップ方法でデータベースをバックアップした場合のみ、このオプションを選択します。この場合、「リストア」では、元のデータベースの設定のみがリストアされます。データベース自体をリストアするには、独自のバックアップ・ユーティリティを使用して作成したバックアップをリストアする必要があります。

注意:
フラッシュバックおよび保証付きリストア・ポイントを利用するには、アップグレードしているデータベースがリリース11.1.0.7以上である必要があり、ソース・データベースで有効化される必要があります。

関連項目:
フラッシュバック・データベースおよび保証付きリストア・ポイントの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

「次へ」をクリックします。

「データベースのアップグレード・サマリー」ページが表示されます。

13. アップグレードを開始する前に、アップグレードに関する情報が「サマリー」ページに表示されます。すべての詳細を表示するには、リストを下にスクロールします。次に例を示します。

- ソース・データベース

- ターゲット・データベース

- プラガブル・データベース

- アップグレード前のチェック

- 初期化パラメータの変更

- タイムゾーンのアップグレード

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

すべての詳細を確認します。次のとおり、「戻る」または「終了」をクリックします。

- 設定内容が間違っている場合は、その設定を修正できるページが表示されるまで「戻る」をクリックします。

- すべて正しい場合は、「終了」をクリックします。

プログレス・バーが表示された「進行状況」ページが表示され、DBUAによってアップグレードが開始されます。「進行状況」ページには、アップグレードの進行にともなって、実行されている手順、継続時間およびステータスが示される表も表示されます。DBUAでは、この時点でアップグレードを取り消す必要がある場合に備えて、「停止」ボタンが提供されています。

CDBルートおよび各PDBシードのアップグレードの終了を介してアップグレードが進むと、「進行状況」ページでは、ステータスが「終了」とマークされます。「アクティビティ・ログ」、「アラート・ログ」および「アップグレード結果」をクリックすると、詳細を表示できます。

14. アップグレードの完了後、「アップグレード結果」ページに、元のデータベースとアップグレードしたデータベースの説明が表示され、初期化パラメータに対して行われた変更が表示されます。このページには、アップグレード後に様々なログ・ファイルが格納されるディレクトリ、およびプラガブル・データベースも表示されます。アップグレード前チェックの詳細を表示するには、下にスクロールします。

15. オプション: アップグレード処理の詳細を確認するには、このログ・ファイルを確認します。DBUAログ・ファイルは、/ORACLE_BASE/cfgtoollogs/dbua/logsにあります。

注意:
HTML版のアップグレード結果も、ログ・ファイル・ディレクトリに保存されます。このHTMLページにあるリンクをクリックすると、ブラウザでログ・ページを表示できます。

アップグレード結果に問題がない場合は、「閉じる」をクリックしてDBUAを終了し、新しくアップグレードしたデータベースを使用します。

16. 第4章「Oracle Databaseのアップグレード後の作業」に示す手順を実行します。

注意:
データベースの不正な使用を防止するために、データベースをアップグレードした直後にすべてのユーザー・パスワードを変更することをお薦めします。
Oracle Database 12cのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。認証構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

3.2.4 アップグレード時のWindows認証の概要

Windowsシステムでは、SYSDBA権限を使用して接続するユーザーは、Windowsのネイティブ認証を利用できます。このユーザーがドメイン・アカウントを使用してOracle Databaseを操作する場合は、ローカル管理権限およびORA_DBAメンバーシップを明示的に付与する必要があります。

以前のリリースとは異なり、Oracle Databaseサービスがローカル・システム・アカウントの権限を使用して実行することが必須ではありません。Oracle DatabaseのサービスをWindowsのユーザー・アカウントを使用して実行できます。データベースに対する認証には、Oracle DatabaseのWindows固有のオペレーティング・システム・グループを使用できます。

関連項目:

- オペレーティング・システムを使用したデータベース管理者の認証の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- Windowsでのデータベース・ユーザーの認証の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

3.2.5 既存の12c Oracleホームからのデータベースの移動

DBUAを使用すると、Oracle Database 12cデータベースを、既存の12cのOracleホームから別の12cのOracleホームに移行できます。

データベースを既存の12cのホームから新しい12cのOracleホームに移動するには、次の手順を実行します。

1. 「DBUAを使用したLinux、UNIXおよびWindowsシステムでのデータベースのアップグレード」の説明に従って、DBUAを起動します。
DBUAが「操作を選択」ページで起動します。

2. 「操作を選択」ページで、「別のリリース12.1 Oracleホームからのデータベースの移動」を選択して「次へ」をクリックします。
「データベースの選択」ページが表示されます。

3. 「データベースの選択」ページで、新しいOracleホームに移動するデータベースを選択します。リリース12cのOracleホームにあるデータベースのみが表示されます。Oracle Database 12cのデータベースがない場合は、移動操作で使用できるデータベースはありません。
「次へ」をクリックします。「データベース・オプションの移動」ページが表示されます。

4. 「データベース・オプションの移動」ページでは、DBUAが作成する診断ログ・ファイルの別の場所を指定でき、オプションで、データベースの移動後に実行するカスタムSQLスクリプト(存在する場合)を指定できます。
「次へ」をクリックします。「データベースの移動サマリー」ページが表示されます。

5. 移動操作のサマリーを確認して、「次へ」をクリックします。DBUAによるデータベースの移動処理が表示される「進行状況」ページが表示されます。

6. 移動処理が完了したら、「終了」をクリックします。

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

-silentコマンドライン・オプションを使用してDBUAを起動すると、DBUAはサイレント・モードで動作します。サイレント・モードでは、DBUAのユーザー・インタフェースは表示されません。メッセージ(情報、エラー、および警告を含む)がDBUAによってORACLE_HOME/cfgtoollogs/dbua/SID/upgradenにあるログ・ファイルに書き込まれますが、ここでnは、DBUAが実行したアップグレードの続き番号を表します。確実にアップグレードを行うために、DBUAによって生成されたログ・ファイルを確認することを強くお薦めします。

サイレント・モードのDBUAを使用してデータベースをアップグレードするには、次の手順を実行します。

- 次のコマンドを発行します。

dbua -silent -sid ORCL &

この例では、データベースの名前はORCLです。

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

Database Upgrade Assistant(DBUA)では、サイレント・モードで実行する場合のコマンドライン・オプションがサポートされています。表3-1に、DBUAでサポートされている様々なオプションおよび対応するパラメータを示します。

注意:
Oracle Databaseのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

表3-1 DBUAのコマンドライン・オプション

オプション

説明

-silent

DBUAがサイレント・モードで動作するように指定します。

-sid SID

アップグレードするデータベースのシステム識別子(SID)を指定します。

-oracleHome home_name

アップグレードするデータベースのOracle Databaseホーム・ディレクトリを指定します。

-oracleBase base_name

アップグレードするデータベースのOracle Databaseベース・ディレクトリを指定します。

-listeners

新しいリリースのOracleホームにリスナーを作成するには、listenrName:lsnrPortを指定します。

-createListeners

データベースを既存のリスナーに登録するには、カンマ区切りのlistenerName:Oracle Homeをリスナーに渡します。以前のリリースのホームのリスナーは、新しいリリースのホームに移行されます。-listeners lsnrName1,lsnrName2を指定すると、DBUAによって指定されたリスナーがGrid Infrastructureホーム(Grid Infrastructureが構成されている場合)、ターゲット・ホームおよびソース・ホームから検索されます。

-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

アップグレードを開始する前に、データベースをバックアップするディレクトリを指定します。

-postUpgradeScripts script [, script ] ...

SQLスクリプトを、カンマで区切ったリストにして指定します。完全なパス名を指定します。このスクリプトはアップグレード後に実行されます。

-initParam parameter=value [, parameter=value ] ...

name=valueの形式で初期化パラメータ値のカンマ区切りのリストを指定します。

-disableArchiveLogMode

アップグレード中のアーカイブおよびフラッシュバック・ロギングをオフにします。

-recompile_invalid_objects true|false

このオプションをTRUEにすると、すべての無効なPL/SQLモジュールが、アップグレードの実行直後にDBUAによって再コンパイルされます。

-degree_of_parallelism number

パラレル再コンパイルに使用するレベルを指定します。

-recoveryAreaDestination directory

すべてのリカバリ・ファイルの宛先ディレクトリを指定します。このオプションが適用されるのは、データ・ファイルを移動する場合、Oracle XEデータベースをアップグレードする、またはOracle Enterprise Managerを構成する場合のみです。

[-localRacSid SID

クラスタ・データベースがOracle Cluster Registryに登録されていない場合は、クラスタ・データベースのローカルSIDを指定します。

-h | -help

DBUAのヘルプを表示します。

3.2.6.2 サイレント・モードでの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 number]
[-recoveryAreaDestination directory] [-h|-help]

3.3 Oracle Databaseのパラレル・アップグレード・ユーティリティの概要

Oracle Database 12cでは、パラレル・アップグレード・ユーティリティ(catctl.pl)が導入されましたが、これにより、特定の順序でアップグレードする必要のないコンポーネントを、CPU性能を活用して同時にアップグレードできます。手動によるアップグレードとDatabase Upgrade Assistant (DBUA)を使用して実行するアップグレードの両方でアップグレード処理を簡易化するための改善を引き続き行います。DBUAおよび手動アップグレード手順では、新しいパラレル・アップグレード・ユーティリティを活用します。パラレル・アップグレード・ユーティリティでは、データベースをアップグレードするために複数のSQLプロセスを使用してデータベース・ディクショナリをパラレルでロードすることによって、アップグレードの実行にかかる合計時間を短縮します。

新しいパラレル・アップグレード・ユーティリティ(catctl.pl)に関連する項目は、次のとおりです。

- 新しいパラレル・アップグレード・ユーティリティ(catctl.pl)を実行するための一般的な手順

- パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ

- パラレル・アップグレード・ユーティリティの使用例

3.3.1 新しいパラレル・アップグレード・ユーティリティ(catctl.pl)を実行するための一般的な手順

パラレル・アップグレード・ユーティリティでは、データ・ディクショナリおよびコンポーネントをパラレルでロードするため、アップグレード全体の時間が短縮されます。パラレル・アップグレード・ユーティリティ(catctl.pl)を起動する前に、アップグレード前に通常行うデータベースのバックアップ手順に従います。また、前提条件として、アップグレード前情報ツール(preupgrd.sql)を実行して、アップグレード処理の前にデータベース管理者が対処する必要のある問題を特定する必要があります。

手動でcatctl.plを実行するための手順の詳細は、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」に記載されています。パラレル・アップグレード・ユーティリティを使用してデータベースをアップグレードするための一般的な手順は次のとおりです。

1. 「アップグレードのためのOracle Databaseのバックアップ」の説明に従って、現行のデータベースをバックアップします。

2. 「新しいOracle Databaseソフトウェアのインストール」の説明に従って、新しいリリースのOracle Database 12cソフトウェアをインストールします。

3. 「Oracle Databaseのアップグレード前情報ツールの概要」に記載されているとおり、アップグレード前情報ツール(preupgrd.sql)がソース・データベースで実行されていることを確認します。

4. ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。

5. アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。

CONNECT / AS SYSDBA

6. データベースをアップグレード・モードで起動します。
マルチテナント・コンテナ・データベース(CDB)の場合:

SQL> alter pluggable database all open upgrade;

非CDBの場合:

SQL> startup upgrade

注意:
UPGRADEキーワードは、アップグレード用に環境を準備する操作を実行します。

起動コマンドでPFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

一度データベースをアップグレード・モードで起動すると、catctl.plスクリプトを実行するまでは、固定ビューへの問合せのみ、エラーにならずに実行できます。catctl.plを実行する前は、他のビューへの問合せやPL/SQLの実行で、エラーが戻されます。

サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。

7. SQL*Plusを終了します。

8. 新しいOracleホームからcatctl.plを実行します。catctl.plを実行可能なパラメータについては、「パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ」を参照してください。
Linuxでは、次のようにcatctl.plを実行します。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql -l

Windowsでは、次のようにcatctl.plを実行します。

cd %ORACLE_HOME%\rdbms\admin
%ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql -l

3.3.2 パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ

表3-2にリストされているパラメータは、catctl.plの起動時に使用できます。catctl.plでのアップグレード・フェーズの処理方法およびその例の詳細は、「パラレル・アップグレード・ユーティリティの使用例」を参照してください。

表3-2 catctl.plパラメータ

パラメータ

説明

-c

アップグレードするPDBを指定します。

このパラメータは包含リストを指定します。たとえば、ここで名前を指定したPDBは含まれます(ここで名前を指定しないすべてのPDBはスキップされます)。

LinuxおよびUNIXの場合(一重引用符を使用):

-c 'PDB1 PDB2'

Windowsの場合(二重引用符を使用):

-c "PDB1 PDB2"

-C

アップグレードしないPDBを指定します。

このパラメータは除外リストを指定します。たとえば、ここで名前を指定したすべてのPDBはスキップされます(他のすべてのPDBはアップグレードされます)。

LinuxおよびUNIXの場合(一重引用符を使用):

-C 'PDB1 PDB2'

Windowsの場合(二重引用符を使用):

-C "PDB1 PDB2"

注意: -cと-Cは相互に排他的です。

-d

処理されるファイルが含まれているディレクトリの場所を指定します。

-e

スクリプトの実行中にecho OFFに設定します。デフォルトはecho ONです。

-i

スプール・ログ・ファイルの作成時に使用する識別子を指定します。

-l

スプール・ログ・ファイルで使用するディレクトリの場所を指定します。デフォルトは現行の作業ディレクトリです。

\adminディレクトリにログ・ファイルを書き込まないことを強くお薦めします。

-M

PDBのアップグレード中に、UPGRADEモード内でCDB$ROOTを維持します。非CDBでは、このパラメータは無視されます。CDBのアップグレード中に、このパラメータ設定を使用すると、CDBおよびそのすべてのPDBがアップグレード・モードになるので、アップグレードにかかる合計の時間を減らすことができます。ただし、CDBおよびそのすべてのPDBのアップグレードがすべて終了するまで、いずれのPDBも取り出すことはできません。デフォルトでは、-Mパラメータ設定を使用しない場合、CDB$ROOTは通常のモードでアップグレードされて再起動し、通常のバックグラウンド処理が開始されます。それぞれのPDBのアップグレード中に、他のPDBのアップグレードが進行中にPDBをオンラインにすることができます。

-n

パラレル操作で使用する処理の数を指定します。

非CDBでは、データベースをアップグレードする時に使用するSQL処理の数を指定します。最大値は8です。最小値は1です。デフォルト値は4です。

CDBでは複数のPDBのアップグレードが同時に処理されます。同時にアップグレードされるPDBの数は、-nパラメータの値よって制御されます。デフォルト値は、CPUの数を2で割った数値です(cpu_count/2).。cpu_countは、24に等しく、12 PDBのアップグレードが同時に実行されているのと同等です。最大値は64です。最小値は4です。最大のPDBアップグレードは同時に32 (64/2)実行され、最少の値は2 (4/2)です。

-N

データベースをアップグレードする時に使用するSQL処理の数を指定します。

非CDBでは、このパラメータは無視されます。

CDBでは、最大値は8です。最小値は1です。デフォルト値は2です。

-p

指定したフェーズを再起動します(再実行では成功したフェーズをスキップします)。

-P

指定したフェーズを停止します。

-s

セッションを初期化するSQLスクリプトを指定します。

-S

パラレルではなく、シリアル・アップグレードを指定します。

-u

ユーザー名を指定し、パスワードを要求します。

-y

フェーズのみを表示します。

-z

catcon.pmのデバッグ情報を戻します。

-Z

catctl.plのデバッグ・トレース情報を戻します。

たとえば、1に設定する場合、-Z 1を入力します。

3.3.3 パラレル・アップグレード・ユーティリティの使用例

catctl.plパラレル・アップグレード・ユーティリティはDBUAと統合されています。ただし、手動のコマンドライン・アップグレードでは、catctl.plを様々なパラメータを指定して実行できます。たとえば、catctl.plをパラレル操作を使用せずにシリアル・モードで実行するには、-Sパラメータを指定します。使用可能なパラメータについては、表3-2「catctl.plパラメータ」を参照してください。

例3-1 選択したパラメータを使用したcatctl.plの実行

catctl.plの起動時に-n 4が使用されている場合、アップグレード処理でcatupgrd0.log、catupgrd1.log、catupgrd2.logおよびcatupgrd3.logが作成されます。アップグレードが成功したか失敗したかを検証する場合は、catupgrd#.logファイルをすべて確認する必要があります。catctl.plを再実行する場合は、別のログ・ディレクトリを指定しないかぎり、以前のログ・ファイルは上書きされます。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -n 4 -l $ORACLE_HOME/diagnostics catupgrd.sql

3.4 非CDBのOracle Databaseの手動でのアップグレード

Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームを準備したら、DBUAではなく、手動のコマンドライン・アップグレードに進むことができます。

この項の手順では、Oracleマルチテナント・コンテナ・データベース(CDB)ではないOracle Databaseのアップグレードのステップについて説明します。この手順は、Oracle Database 12cのソフトウェアをインストールし、新しいOracleホームを準備し、アップグレード前情報ツールを実行済であることを想定しています。手順の詳細は、「新しいOracle Databaseソフトウェアのインストール」および「アップグレードのための新しいOracleホームの準備」を参照してください。

関連項目:
マルチテナント・アーキテクチャの概要については、『Oracle Database概要』を参照してください。

非CDBのデータベースを手動でアップグレードするには、次の手順を実行します。

1. まだ実行していない場合は、「Oracle Databaseのアップグレード前情報ツールの概要」の記載に従って、アップグレード前情報ツールを実行します。次に進む前に、アップグレード前情報ツールの出力を確認して、出力に記載されているすべての問題を修正します。問題の修正の詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。

2. 「アップグレードのためのOracle Databaseのバックアップ」の説明に従って、ソース・データベースをバックアップします。

3. まだ実行していない場合は、「アップグレードのための新しいOracleホームの準備」の記載に従って、新しいOracleホームを準備します。

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

SQL> SHUTDOWN IMMEDIATE

5. ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。

1. アップグレードするデータベースのOracleサービスOracleServiceSIDを停止します(SIDはインスタンスの名前です)。たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。

C:\> NET STOP OracleServiceORCL

2. コマンド・プロンプトで、ORADIMを使用してOracleサービスを削除します。詳細は、「WindowsでOracle Databaseのアップグレード時に使用するORADIMの変数」を参照してください。ORADIMの構文およびコマンドの完全なリストは、ご使用のプラットフォームのガイドを参照してください。
SIDがORCLの場合、次のコマンドを入力します。実際のSIDの名前で置き換えます。

C:\> ORADIM -DELETE -SID ORCL

3. 次の例に示すとおり、新しいOracle DatabaseリリースのORADIMコマンドをコマンド・プロンプトで使用して、Oracle Database 12cのサービスを作成します。

C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS
-STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

ほとんどのOracle Databaseサービスは、Oracleホーム・ユーザーの権限を使用してシステムにログオンします。サービスは、このユーザーの権限を使用して実行されます。ORADIMコマンドは、このユーザー・アカウントのパスワードを要求します。ORADIMを使用して、他のオプションを指定できます。

この例で、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ディレクトリにログが書き込まれます。ログ・ファイルには、マルチテナント・データベース内のPDBの名前が含まれています。

6. ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の内容を確認します。

1. ORACLE_SIDが正しく設定されていること。

2. oratabファイルがOracle Database 12cのOracleホームを指していること。

3. 次の環境変数がOracle Database 12cのディレクトリを指していること。

- ORACLE_HOME

- PATH

4. ORACLE_HOME値を設定するためにクライアントで使用するすべてのスクリプトが、新しいOracleホームを指している必要があります。

注意:
クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。

関連項目:
ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関する詳細は、オペレーティング・システム固有の『Oracle Databaseインストレーション・ガイド』を参照してください。

7. 新しいOracle Database 12cのOracleホームの所有者として、システムにログインします。

8. ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。

9. アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。

SQL> CONNECT / AS SYSDBA

10. SQL*Plusで次のコマンドを発行して、インスタンスを起動します。

SQL> startup upgrade pfile=pfile_name

注意:
UPGRADEキーワードを使用すると、前のOracle Databaseリリースをベースとするデータベースをオープンできます。また、AS SYSDBAセッションへのログオンの制限、システム・トリガーの無効化、およびアップグレードの環境を準備するその他の操作も実行されます。

初期化パラメータ・ファイルPFILEの場所を指定します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。

11. SQL*Plusを終了したら、次の手順に進みます。

12. この手順の説明に従って、新しいOracleホームからcatctl.plスクリプトを実行します。パラレル・アップグレード・ユーティリティ(catctl.pl)によって、停止時間を短縮するパラレル・アップグレード・オプションが提供されています。
Linuxでは、次のようにcatctl.plを実行します。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql

Windowsでは、次のようにcatctl.plを実行します。

cd %ORACLE_HOME%\rdbms\admin
%ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql

注意:

- -dオプションを使用して、処理されるファイルが含まれているディレクトリを指定でき、-lオプションで、スプール・ログ・ファイルに使用するディレクトリを指定できます。catctl.pl -Sを使用して、アップグレード処理をシリアルに実行できます。すべてのオプションについては、表3-2、「catctl.pl Parameters」を参照してください。

- catupgrd.sqlスクリプトを非CDBで実行することを選択した場合、現在は、次のように、追加の入力パラメータが必要です。

SQL> @catupgrd.sql PARALLEL=NO

関連項目:
catctl.plパラメータおよびオプションの詳細は、「新しいパラレル・アップグレード・ユーティリティ(catctl.pl)を実行するための一般的な手順」を参照してください。

13. catctl.plを実行すると、アップグレードしたデータベースは停止されます。インスタンスを再起動して、通常の操作用にシステム・パラメータを再初期化します。

SQL> STARTUP

catctl.plスクリプトの一部としてデータベースが停止された後のこの再起動では、すべてのキャッシュがフラッシュされ、バッファが消去されて、その他のハウスキーピング・アクティビティが実行されます。これらの操作は、新しくアップグレードしたOracle Databaseソフトウェアの整合性と一貫性を保証するための重要な最終手順です。

注意:
手順11でデータベースを起動したときに、サポートが終了した初期化パラメータがリストされているメッセージが表示された場合は、再起動の前にサポートが終了した初期化パラメータをパラメータ・ファイルから削除します。ファイルを編集してパラメータを削除するために、必要に応じてSPFILEをPFILEに変換します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

14. 重要: catuppst.sqlスクリプトは、アップグレード処理中にエラーが戻されないかぎり、アップグレードの一部として実行されます。ログ・ファイルで「Rem BEGIN catuppst.sql」を検索して、アップグレード処理中にcatuppst.sqlが実行されたことを確認します。
catuppst.sqlが実行されていない場合は、この手順に示されているcatuppst.sqlの実行に進みます。catctl.plを実行すると、アップグレード中にcatuppst.sqlが実行されなかったことを示す警告メッセージも表示されます。

次のようにcatuppst.sqlを実行します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catuppst -d '''.''' catuppst.sql

ログ・ファイルcatuppst0.logは、アップグレード後の結果を記録して生成されます。

15. catcon.plを実行して、utlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql

ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。

16. postupgrade_fixups.sqlを実行します。「postupgrade_fixups.sqlスクリプトの実行」を参照してください。

17. utlu121s.sqlを実行して、すべての問題が修正されたことを確認します。

SQL> @rdbms/admin/utlu121s.sql

ログ・ファイルutlu121s0.logは、アップグレード結果を記録して生成されます。

データベースの状態に関する情報を確認するには、アップグレードの完了後、いつでも何回でもutlu121s.sqlを実行できます。utlu121s.sqlスクリプトからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、詳細を「Oracle Databaseのアップグレードのトラブルシューティング」で確認してください。

18. 予測されるすべてのパッケージおよびクラスが有効であることを確認します。(この手順は、アップグレードを開始する前にpreupgrd.sqlが実行済であることを前提としています。)

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utluiobj -d '''.''' utluiobj.sql

ログ・ファイルutluiobj0.logは、検証の結果を記録して生成されます。

注意:
アップグレード前情報ツールでINVALIDオブジェクトが検出され、registry$sys_inv_objs表およびregistry$nonsys_inv_objs表に移入された場合は、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行して、アップグレード処理の結果、新しく無効になったオブジェクトのみを表示します。このutluiobj.sqlスクリプトを実行すると、アップグレード前はVALIDであったが、現在はINVALIDであるオブジェクトのみが表示されます。「アップグレード前情報ツール(preupgrd.sql)の使用方法」を参照してください。

19. SQL*Plusをまだ起動している場合は終了します。

20. リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。

$ srvctl upgrade database -d db-unique-name -o oraclehome

ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、oraclehomeは、データベースがアップグレードされるOracleホームの場所です。SRVCTLユーティリティでは、以前のリリースで使用されていた短いCLIオプションに加えて、GNUスタイルの長いオプションもサポートされます。

これで、データベースがOracle Database 12cにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。

注意:
Oracle Warehouse Builder(OWB)コンポーネントはOracle Databaseアップグレード処理の一部としてアップグレードされません。Oracle Warehouse Builderは、Oracle Database 12cの一部としてインストールされません。詳細は、「Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件」を参照してください。

注意:

古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。また、古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置してください。データ・ファイルの再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。

3.4.1 WindowsでOracle Databaseのアップグレード時に使用するORADIMの変数

Windowsプラットフォームでは、ORADIMによって、Windowsデータベースおよびサービスの管理作業を手動で実行するためのコマンドライン・インタフェースが提供されています。Database Configuration Assistant (DBCA)では、同じ作業を実行するためのグラフィカル・ユーザー・インタフェースが提供されています。Oracle Databaseのアップグレード時に知っておく必要のあるORADIMの変数には、アップグレード対象のデータベースのSID、新しいOracleホームの場所および新しいデータベース・インスタンスのパスワードが含まれます。また、ORADIMによって、ORACLE_HOME\databaseディレクトリにログが書き込まれます。

次の表に、アップグレード時にORADIMを使用するための変数を示します。

ORADIM変数

説明

SID

アップグレードするデータベースのSIDと同じSID名。

PASSWORD

新しいOracle Database 12cデータベース・インスタンスのパスワード。SYSDBA権限で接続するユーザー用のパスワードです。-SYSPWDオプションは必須です。
Oracle Database 12cのデフォルトのセキュリティ設定では、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

USERS

SYSDBA権限およびSYSOPER権限を付与できるユーザーの最大数。

ORACLE_HOME

Oracle Database 12cのOracleホームの場所。-PFILEオプションを使用して、Oracleホームの場所のドライブ文字を含む、フルパス名を指定する必要があります。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

関連項目:
ORADIMを使用したデータベース・インスタンスの管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

3.5 マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード

Oracle Database 12cでは、Oracle Databaseをプラガブル・データベースを含むマルチテナント・コンテナ・データベース(CDB)として機能させることができるマルチテナント・アーキテクチャが導入されています。CDBをアップグレードできるため、CDB内のすべてのプラガブル・データベースを同時にアップグレードします。Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームを準備したら、DBUAではなく、手動のコマンドライン・アップグレードに進むことができます。

この項の手順では、CDBのアップグレードのステップについて説明します。この手順は、Oracle Database 12cのソフトウェアをインストールし、新しいOracleホームを準備し、アップグレード前情報ツールを実行済であることを想定しています。手順の詳細は、「新しいOracle Databaseソフトウェアのインストール」および「アップグレードのための新しいOracleホームの準備」を参照してください。

CDBのデータベースを手動でアップグレードするには、次の手順を実行します。

1. まだ実行していない場合は、「Oracle Databaseのアップグレード前情報ツールの概要」の記載に従って、アップグレード前情報ツールを実行します。次に進む前に、アップグレード前情報ツールの出力を確認して、出力に記載されているすべての問題を修正します。問題の修正の詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。

2. 「アップグレードのためのOracle Databaseのバックアップ」の説明に従って、ソース・データベースをバックアップします。

3. まだ実行していない場合は、「アップグレードのための新しいOracleホームの準備」の記載に従って、新しいOracleホームを準備します。

4. データベースを停止します。(構文は、非CDBとCDBで同じです。)

SQL> SHUTDOWN IMMEDIATE

注意:
PDBを閉じるには、CDBルートから次のように指定できます: alter pluggable database PDBname close

5. ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。

1. アップグレードするデータベースのOracleサービスOracleServiceSIDを停止します(SIDはインスタンスの名前です)。たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。

C:\> NET STOP OracleServiceORCL

2. コマンド・プロンプトで、ORADIMを使用してOracleサービスを削除します。詳細は、「WindowsでOracle Databaseのアップグレード時に使用するORADIMの変数」を参照してください。ORADIMの構文およびコマンドのリストは、ご使用のプラットフォームのガイドも参照してください。
SIDがORCLの場合、次のコマンドを入力します。実際のSIDの名前で置き換えます。

C:\> ORADIM -DELETE -SID ORCL

3. 次の例に示すとおり、新しいOracle DatabaseリリースのORADIMコマンドをコマンド・プロンプトで使用して、Oracle Database 12cのサービスを作成します。

C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS
-STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

ほとんどのOracle Databaseサービスは、Oracleホーム・ユーザーの権限を使用してシステムにログオンします。サービスは、このユーザーの権限を使用して実行されます。ORADIMコマンドは、このユーザー・アカウントのパスワードを要求します。ORADIMを使用して、他のオプションを指定できます。

この例で、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ディレクトリにログが書き込まれます。ログ・ファイルには、マルチテナント・データベース内のPDBの名前が含まれています。

6. ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の内容を確認します。

1. ORACLE_SIDが正しく設定されていること。

2. oratabファイルがOracle Database 12cのOracleホームを指していること。

3. 次の環境変数がOracle Database 12cのディレクトリを指していること。

- ORACLE_HOME

- PATH

4. ORACLE_HOME値を設定するためにクライアントで使用するすべてのスクリプトが、新しいOracleホームを指している必要があります。

注意:
クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。

関連項目:
ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関する詳細は、オペレーティング・システム固有の『Oracle Databaseインストレーション・ガイド』を参照してください。

7. 新しいOracle Database 12cのOracleホームの所有者として、システムにログインします。

8. ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。

9. アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。

SQL> CONNECT / AS SYSDBA

10. アップグレード・モードでCDBを開始します。

SQL> startup upgrade

11. SQL*Plusで次のコマンドを発行して、インスタンスを起動します。

SQL> alter pluggable database all open upgrade;

注意:
UPGRADEキーワードを使用すると、前のOracle Databaseリリースをベースとするデータベースをオープンできます。また、AS SYSDBAセッションへのログオンの制限、システム・トリガーの無効化、およびアップグレードの環境を準備するその他の操作も実行されます。

初期化パラメータ・ファイルPFILEの場所を指定します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。

12. SQL*Plusを終了したら、次の手順に進みます。

13. CDB全体をアップグレードするには、この手順の説明に従って、新しいOracleホームからcatctl.plスクリプトを実行します。パラレル・アップグレード・ユーティリティ(catctl.pl)によって、停止時間を短縮するパラレル・アップグレード・オプションが提供されています。
Linuxでは、次のようにcatctl.plを実行します。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql

Windowsでは、次のようにcatctl.plを実行します。

cd %ORACLE_HOME%\rdbms\admin
%ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql

注意:

- -dオプションを使用して、処理されるファイルが含まれているディレクトリを指定でき、-lオプションで、スプール・ログ・ファイルに使用するディレクトリを指定できます。catctl.pl -Sを使用して、アップグレード処理をシリアルに実行できます。すべてのオプションについては、表3-2、「catctl.pl Parameters」を参照してください。

- catupgrd.sqlスクリプトを非CDBで実行することを選択した場合、現在は、次のように、追加の入力パラメータが必要です。

SQL> @catupgrd.sql PARALLEL=NO

- CDB全体をアップグレードするとき、CDBルートまたはPDBシードにエラーがある場合、アップグレードは中断します。

- catupgrd.sqlをCDBで実行するには、すべてのPDBに対してCDB$ROOTおよびPDB$SEEDで実行する必要があります。次に例を示します。

SQL> ALTER SESSION SET CONTAINER = "CDB$ROOT"
SQL> catupgrd.sql PARALLEL=NO
SQL> ALTER SESSION SET CONTAINER = "PDB$SEED"
SQL> catupgrd.sql PARALLEL=NO
SQL> ALTER SESSION SET CONTAINER = "PDB1"
SQL> catupgrd.sql PARALLEL=NO

関連項目:
catctl.plパラメータおよびオプションの詳細は、「新しいパラレル・アップグレード・ユーティリティ(catctl.pl)を実行するための一般的な手順」を参照してください。

14. CDB内のPDBのサブセットをアップグレードするために、この手順の例に示すように、包含リストまたは除外リストのいずれかを指定できます。

1. PDB1のみをアップグレードするための包含リストは、次のとおりです。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -c 'PDB1' catupgrd.sql

2. PDB1を除くCDB内のすべてをアップグレードするための除外リストは、次のとおりです。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -C 'PDB1' catupgrd.sql

注意:
特定のPDBを切断してからCDBに接続することにより、そのPDB自体でアップグレードすることもできます。これは、「プラガブル・データベース(PDB)のアップグレード」で説明しています。
Windowsでは、CDBルート名およびPDBシード名を引用符で囲んだ-Cオプションを指定する必要があります。たとえば、次のようになります。

... -C "CDB$ROOT PDB$SEED"

15. 重要: catuppst.sqlスクリプトは、アップグレード処理中にエラーが戻されないかぎり、アップグレード処理の一部として実行されます。ログ・ファイルで「Started: catuppst.sql」を検索して、アップグレード処理中にcatuppst.sqlが実行されたことを確認します。catuppst.sqlが実行されていない場合は、この手順に示されているcatuppst.sqlの実行に進みます。catctl.plを実行すると、アップグレード中にcatuppst.sqlが実行されなかったことを示す警告メッセージも表示されます。
次のようにcatuppst.sqlを実行します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catuppst -d '''.''' catuppst.sql

ログ・ファイルcatuppst0.logは、アップグレード後の結果を記録して生成されます。

16. catcon.plを実行して、utlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql

ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。

17. utlu121s.sqlを実行して、すべての問題が修正されたことを確認します。
CDBの場合:

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlu121s -d '''.''' utlu121s.sql

非CDBの場合:

SQL> @rdbms/admin/utlu121s.sql

ログ・ファイルutlu121s0.logは、アップグレード結果を記録して生成されます。

データベースの状態に関する情報を確認するには、アップグレードの完了後、いつでも何回でもutlu121s.sqlを実行できます。utlu121s.sqlスクリプトからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、詳細を「Oracle Databaseのアップグレードのトラブルシューティング」で確認してください。

18. 予測されるすべてのパッケージおよびクラスが有効であることを確認します。(この手順は、アップグレードを開始する前にpreupgrd.sqlが実行済であることを前提としています。)

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utluiobj -d '''.''' utluiobj.sql

ログ・ファイルutluiobj0.logは、検証の結果を記録して生成されます。

注意:
アップグレード前情報ツールでINVALIDオブジェクトが検出され、registry$sys_inv_objs表およびregistry$nonsys_inv_objs表に移入された場合は、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行して、アップグレード処理の結果、新しく無効になったオブジェクトのみを表示します。このutluiobj.sqlスクリプトを実行すると、アップグレード前はVALIDであったが、現在はINVALIDであるオブジェクトのみが表示されます。「アップグレード前情報ツール(preupgrd.sql)の使用方法」を参照してください。

19. この時点で、タイムゾーン・データ・ファイルが現行のものであることを確認できます。タイムゾーンを更新する必要がある場合、CDB$ROOTとPDBデータベースの両方のタイムゾーンを更新する必要があります。この調整は、アップグレード後に行うこともできます。
「Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード」を参照してください。

20. (たとえば非CDBなどで)SQL*Plusをまだ起動している場合は終了します。

21. リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。

$ srvctl upgrade database -d db-unique-name -o oraclehome

ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、oraclehomeは、データベースがアップグレードされるOracleホームの場所です。SRVCTLユーティリティでは、以前のリリースで使用されていた短いCLIオプションに加えて、GNUスタイルの長いオプションもサポートされます。

これで、データベースがOracle Database 12cにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。

注意:
Oracle Warehouse Builder(OWB)コンポーネントはOracle Databaseアップグレード処理の一部としてアップグレードされません。Oracle Warehouse Builderは、Oracle Database 12cの一部としてインストールされません。詳細は、「Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件」を参照してください。

注意:

古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。また、古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置してください。データ・ファイルの再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。

3.6 データ・ディクショナリのアップグレード方法およびステータスの表示方法

Oracle Database 12cでは、アップグレード処理およびアップグレードされたデータベースのアップグレード・ステータスの表示方法が改善されました。

次の各項目では、データ・ディクショナリのオブジェクトのパフォーマンスとステータスに影響する変更について説明します。

- データ・ディクショナリのパラレル・アップグレード

- アップグレード・ステータスの設定に対する変更

- utlrp.sql再コンパイル・スクリプト実行後のステータスの変更

3.6.1 データ・ディクショナリのパラレル・アップグレード

現在、Oracle Databaseのデータ・ディクショナリのアップグレードは、catctl.plユーティリティを使用してパラレルで行われますが、これによりアップグレード処理が高速化されます。1つのSQL処理がデータ・ディクショナリをロードするのではなく、CPU性能に応じて複数の処理が可能になりました。catctl.plユーティリティによってデータがディクショナリに可能なかぎり高速にロードされ、アップグレード・モードではなく通常モードで実行可能な作業を遅らせます。この方法によるデータベースのアップグレードでは、全体の停止時間が短縮されます。

3.6.2 アップグレード・ステータスの設定に対する変更

アップグレード完了時にエラーがない場合は、データベースのステータスはUPGRADEDに設定されます。この動作は、アップグレード後にデータベースのステータスがVALIDに設定されていた以前のリリースとは異なります。UPGRADEDステータスは、データ・ディクショナリが、エラーなくロードされたことを示します。エラーがregistry$errorに記録されている場合、アップグレードのステータスはINVALIDに設定されます。

3.6.3 utlrp.sql再コンパイル・スクリプト実行後のステータスの変更

Oracle Databaseの以前のリリースでは、データベースのアップグレード後のVALIDは、データ・ディクショナリのすべてのオブジェクトが再コンパイルされ、使用の準備ができたことを意味しました。Oracle Database 12cでは、VALIDステータスを取得することは異なります。utlrp.sqlスクリプトを通常モードで実行し、データ・ディクショナリのオブジェクトを再コンパイルしてそのデータ・ディクショナリをUPGRADEDステータスからVALIDステータスに移動します。

データベースのアップグレードが有効かどうかは、アップグレード後、アップグレードされたデータベースが最初に起動される前にutlrp.sqlが実行されるまで保証できません。アップグレードの実行後にutlrp.sqlを実行しないと、データ・ディクショナリのオブジェクトの再コンパイルが最初のアクセス中に強制されます。データベースに最初にアクセスするユーザーは、この時点で無効な各オブジェクトがアクセスされることによるパフォーマンス・ヒットの影響を受けます。無効なオブジェクトの再コンパイルが完了すると、通常の処理に戻ります。utlrp.sqlを実行すると、アップグレード後にデータベースを使用する準備が整います。検出されたエラーは、ただちにレポートされ、アップグレードしたデータベースのユーザーが問題に遭遇する前に修正できます。

3.7 以前のリリースのOracle Databaseでのcatupgrd.sqlスクリプトの概要

Oracle Databaseの以前のリリースでは、アップグレードの処理にcatupgrd.sqlアップグレード・ユーティリティを使用していました。Oracle Database 12cからは、catupgrd.sqlを置換し、パラレル処理モードとシリアル・モードの両方が提供されるcatctl.plパラレル・アップグレード・ユーティリティを使用することを強くお薦めします。catupgrd.sqlに関する情報は、任意のカスタム・スクリプトとの下位互換性またはアップグレードで使用する処理について、この項で説明します。catupgrd.sqlスクリプトは、Oracle Database 12c環境から実行する必要があります。

注意:
catupgrd.sqlを単独で実行した場合は、catuppst.sqlはアップグレード処理の一部として実行されません。catuppst.sqlスクリプトは、catupgrd.sqlの完了後に実行する必要があります。

関連項目:
以前のアップグレード・ユーティリティの実行の詳細は、「catupgrd.sqlスクリプトの非推奨および新しいcatctl.plユーティリティの導入」を参照してください。

catupgrd.sqlスクリプトを実行すると、特定のデータ・ディクショナリ表を作成して変更します。また、新しいOracle Database 12cデータベースの次のデータベース・コンポーネントも、アップグレードまたはインストールされます。

- 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

- Oracle Text

- Oracle Spatial and Graph

- Oracle Data Mining

- Oracle Label Security

- Messaging Gateway

- Oracle Database Vault

- Oracle Application Express

3.8 catuppst.sqlスクリプトの概要

catuppst.sqlスクリプトでは、アップグレード中に情報メッセージおよびログ・ファイルが生成されます。DBUAおよびcatctl.plではcatuppst.sqlは自動的に実行されます。手動アップグレード中にエラーが発生した場合は、このスクリプトを個別に実行します。

ORACLE_HOME/rdbms/adminディレクトリにあるcatuppst.sqlスクリプトは、データベースをUPGRADEモードにする必要のない、残りのアップグレード操作を実行します。また、このスクリプトは、最新のOracleパッチ・セット更新(PSU)を自動的に適用します。

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_PDB_name.log

3.9 データベースのトランスポートおよびアップグレードについて(フル・トランスポータブル・エクスポート/インポート)

Oracle Data Pumpのフル・トランスポータブル・エクスポート/インポート機能では、2つのオプションが提供されています(詳細は、『Oracle Database管理者ガイド』を参照)。次の2つのオプションがあります。

- ファイルベースのOracle Data Pumpエクスポート/インポートの使用

- ファイルベースでないネットワーク・モードのOracle Data Pumpインポートの使用

関連項目:

- エクスポート・ダンプ・ファイルを使用したデータベースのトランスポートの詳細は、『Oracle Database管理者ガイド』を参照してください。

- ネットワークを介したデータベースのトランスポートの詳細な手順は、『Oracle Database管理者ガイド』を参照してください。

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

データベースのアップグレード時に発生する可能性のあるエラーや問題について、トラブルシューティングのヒントを提供しています。今回のリリースに影響する重要な変更について、第8章「Oracle Database 12cで非推奨となった機能とサポートが終了した機能」を必ず確認してください。

この項には次のトピックが含まれます:

- Oracle Databaseのアップグレード・モードでの起動の概要

- 異なるORACLE_HOME所有者でのDBUAの実行

- Oracle Databaseのアップグレード・スクリプトの終了エラー

- 無効なオブジェクト警告およびDBAレジストリ・エラー

- 無効なオブジェクトおよびアップグレード後ツールの不完全な使用

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

- Oracle DatabaseでのSQL*Plusエディション・セッションの起動エラー

- Oracle Database索引のORA-01408に対する手動の回避策

- リリース11.1.0.7データベースでのDBCAプロセスに対するエラーORA-00018

- エラーORA-00020 utlrp.sqlの実行中に処理の最大数が超過する

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

- サーバーの再起動後のアップグレードの継続(ADVM/ACFSドライバ・エラー)

- アップグレード後の状態ツールのコンポーネント・ステータスの理解

- アップグレード後のOracle ASMパスワード・ファイルの場所の調整

- エラーORA-27248: sys.dra_reevaluate_open_failuresが実行されています

- Oracle Databaseエンタープライズ・ユーザー・セキュリティ、OLS-OIDおよびプロビショニング・プロファイルのエラー

- utl32k.sqlおよびMAX_STRING_SIZEでの32K移行エラー

- CRSがすべてのノードで停止した場合のASMでのローリング移行状態の喪失

- データ型のバージョニングによるバージョン間のレプリケーション(ORA-26656)

- Oracle XML DBエラーORA-64123およびORA-14097

関連項目:
「Oracle Databaseのアップグレードの再実行」

3.10.1 Oracle Databaseのアップグレード・モードでの起動の概要

一度データベースをアップグレード・モードで起動すると、catctl.plスクリプトを実行するまでは、固定ビューへの問合せのみ、エラーにならずに実行できます。アップグレード・スクリプトを実行する前は、他のビューへの問合せやPL/SQLの実行で、エラーが戻されます。

この項に記載されているエラーは、新しいOracle Database 12cデータベースの起動を試みると発生する可能性があります。これらのエラーの一部はアラート・ログに記録され、セッションには表示されません。いずれかのエラーが表示された場合、 SHUTDOWN ABORTコマンドでデータベースを停止し、問題を修正します。

- ORA-00401: パラメータcompatibleの値はこのリリースではサポートされません。
COMPATIBLE初期化パラメータが11.0.0未満に設定されている場合。

- ORA-39701: データベースをUPGRADEまたはDOWNGRADE用にEXCLUSIVEでマウントしてください
CLUSTER_DATABASE初期化パラメータがFALSEではなく、TRUEに設定されている場合。

- ORA-39700: データベースは、UPGRADEオプションを使用してオープンしてください
UPGRADEキーワードを指定しないでSTARTUPコマンドを発行した場合。

- Ora-00704: ブートストラップ障害

関連項目:
My Oracle Support (http://support.oracle.com)の「Ora-00704、Ora-39700: Database Must Be Opened With Upgrade Option」(Doc ID 1349722.1)

- ORA-00336: ログ・ファイルのサイズxxxxが最小値8192より小さくなっています
REDOログのサイズが4MB未満の場合。

サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。

3.10.2 異なるORACLE_HOME所有者でのDBUAの実行

データベースをアップグレードする際、DBUAはソース(12cより前)のOracleホームと宛先(新規の12c)のOracleホームを同じユーザーが所有していることを想定しています。ご使用の環境でこれが該当しない場合は、データベース・ファイルの権限を変更し、DBUAに追加のパラメータを渡す必要があります。そうしないと、DBUAの「前提条件チェック」ページに「upgrade.xml not found」エラーが表示され、アップグレードを続行できなくなります。

- まず、すべてのデータベース・ファイル(データ・ファイル、REDOファイル、制御ファイル、アーカイブ・ログ宛先、リカバリ領域、Spfileおよびパスワード・ファイル)が新しい12cと12cより前の両方のバイナリ所有者によって読取りおよび書込み可能であることを確認します。これは、両方のユーザーを同じグループ(oinstallなど)に置き、このグループにすべてのデータベース・ファイルへの読取り/書込みアクセスを付与することによって行うことができます。

- -logdirコマンドライン・スイッチを指定してDBUAを実行し、12cと12cより前の両方のバイナリ所有者が書込みできるディレクトリ(/tmpなど)を指定します。DBUAはこのディレクトリを使用してアップグレード前情報ツール(12cより前のバイナリ所有者が実行する12cより前のインスタンスで実行します)からの出力、および12cのバイナリ所有者によってアップグレード時に生成されるDBUAログを格納します。

- たとえば、コマンドラインで次のようにDBUAを実行します。

dbua -logdir /tmp

3.10.3 Oracle Databaseのアップグレード・スクリプトの終了エラー

アップグレードの開始前にアップグレード前情報ツールを実行しなかった場合、catctl.plおよびcatupgrd.sqlスクリプトが次のエラーで終了します。

ORA-00942: table or view does not exist
ORA-00904: "TZ_VERSION": invalid identifier
ORA-01722: invalid number

これらのエラーのいずれかが発生した場合は、SHUTDOWN ABORT文を発行します。次に、元のOracleホーム・ディレクトリに戻し、「Oracle Databaseのアップグレード前情報ツールの概要」の記載に従って、アップグレード前情報ツール(ultu121i.sql)を実行します。

3.10.4 無効なオブジェクト警告およびDBAレジストリ・エラー

アップグレードを開始する前に、アップグレード前情報ツール(preupgrd.sql)を実行することを強くお薦めします。

アップグレード前情報ツールは、無効なSYSおよびSYSTEMオブジェクトと他の無効なオブジェクトを識別します。utlrp.sqlを使用して、無効なオブジェクトを再コンパイルします。アップグレード前にこの処理を実行できない場合、アップグレードを開始する前に無効だったシステムのオブジェクトおよびアップグレードの結果として無効になるオブジェクトを判別することが難しくなります。

3.10.5 無効なオブジェクトおよびアップグレード後ツールの不完全な使用

アップグレードが完了するまで、新しいOracle Database 12.1リリース(utlu121s.sql)のアップグレード後ステータス・ツールを実行しないでください。

アップグレード・プロセスが完了し、utlrp.sqlを実行した後にのみ、アップグレード後ステータス・ツールを実行することをお薦めします。@utlrp.sqlを実行する前にアップグレード後ステータス・ツールを実行すると、ツールの出力に正確な最終コンポーネント・ステータス値が表示されない場合があります。utlrp.sqlを実行する前にツールを実行すると、コンポーネント・ステータス値に最終状態が適切に反映されない場合があります。utlrp.sqlの実行後にのみ、最終コンポーネント状態を決定できます。

3.10.6 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.

問題の根本原因を特定し、アップグレードを続行するための適切な対処を行います。アップグレード中にこの問題が発生しないようにするには、アップグレードを開始する前に、高速リカバリ領域内の使用可能な領域を増やします。

3.10.7 Oracle DatabaseでのSQL*Plusエディション・セッションの起動エラー

アップグレード・スクリプトまたはSQL*Plusで実行するコマンドでEDITIONパラメータを設定すると、それ以降はOracle Databaseが適切に起動できなくなり、エラー「SP2-1540: Oracle Databaseはエディション・セッションでは起動できません。」がスローされます。この問題を回避するには、このパラメータが変更されるcatugrd.sqlまたはSQL*Plusセッションを実行した後に、そのSQL*Plusセッションを終了し、別のセッションでそのインスタンスを再起動します。

3.10.8 Oracle Database索引の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 indexed

回避策として、REPCAT$_AUDIT_COLUMN_IDX1索引を削除し、「Oracle Databaseのアップグレードの再実行」の説明に従って再度アップグレードを実行します。

3.10.9 リリース11.1.0.7データベースでのDBCAプロセスに対するエラーORA-00018

Oracle Grid Infrastructureを使用していてOracle RACリリース11.1.0.7データベースを作成する場合、セッション処理に対するDBCAのデフォルトを増やす必要がある場合があります。Oracle Database 12cでは、処理に対するDBCAのデフォルトの値は300に設定されています。以前のリリースでは、DBCAのデフォルト設定値は150でした。

エラー・メッセージ「ORA-00018:maximum number of session exceeded」が表示された場合は、DBCAのセッション処理に対するデフォルト値を300に変更します。その後、DBCAは、Oracle Grid Infrastructureリリース12.1で使用するリリース11.1.0.7データベースの作成に成功します。

3.10.10 エラーORA-00020 utlrp.sqlの実行中に処理の最大数が超過する

このエラーは、使用するOracle構成にリコンパイルに必要な数のプロセスがないことを示します。ドキュメントを参照して、PROCESSESパラメータの設定に関する詳細を確認します。

関連項目:
Oracle Databaseリファレンス

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

Oracle Database 12cにアップグレードした後、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の警告の概要」の説明に従ってタイムゾーンのバージョンを更新し、「Oracle Databaseのアップグレードの再実行」の説明に従ってアップグレードを再実行します。

3.10.12 サーバーの再起動後のアップグレードの継続(ADVM/ACFSドライバ・エラー)

Windowsプラットフォームでは、アップグレード中にサーバーが再起動した場合に、ADVMドライバまたはACFSドライバ関連のエラーが発生する可能性があります。次のエラー・メッセージが表示されることがあります。

「ACFS-9427: ADVM/ACFSドライバのアンロードに失敗しました。システムの再起動をお薦めします。」または「ACFS-9428 ADVM/ACFSドライバのロードに失敗しました。システムの再起動をお薦めします。」

原因: これらのエラーがアップグレード中に表示される場合の原因は、ADVMドライバおよびACFSドライバが使用中であり、システムを再起動して新しいドライバを開始する必要があります。

処置: 次の手順に記載されている手順を完了します。

最初のノード(アップグレードを開始したノード)以外のノードで、次の手順を実行します。

1. エラーが発生したノードを再起動します。

2. そのノード上で、rootスクリプトを再度実行します。

最初のノード(アップグレードを開始したノード)で、次の手順を実行します。

1. クラスタ内のその他すべてのノードのアップグレードを完了します。

2. 最初のノードを再起動します。

3. 最初のノード上で、rootスクリプトを再度実行します。

4. アップグレードを完了するには、rootでログインし、パスGrid_home/cfgtoollogs/configToolAllCommandsにあるスクリプトconfigToolAllCommandsを実行します。

関連項目:
クラスタのアップグレードの問題のトラブルシューティングの詳細は、使用しているオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

3.10.13 アップグレード後の状態ツールのコンポーネント・ステータスの理解

utlu121s.sqlアップグレード後の状態ツールには、アップグレード後に、データベース・コンポーネントの状態が表示されます。このツールは、アップグレード後にいつでも(アップグレード後または無効なオブジェクトの再コンパイル後)、utlrp.sqlを使用して実行できます。サマリー・レポートの例は、「アップグレード後の状態ツール(utlu121s.sql)のアップグレード・サマリー・レポートのサンプル」に記載されています。

次のリストでは、表示される可能性のある状態の値を簡単に説明します。

- INVALID
アップグレードの完了時に、コンポーネントの一部のオブジェクトが無効でした。コンポーネントのアップグレード中にエラーが発生しなかった場合は、アップグレード全体を再実行しなくても、utlrp.sqlを実行することで、状態がVALIDに変わる可能性があります。utlrp.sqlを実行した後に、DBA_REGISTRYビューを確認します。「Oracle Databaseのアップグレード用スクリプト」を参照してください。

- VALID
コンポーネントは有効で、エラーがありません。

- LOADING
コンポーネントはロード中です。

- LOADED
コンポーネントは正常にロードが終了しました。

- UPGRADING
コンポーネントはアップグレードの処理中です。

- UPGRADED
コンポーネントはアップグレードが完了し、エラーがありません。

- DOWNGRADING
コンポーネントはダウングレードの処理中です。

- DOWNGRADED
コンポーネントはダウングレードが完了し、エラーがありません。

- REMOVING
コンポーネントは削除の処理中です。

- REMOVED
データベースから削除されたため、コンポーネントはアップグレードされませんでした。

- OPTION OFF
コンポーネントに必要なサーバー・オプションがインストールされていないか、またはサーバーとリンクされていません。V$OPTIONビューおよびインストール・ログを確認します。コンポーネントをインストールするか、必要なオプションをサーバーに再リンクしてから、catctl.plを再実行します。「Oracle Databaseのアップグレード用スクリプト」を参照してください。

- NO SCRIPT
コンポーネント・アップグレード・スクリプトがORACLE_HOMEに見つかりませんでした。インストール・ログを確認し、コンポーネント・ソフトウェアをインストールし、catctl.plを再実行します。「Oracle Databaseのアップグレード用スクリプト」を参照してください。

関連項目:
「アップグレード・ステータスの設定に対する変更」

3.10.13.1 アップグレード後の状態ツール(utlu121s.sql)のアップグレード・サマリー・レポートのサンプル

アップグレード後の状態ツールによって、アップグレード・サマリー・レポートが作成されます。例3-2「アップグレード後の状態ツールのアップグレード・サマリー・レポート」に示すように、アップグレード・サマリー・レポートには、データベース内のすべてのコンポーネントのステータスが含まれています。例は、マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)のレポートを示しています。

アップグレードが完了すると、レポートのコピーは、次のいずれかの場所に配置されます。

1. $ORACLE_BASE/cfgtoollogs/db-unique-name/upgrade/upg_summary.rpt

2. $ORACLE_HOME/cfgtoollogs/db-unique-name/upgrade/upg_summary.rpt

3. $ORACLE_HOME/rdbms/logs/upg_summary.rpt

場所は、utlu121s.sqlがレポートの作成に使用する順序で示されます。最初のディレクトリ・スキームの下にレポートを作成できない場合、2番目、3番目の場所で試行してから、レポートの書込みをこれ以上試行しなくなります。

例3-2 アップグレード後の状態ツールのアップグレード・サマリー・レポート

Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 20:37:07
.                             CDB$ROOT:1
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:14:26
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:05:50
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:01
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:01:19
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:11
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:59
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:32
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:01:40
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:21
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:03:43
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:13
Post Upgrade
.                                                                00:01:25
Final Actions
.                                                                00:00:15
Total Upgrade Time: 00:31:47

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.11
.
Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 21:00:02
.                             PDB$SEED:2
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:13:19
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:02:24
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:01
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:00:51
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:06
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:40
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:11
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:00:48
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:11
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:01:41
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:12
Post Upgrade
.                                                                00:01:19
Final Actions
.                                                                00:00:01
Total Upgrade Time: 00:22:24

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.08
.
Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 21:24:16
.                             CDB1_PDB1:3
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:13:05
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:03:01
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:02
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:01:01
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:06
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:45
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:15
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:00:55
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:17
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:01:59
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:10
Post Upgrade
.                                                                00:01:18
Final Actions
.                                                                00:00:01
Total Upgrade Time: 00:23:33

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.12
.
Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 21:27:03
.                             CDB1_PDB2:4
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:14:01
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:03:11
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:02
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:01:05
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:07
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:49
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:12
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:00:54
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:15
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:02:03
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:13
Post Upgrade
.                                                                00:01:18
Final Actions
.                                                                00:00:01
Total Upgrade Time: 00:24:51

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.11
.
Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 21:49:18
.                             CDB1_PDB3:5
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:13:57
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:03:01
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:02
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:01:07
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:07
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:46
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:12
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:00:58
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:13
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:02:10
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:13
Post Upgrade
.                                                                00:01:17
Final Actions
.                                                                00:00:01
Total Upgrade Time: 00:24:42

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.10
.
Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 21:51:15
.                             CDB1_PDB4:6
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:13:41
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:02:48
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:04
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:00:58
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:07
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:40
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:15
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:00:50
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:16
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:02:04
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:15
Post Upgrade
.                                                                00:01:16
Final Actions
.                                                                00:00:01
Total Upgrade Time: 00:23:54

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.08
.
Oracle Database 12.1 Post-Upgrade Status Tool           06-12-2014 22:08:18
.                             CDB1_PDB5:7
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.2.0  00:09:42
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.2.0  00:02:31
Oracle Real Application Clusters
.                                    OPTION OFF      12.1.0.2.0  00:00:01
Oracle Workspace Manager
.                                         VALID      12.1.0.2.0  00:00:52
Oracle Label Security
.                                         VALID      12.1.0.2.0  00:00:05
Oracle XDK
.                                         VALID      12.1.0.2.0  00:00:42
Oracle Text
.                                         VALID      12.1.0.2.0  00:00:13
Oracle XML Database
.                                         VALID      12.1.0.2.0  00:00:44
Oracle Database Java Packages
.                                         VALID      12.1.0.2.0  00:00:12
Oracle Multimedia
.                                         VALID      12.1.0.2.0  00:01:44
Oracle Database Vault
.                                         VALID      12.1.0.2.0  00:00:12
Post Upgrade
.                                                                00:01:08
Final Actions
.                                                                00:00:01
Total Upgrade Time: 00:18:44

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.08
.

3.10.14 Standard Editionの初期データベースおよびステータスがOPTION OFFのコンポーネント

Standard Edition(SE)の初期データベースをアップグレードする場合、初期データベースに付属していないコンポーネントは、Standard Editionにインストールされていないオプションが必要となるため、SEサーバーでアップグレードできません。

アップグレード後、コンポーネントをDBA_REGISTRYビューで参照すると、STATUSの値がOPTION OFFと表示され、関連付けられたコンポーネント・スキーマに無効なオブジェクトが含まれます。Database Upgrade Assistant(DBUA)には、これらのコンポーネントのアップグレードが失敗したことが表示されます。

3.10.15 アップグレード後のOracle ASMパスワード・ファイルの場所の調整

Grid Infrastructureのアップグレード後、srvctl config asmを起動すると、コマンド出力にはOracle ASMパスワード・ファイルの場所は表示されません。パスワード・ファイルの場所は、新しいOracle ASMディスク・グループに自動的には渡されません。SRVCTLがアップグレード後のパスワード・ファイルの場所を特定できるようにするには、ディスク・グループの互換性の設定を拡張し、ディスク・グループにPWFILEを作成する必要があります。SRVCTLは、共有PWFILEの構成済の場所を報告するようになります。

ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』の手順を参照してください。

3.10.16 エラーORA-27248: sys.dra_reevaluate_open_failuresが実行されています

データベースのアップグレード時に、DBUAで障害が発生してエラー「ORA-27248: sys.dra_reevaluate_open_failuresが実行されています」が表示された場合、実行中のジョブDRA_REEVALUATE_OPEN_FAILURESが原因でアップグレードが失敗しています。このジョブが停止していることを確認する必要があります。

ジョブ定義でALLOW_RUNS_IN_RESTRICTED_MODEがTRUEに設定されている場合、このモード中にジョブの所有者がログインを許可されていると、データベースが制限またはアップグレード・モードのときにジョブの実行が許可されます。デフォルト設定はFALSEです。

次の問合せを使用して、実行されている可能性があるジョブの状態を確認できます。

SQL> select OBJECT_NAME, Owner, OBJECT_TYPE from dba_objects whereobject_name like '%DRA_REEVA%';

3.10.17 Oracle Databaseエンタープライズ・ユーザー・セキュリティ、OLS-OIDおよびプロビショニング・プロファイルのエラー

OLSを使用するデータベースおよびスタンバイ・データベースをアップグレードすると、ORA-16000 (データベースは読取り専用アクセスでオープンされています。)が表示される場合があります。スイッチオーバー後、プロビショニング・プロファイルは新しいプライマリの接続情報で更新される必要があります。そうしないと、ポリシーは新しいスタンバイ(古いプライマリ)への適用を続行し、ORA-16000で失敗します。Oracle Databaseリリース10g (10.1)以上からOracle Database 12cへのアップグレードに必要な追加の手順の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

3.10.18 utl32k.sqlおよびMAX_STRING_SIZEでの32K移行エラー

初期化パラメータMAX_STRING_SIZEがEXTENDEDに設定されたが、32K移行がutl32k.sqlスクリプトの実行を完了していない場合、エラーが生成されます。データベース・アップグレードは、次のエラーで終了します。

SELECT TO_NUMBER('32K_MIGRATION_NOT_COMPLETED')
*
ERROR at line 1:
ORA-01722: invalid number

データベース・アップグレードではutl32k.sqlスクリプトを自動的に実行せず、32K移行を実行しません。

アップグレードおよびアップグレード後の32K移行を完了するには、次の手順を実行します。

1. 初期化パラメータMAX_STRING_SIZEをSTANDARDにリセットします。

2. UPGRADEモードでデータベースを再起動します。

3. DBUAを使用するか、手動の手順でアップグレードを再実行します。

4. データベースをアップグレードした後で、初期化パラメータMAX_STRING_SIZEをEXTENDEDに設定します。

5. UPGRADEモードでデータベースを再起動します。

6. ../rdbms/admin/utl32k.sqlを実行します。

アップグレードされたデータベースでは32K移行を完了し、EXTENDEDパラメータがサポートされます。

3.10.19 CRSがすべてのノードで停止した場合のASMでのローリング移行状態の喪失

Cluster Ready Services (CRS)がすべてのノードで停止した場合、Oracle Automatic Storage Management (Oracle ASM)ではローリング移行状態が失われます。Oracle Databaseリリース11.2.0.2で、リリース12.1.0.2にアップグレードされる4つのノード(node1、node2、node3およびnode4)の次のシナリオを考えてみます。

- node1およびnode2は12.1.0.2にアップグレードされ、実行中です。

- node3およびnode4は11.2.0.2のままで、実行中です。

- すべてのCRSスタックがダウンしている停止があると考えます。クラスタは異機種状態のままです(つまり、11.2.0.2に2ノード、12.1.0.2に2ノード)。

アップグレードを続行するには、リリース11.2.0.2のノード(つまり、node3またはnode4、あるいはその両方)のみを起動する必要があり、次のコマンドを実行する必要があります: 12.1.0.2ノードの起動前のnode3またはnode4のOracle ASMインスタンスでのALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'コマンド。

前述の手順を実行してOracle ASMクラスタをローリング移行に戻す前に、クラスタ内の異なるバージョンの2つのノードを起動できないことに注意してください。これを行った場合、Oracle ASMのバージョンの1つがORA-15153またはORA-15163のいずれかのエラー・メッセージで失敗します。

これ以降ですでに記載されているように、アップグレード手順を続行します。

3.10.20 データ型のバージョニングによるバージョン間のレプリケーション(ORA-26656)

リリース12.1.0.2の一部として、Oracleオブジェクト型の属性となるデータ型のバージョニングが導入されました(参照バグ18897657)。この機能により、リリース12.1.0.1データベースとリリース12.1.0.2データベースのバージョン間のレプリケーションは影響を受ける可能性があり、ORA-26656エラーが発生します。

ユーザー定義のオブジェクト型にDATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE、BINARY_FLOAT、BINARY_DOUBLE、NCHAR、NVARCHAR2、NCLOB、ANYDATAなどの属性が含まれている場合、必須パッチ・セット更新18038108をリリース12.1.0.1のすべてのインスタンスに適用する必要があります。

3.10.21 Oracle XML DBエラーORA-64123およびORA-14097

この項で説明する問題は、リリース11.2.0.2のOracle Databaseのアップグレードに関するもののみです。

次のシナリオにより、ALTER TABLE EXCHANGE PARTITION文はエラーで失敗します。

11.2.0.2データベース上で、XMLType表またはパーティション化されたXMLType列を含む表を作成し、その表に構造化XMLIndexを作成します。次に、11.2.0.2データベースをOracle Database 12c以上にアップグレードします。同じ構造と類似のXMLIndexを持つOracle Database 12cデータベースで作成された別のパーティションまたは表とともに、実表のパーティションの1つでALTER TABLE EXCHANGE PARTITION文を実行する場合、次のエラーで失敗します。

ORA-64123: XMLIndex DDL: failure of a recursive DDL
ORA-14097: column type or size mismatch in ALTER TABLE EXCHANGE PARTITION

索引が11.2.0.2以外のデータベースで作成された場合、これは問題ではありません。この問題を持つデータベース・リリースは11.2.0.2のみです。他のデータベース・リリース(11.2.0.1や11.2.0.3など)には、この問題はありません。

回避策は次のとおりです: Oracle Database 12c以上にアップグレードした後で、リリース11.2.0.2から索引をアップグレードした表で構造化XMLIndexを削除および再作成します。

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

Oracle Databaseをアップグレードするときに、DBUAまたはcatctl.plスクリプトを使用して、アップグレード処理を再実行できます。

次の方法を使用して、アップグレードを再実行できます。

- アップグレード(catctl.pl)スクリプトを使用したアップグレードの再実行

- マルチテナント・データベース(CDB)のアップグレードの再実行のオプション

3.11.1 アップグレード(catctl.pl)スクリプトを使用したアップグレードの再実行

catctl.plスクリプトを使用して、アップグレードを再実行できます。「マルチテナント・データベース(CDB)のアップグレードの再実行のオプション」も参照してください。

1. データベースを停止します。非CDBとCDBでは、構文は同じです。

SQL> SHUTDOWN IMMEDIATE

2. UPGRADEモードでデータベースを再起動します。
非CDBの場合:

SQL> STARTUP UPGRADE

CDBの場合:

SQL> STARTUP UPGRADE alter pluggable database all open upgrade;

3. catctl.plを再実行します。

注意:
catctl.plスクリプトは、必要な回数だけ再実行できます。CDBの場合、特定のPDBに対してcatctl.plを再実行できます。たとえば、PDB1という名前のPDBの場合は、次のようになります。

$ORACLE_HOME/perl/bin/perl catctl.pl -n 4 -l $ORACLE_HOME/diagnostics catupgrd.sql -c 'PDB1'

4. utlu121s.sql (アップグレード後の状態ツール)を実行します(これにより、スプール・ログにアップグレードのステータスのサマリーが表示されます)。utlu121s.sqlは、アップグレードの完了前または後のいつでも実行できます。

非CDBの場合:

SQL> @rdbms/admin/utlu121s.sql

CDBの場合:

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlu121s -d '''.''' utlu121s.sql

utlu121s.sqlスクリプトからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、詳細を「Oracle Databaseのアップグレードのトラブルシューティング」で確認してください。

5. 重要: catuppst.sqlスクリプトは、アップグレード処理中にエラーが戻されないかぎり、アップグレード処理の一部として実行されます。ログ・ファイルで「Started: catuppst.sql」を検索して、アップグレード処理中にcatuppst.sqlが実行されたことを確認します。catuppst.sqlが実行されていない場合は、この手順に示されているcatuppst.sqlの実行に進みます。catctl.plを実行すると、アップグレード中にcatuppst.sqlが実行されなかったことを示す警告メッセージも表示されます。
ORACLE_HOME/rdbms/adminディレクトリにあるcatuppst.sqlを、次のとおり実行します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catuppst -d '''.''' catuppst.sql

ログ・ファイルcatuppst0.logは、アップグレード後の結果を記録して生成されます。

6. utlrp.sqlを実行して、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql

ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。

予測されるすべてのパッケージおよびクラスが有効であることを確認します。

単一のPDB (この例ではPDB1)で、次のように標準モードでPDBを開きます。

alter pluggable database PDB1 open;

catcon.plを実行して、PDB内のutlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' -c 'PDB1'
utlrp.sql

非CDBの場合:

SQL> SELECT count(*) FROM dba_invalid_objects;
SQL> SELECT distinct object_name FROM dba_invalid_objects;

CDB全体の場合:

SQL> ALTER SESSION SET CONTAINER = "CDB$ROOT"
SQL> SELECT count(*) FROM dba_invalid_objects;
SQL> SELECT distinct object_name FROM dba_invalid_objects;
SQL> ALTER SESSION SET CONTAINER = "PDB$SEED"
SQL> SELECT count(*) FROM dba_invalid_objects;
SQL> SELECT distinct object_name FROM dba_invalid_objects;
SQL> ALTER SESSION SET CONTAINER = "PDB1"
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であるオブジェクトのみが表示されます。

7. utlu121s.sqlを再度実行して、すべての問題が修正されたことを確認します。
非CDBの場合:

SQL> @rdbms/admin/utlu121s.sql

CDBの場合:

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlu121s -d '''.''' utlu121s.sql

8. SQL*Plusを終了します。

9. リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。

$ srvctl upgrade database -d db-unique-name -o Oracle_home

ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、Oracle_homeは、データベースがアップグレードされるOracleホームの場所です。

これで、データベースがOracle Database 12cにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。

3.11.2 マルチテナント・データベース(CDB)のアップグレードの再実行のオプション

マルチテナント・データベース(CDB)の構成に応じて、アップグレードの再実行に関するいくつかのシナリオがあります。次を行うことができます。

- CDBのアップグレード全体の再実行

- 指定したCDBのみのアップグレードの再実行

- 除外リストを使用した他のPDBがオンライン中のアップグレードの再実行

- CDBまたはPDBを指定するための包含リストを使用したアップグレードの再実行

- -pを使用して失敗したアップグレードを特定のフェーズから再開する

3.11.2.1 CDBのアップグレード全体の再実行

最初の試行中に複数の異なる問題が発生した場合、アップグレード全体を再実行する必要がある可能性があります。この例では、共有プールの不足などの問題が発生した場合の、CDB$ROOT、PDB$SEEDおよびコンテナの再アップグレードを示しています。

1. 再度アップグレードを開始します。

SQL> startup upgrade;
alter pluggable database all open upgrade;

2. 次のようにcatctl.plを実行します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_
HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl catupgrd.sql

CDB$ROOTおよびPDB$SEEDに含まれているすべてのコンテナで、アップグレードが再度実行されます。

3.11.2.2 指定したCDBのみのアップグレードの再実行

指定した1つ以上のマルチテナント・コンテナ(CDB)のみで、アップグレードを再実行できます。これは除外リストを使用して実行できます。除外リストには、アップグレードしないコンテナが含まれています。除外リストは、catctl.plで-Cパラメータ・オプションを使用します。(このパラメータには大文字のCを使用する必要があります。大文字と小文字が区別されます。)この方法は、再アップグレードするPDBが多数ある場合に役立ちます。

この例では、マルチテナント・コンテナ・データベースに5つのPDBが含まれています。CDB1_PDB1およびCDB1_PDB2がアップグレード・エラーで失敗したことを除いて、すべてのアップグレードが成功しました。目的は、CDB1_PDB1およびCDB1_PDB2コンテナのみでアップグレードを実行することです。マルチテナント・データベース全体を停止し、アップグレードするPDBのみを再起動することによって、これを行うことができます。

1. 停止してから、アップグレード・モードで起動します。

SQL> shutdown immediate;
startup upgrade;
alter pluggable database CDB1_PDB1 open upgrade;
alter pluggable database CDB1_PDB2 open upgrade;

2. CDBおよびPDBの状態を表示します。

SQL> show pdbs

CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED                       MIGRATE    YES
3 CDB1_PDB1                      MIGRATE    YES
4 CDB1_PDB2                      MIGRATE    YES
5 CDB1_PDB3                      MOUNTED
6 CDB1_PDB4                      MOUNTED
7 CDB1_PDB5                      MOUNTED

3. アップグレードからCDB$ROOTおよびPDB$SEEDを除いて、アップグレードを再実行します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_
HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl -C 'CDB$ROOT PDB$SEED'
catupgrd.sql

アップグレードはCDB1_PDB1およびCDB1_PDB2で再実行し、完了します。

注意:
Windowsでは、CDBルート名およびPDBシード名を引用符で囲んだ-Cオプションを指定する必要があります。たとえば、次のようになります。
... -C "CDB$ROOT PDB$SEED"

3.11.2.3 除外リストを使用した他のPDBがオンライン中のアップグレードの再実行

この例では、CDB$ROOTは標準モードで起動され、コンテナCDB1_PDB3、CDB1_PDB4およびCDB1_PDB5はオンラインです。この場合、コンテナCDB1_PDB1およびCDB1_PDB2ではアップグレードが失敗しますが、コンテナCDB1_PDB3、CDB1_PDB4およびCDB1_PDB5ではアップグレードが成功します。DBAでは、CDB1_PDB3、CDB1_PDB4およびCDB1_PDB5のアップグレード・ログを確認し、これらの特定のコンテナをオンラインにします。

コンテナCDB1_PDB1およびCDB1_PDB2でアップグレードを再実行するには、次を行います。

1. CDB$ROOTを標準モードで起動し、CDB1_PDB1およびCDB1_PDB2をアップグレード・モードで開きます。CDB1_PDB3、CDB1_PDB4、CDB1_PDB5は標準モードです。例は次のとおりです。

SQL> startup;
alter pluggable database CDB1_PDB1 open upgrade;
alter pluggable database CDB1_PDB2 open upgrade;
alter pluggable database cdb1_pdb3 open;
alter pluggable database cdb1_pdb4 open;
alter pluggable database cdb1_pdb5 open;

2. PDBの状態を表示します。

SQL> show pdbs

CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED                       READ ONLY  NO
3 CDB1_PDB1                      MIGRATE    YES
4 CDB1_PDB2                      MIGRATE    YES
5 CDB1_PDB3                      READ WRITE NO
6 CDB1_PDB4                      READ WRITE NO
7 CDB1_PDB5                      READ WRITE NO

3. アップグレードからCDB$ROOTを除いて、アップグレードを再実行します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_
HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl -C 'CDB$ROOT'
catupgrd.sql

Windowsでは、CDBルート名およびPDBシード名を引用符で囲んだ-Cオプションを指定する必要があります。たとえば、次のようになります。

... -C "CDB$ROOT PDB$SEED"

アップグレードはCDB1_PDB1およびCDB1_PDB2で再実行し、完了します。

3.11.2.4 CDBまたはPDBを指定するための包含リストを使用したアップグレードの再実行

除外リストを使用してアップグレードを再実行するかわりに、包含リストを使用して、アップグレードを再実行するCDBおよび/またはPDBを指定できます。この例に示すように、包含リストは、catctl.plで-cパラメータを使用します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl -c 'CDB1_PDB1 CDB1_PDB2' catupgrd.sql

アップグレードはCDB1_PDB1およびCDB1_PDB2で再実行し、完了します。

3.11.2.5 -pを使用して失敗したアップグレードを特定のフェーズから再開する

catctl.plを使用して、アップグレードを再実行し、実行が成功したアップグレードのフェーズをスキップできます。再開するフェーズの番号を確認するには、アップグレード・ログで最初のエラーが発生した場所とフェーズを特定します。

3.11.2.5.1 失敗したフェーズの非CDBログ・ファイルの表示

ログ・ファイルの範囲は、catupgrd0...catupgrd7.logです。

3.11.2.5.2 失敗したフェーズのCDBログ・ファイルの表示

CDB$ROOT (CDB)のログ・ファイルの範囲は、catupgrd0...catupgrd7.logです。コンテナ(PDB)のログ・ファイルの範囲は、catupgrdpdbname0...catupgradepdbname7.logです。

3.11.2.5.3 失敗したフェーズからのマルチテナント・アップグレードの特定および再開の手順

失敗したフェーズからマルチテナント・アップグレードを再開するには、まずエラーが発生したPDBを特定し、適切なログ・ファイルを検索します。

マルチテナント・アップグレードのエラーの原因のPDBを特定するには、アップグレード・サマリー・レポートを確認するか、catupgrd0.logを参照します。このログ・ファイルの最後に、アップグレード・サマリー・レポートが記載されています。

次の手順に従い、ログ・ファイルをチェックしてエラーを探します。

1. エラーのあるログ・ファイルを特定します。次に例を示します。
LinuxおよびUNIXの場合

$ grep -i 'error at line' catupgrd*.log

Windowsの場合

C:\> find /I "error at line" catupgrd*.log

grepまたはfindコマンドを使用すると、エラーが発見されたログ・ファイルのファイル名が表示されます。

2. エラーのあるログ・ファイルをチェックし、最初のエラーが発生した場所を特定します。任意のエディタを使用して、ログ・ファイルを表示します。最初の文字列「error at line」を検索します。文字列を発見したら、エラーからさかのぼって、PHASE_TIME___STARTを検索します。次に例を示します。

PHASE_TIME___START 15 15-01-16 08:49:41

PHASE_TIME___STARTの後の数字が、エラーの発生したフェーズ番号です。たとえば、フェーズ番号が15だとします。

各ログ・ファイルにエラーがあります。この文字列の検索を繰り返して、すべてのログ・ファイルでエラーのあるフェーズ番号を特定し、フェーズ番号の数字が最も小さい場所を特定します。

最も小さい数字のフェーズ番号を含むログ・ファイルが、再開するフェーズ番号です。このフェーズ番号から、アップグレードを再開します。

次に例を示します。

catupgrd0.logエラーがフェーズ15で発生したとします。

PHASE_TIME___START 15 15-01-16 08:49:41

catupgrd1.logエラーがフェーズ19で発生したとします。

PHASE_TIME___START 19 15-01-16 08:50:01

この例では、フェーズ番号15から再開します。すべてのログ・ファイルを検証して最初のエラーを探し、アップグレードを再開するフェーズを特定してください。

3. -pフラグを使用して再開するフェーズ番号を与えてcatctl.plコマンドを実行するディレクトリに変更し、失敗したフェーズからアップグレードを再開します。マルチテナント・データベースでは、-cフラグを構文-c 'PDBname'のように使用できます。ここでは、PDBnameは、エラーが発生したPDBの名前です。
次に例を示します。

非CDBのOracle Databaseの場合

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -p 15 catupgrd.sql

マルチテナントOracle Database (CDB)内のPDBの場合

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -p 15 -c 'PDB1' catupgrd.sql

いずれの例でも、アップグレードは、-pフラグを使用して特定されたフェーズ15から再開されています。マルチテナントの例では、エラーの発生したPDBは、-cフラグで特定されます。

これらの例で、アップグレードはフェーズ15から再開され、最後までアップグレードが実行されます。

4. (オプション) -Pフラグを使用して停止フェーズを指定することで、エラーを含むフェーズを実行できます。停止フェーズを使用すると、エラーが発生したフェーズのみを再実行できます。アップグレード全体を実行することなく、エラーが発生したフェーズのみで実行することで、エラーが修正されたかどうかを迅速に特定できます。
次のcatctl.plコマンドの例では、アップグレードはフェーズ15で再開され、-Pフラグで指定した停止フェーズであるフェーズ15の最後で停止します。

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -p 15 -P 15 -c 'PDB1' catupgrd.sql

エラーの発生したフェーズでエラーが修正されたことを確認したら、その後のフェーズのアップグレードを中止できます。

たとえば、使用するマルチテナント・データベースのアップグレードPDB1のフェーズ15で発生したエラーが修正されたことを確認したら、次のコマンドを使用してフェーズ16でアップグレードを継続できます。

cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -p 16 -c 'PDB1' catupgrd.sql

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

Oracle Databaseをアップグレードする手順を実行した後は、必要な作業を行い、新しいリリースの推奨事項を考慮する必要があります。

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

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

- Oracle Databaseのアップグレード後のOPatchコマンドの概要

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

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

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

- Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

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

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

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

- Oracle Application Expressパッケージ・アプリケーションのオプションでの更新

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

4.1 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

4.2 Oracle Databaseのアップグレード後のOPatchコマンドの概要

Oracle Databaseをアップグレードした後で、新しいOracleホームからOPatchコマンドを実行する必要があります。たとえば、現在システムにインストールされている正確で完全なインベントリをリストするには、新しいOracleホームからlsinventoryコマンドを実行します。

関連項目:
OPatchの構文およびコマンドは、Oracle OPatchユーザーズ・ガイドfor Windows and UNIXの付録Aを参照してください。

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

アップグレードを手動で行ったかDatabase Upgrade Assistant (DBUA)を使用して行ったかにかかわらず、Oracle Databaseをアップグレードした後、使用環境に指定されている必要な作業を完了する必要があります。

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

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

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

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

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

- Oracle XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成

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

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

- 外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成

- Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

- SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認

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

ご使用のオペレーティング・システムがLinuxまたはUNIXで、かつOracle Databaseを手動でアップグレードした場合は、特定の環境変数が新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。また、クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。

次の環境変数が新しいOracleホームのディレクトリを指していることを確認します。

- ORACLE_HOME

- PATH

注意:
DBUAでは、自動的にOracle環境変数に対して必要な変更が行われます。

関連項目:

- データベースに対する環境変数の設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

- その他の重要な環境変数の設定の詳細は、オペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

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

Oracle Databaseを新しいリリースにアップグレードした後に、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 12cリリース用に作成された新しいOracleホームを指していることを確認する必要があります。DBUAではoratabは自動的に新しいOracleホームを指しますが、アップグレードにどの方法を使用しても、クライアント・スクリプトを確認する必要があります。

関連項目:
オペレーティング・システムの環境変数の設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

4.3.3 新しい拡張データ型機能の有効化

Oracle Database 12cでは、SQLのVARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズを制御するMAX_STRING_SIZEが導入されました。MAX_STRING_SIZE = EXTENDEDを設定することで、Oracle Database 12cで導入された32767バイト制限が有効になります。MAX_STRING_SIZE = EXTENDEDを設定できるようにするためには、COMPATIBLE初期化パラメータを12.0.0.0以上に設定する必要があります。

システムで新しい拡張データ型を使用可能にするには、『Oracle Databaseリファレンス』で説明するように、特定のアップグレードを行う必要があります。MAX_STRING_SIZEの値はSTANDARDからEXTENDEDに変更できます。ただし、MAX_STRING_SIZEの値をEXTENDEDからSTANDARDには変更できません。MAX_STRING_SIZE = EXTENDEDを設定することは、データベースでアプリケーションの非互換性が発生する可能性がある設定を明示的に指定することになります。

関連項目:
MAX_STRING_SIZEの推奨事項および手順などの詳細は、『Oracle Databaseリファレンス』を参照してください。

4.3.4 パラレル実行サーバーの最大値および最小値の調整

Oracle Database 12cでは、PARALLEL_MIN_SERVERSのデフォルトが0からご使用のハードウェア・プラットフォームに応じた値に変更されており、パラレル実行に必要な最低限のサポートが提供されます。ご使用の環境でこの新しいデフォルト設定が高すぎる場合は、要件に合せて設定を調節します。PARALLEL_MAX_SERVERSのデフォルトは変更されていないため、古い環境でデフォルトを変更していない場合は、何もする必要はありません。

関連項目:
PARALLEL_MIN_SERVERSの詳細は、『Oracle Databaseリファレンス』を参照してください。

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

RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。リカバリ・カタログのアップグレードおよびUPGRADE CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

データベースのアップグレードを完了した後、アップグレード前情報ツールによってタイム・ゾーン・ファイルをアップグレードするよう指示された場合は、DBMS_DST PL/SQLパッケージを使用してこのファイルをアップグレードします。

Oracle Databaseでは複数のバージョンのタイム・ゾーン・ファイルが提供されており、互いに関連付けられている2種類のファイルがあります。1つはデータベースで定義されているすべてのタイム・ゾーンを含む大きなファイルで、もう1つは最も一般的に使用されるタイム・ゾーンのみを含む小さいファイルです。大きいバージョンはtimezlrg_version_number.dat、小さいバージョンはtimezone_version_number.datと指定されます。ファイルは、Oracle Databaseホーム・ディレクトリ下のoracore/zoneinfoサブディレクトリにあります。

関連項目:

- 『Oracle Databaseグローバリゼーション・サポート・ガイド』で、タイムゾーン・ファイルおよびTIMESTAMP WITH TIME ZONEデータのアップグレード手順に関する説明を参照してください。

- My Oracle Support (http://support.oracle.com)のNote ID 1509653.1「Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST」

- 「TIMESTAMP WITH TIME ZONEデータ型に対するOracle Databaseの警告の概要」

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

DBMS_STATS.CREATE_STAT_TABLEプロシージャを使用して統計表を作成した場合、次のプロシージャを実行してこれらの表をアップグレードします。

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('green', 'stat_table');

この例で、greenは統計表の所有者で、STAT_TABLEは統計表の名前です。各統計表にこのプロシージャを実行します。

関連項目:
DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

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

Oracle9iリリース2 (9.2)またはOracle Database 10gリリース1 (10.1)からのアップグレード時に、外部認証されたSSLユーザーを使用している場合は、SSL外部ユーザー変換(extusrupgrade)スクリプトを実行してそれらのユーザーをアップグレードする必要があります。スクリプトの構文は次のとおりです。

ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring
host_name:port_no:sid --dbuser <db admin> --dbuserpassword
password -a

注意:
Oracle Database 10gリリース2 (10.2)以上のリリースからアップグレードしている場合は、extusrupgradeスクリプトを実行する必要はありません。

関連項目:
extusrupgradeスクリプトの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

4.3.9 Oracle XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成

Oracle Database 12cでは、Database Creation Assistant (DBCA)によってOracle XML DB用のポートは構成されません。また、改善されたセキュリティ機能を利用するために、Oracle XML DB RepositoryへのアクセスにHTTPの認証を構成する必要もあります。

Oracle Database 12c以上では、ダイジェスト認証のサポートを提供することによって、データベースのセキュリティが向上しました。ダイジェスト認証は、HTTPプロトコルで一般に使用される業界標準のプロトコルで、ほとんどのHTTPクライアントでサポートされています。ダイジェスト認証では、暗号化された(HTTPS)接続が使用されていない場合でも、パスワードは常にセキュアな方法で転送されます。ダイジェスト認証をサポートすることによって、組織では、パスワードの漏えいを心配することなくOracle XML DB HTTPを使用するアプリケーションをデプロイできます。Oracle XML DBでのダイジェスト認証のサポートでは、Oracle XML DB HTTPサーバーとMicrosoft Web Folders WebDAVクライアントとの互換性も引き続き維持されます。

関連項目:
HTTPの認証メカニズムの構成および管理の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

新しいリリースのインストールまたはアップグレード後に、次のようにOracle XML DBのFTPおよびHTTPポートを手動で構成する必要があります。

1. DBMS_XDB_CONFIG.setHTTPPort(HTTPポート番号)を使用して、Oracle XML DBのHTTPポートを設定します。

SQL> exec DBMS_XDB_CONFIG.setHTTPPort(port_number);

2. DBMS_XDB_CONFIG.setFTPPort(FTPポート番号)を使用して、Oracle XML DBのFTPポートを設定します。

SQL> exec DBMS_XDB_CONFIG.setFTPPort(port_number);

注意:
手順内のFTPおよびHTTPで使用するポート番号は、DBMS_XDB_CONFIG.getFTPPortおよびDBMS_XDB_CONFIG.getHTTPPortをそれぞれ使用することによって問い合せることができます。

3. 使用されているすべてのポート番号を確認するには、DBMS_XDB_CONFIG.usedportを使用できます。

関連項目:
FTPおよびHTTP(S)/WebDAVプロトコルを使用したOracle XML DB Repositoryのデータへのアクセスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

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

Oracle Textが提供するナレッジ・ベースはOracle Database 12cの付属製品の一部ですが、Oracle Database 12cへのアップグレード後すぐに使用できるようにはなっていません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースをインストール・メディアからインストールする必要があります。

Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、アップグレード後に再生成する必要があります。これらの変更は、指定されたOracleホームにインストールされているすべてのデータベースに影響します。

関連項目:

- Oracle Textナレッジ・ベースの詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください。

- 付属製品については、ご使用のプラットフォーム固有の『Oracle Databaseインストレーション・ガイド』のインストール後の作業に関する項を参照してください。

4.3.11 AUTO_LEXERを使用したOracle Text索引の再構築

Oracle Database 12cリリース1へのアップグレード完了後に、AUTO_LEXERを使用して作成されたOracle Text索引を使用する場合、問合せを動作させるには、索引を再構築する必要があります。

また、BASIC_LEXERセットの次のINDEX_STEMSタイプを持つ索引を再構築する必要があります。

- ARABIC

- BOKMAL

- CATALAN

- CROATION

- CZECH

- DANISH

- ERIVATIONAL_NEW

- DUTCH_NEW

- ENGLISH_NEW

- FINNISH

- FRENCH_NEW

- GERMAN_NEW

- GREEK

- HEBREW

- HUNGARIAN

- ITALIAN_NEW

- NYNORSK

- POLISH

- PORTUGUESE

- ROMANIAN

- RUSSIAN

- SERBIAN

- SLOVAK

- SLOVENIAN

- SPANISH_NEW

- SWEDISH

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

元のデータベースにOracle Application Expressリリース3.2以上が含まれていた場合は、Oracle Database 12cにアップグレードした後に必要な追加の構成はありません。ただし、レジストリにOracle Application Expressがあり、Oracle Application Expressをアップグレードする場合、open_cursorsパラメータを最低200に設定する必要があります。

データベースはOracle Express EditionデータベースではないがOracle Application Expressの以前のリリースが含まれていた場合は、アップグレード中に最新リリースが自動的にインストールされます。新しいOracle Database 12cと併用するために、インストール後の一連の手順を実行して、Application Expressを構成する必要があります。

関連項目:
Oracle Application Expressのインストール後の作業の詳細は、『Oracle Application Expressインストレーション・ガイド』を参照してください。

データベースがOracle Express Editionデータベースの場合は、Oracle Application Expressの以前のリリースが含まれおり、Oracle Express Edition環境に応じて調整されています。次のURLに用意されている、Oracle Express EditionとOracle Application Expressの相違点を説明したOracleドキュメントを参照してください。

http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html

4.3.13 外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成

Oracle Database 12cには、UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPまたはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。これらのパッケージを使用するアプリケーションがある場合、Oracle Databaseのアップグレード後に、データベースのネットワーク・アクセス制御リスト(ACL)を構成してから、これらのパッケージを前のリリースと同様に動作させる必要があります。ACLがない場合、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」でアプリケーションが失敗する可能性があります。

関連項目:
一部のユーザーはホストAに接続し、別のユーザーはホストBに接続するなど、より複雑な状況については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

4.3.14 Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

Oracle Database Vault (DV)を使用している場合は、データベースをアップグレードする前にこれを無効にするように指示がありました。今度は、Oracle Database Vaultを有効にする必要があります。

アップグレードされたデータベースでOracle DV施行を開始するには、プロシージャdvsys.dbms_macadm.enable_dv()を使用してDVを有効化します。DV_OWNERまたはDV_ADMINロールを持つユーザーのみが、このプロシージャを実行できます。プロシージャを有効にするには、データベース・インスタンスを再起動する必要があります。

関連項目:

- 「Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件」

- 『Oracle Database Vault管理者ガイド』のDatabase Vaultの有効化および無効化に関する付録

- 『Oracle Database Vault管理者ガイド』のDatabase Vaultのインストール後の手順に関する付録

4.3.15 SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認

Oracle Database 12c以上では、SQLNET.ALLOWED_LOGON_VERSIONパラメータのデフォルト値は、8から11に変更されました。このパラメータの使用は非推奨になり、現在はSQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータで置き換えられています。アップグレードされたデータベースでSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを明示的に設定していない場合、リリース10gより前のクライアントからの接続は、エラー「ORA-28040: 一致する認証プロトコルがありません」で失敗します。セキュリティ強化のため、データベース・ユーザーのパスワード検証機能を確認し、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを設定して正しいパスワード検証機能を使用するようにデータベースを構成します。

既存のデータベースにパスワードで保護されたロール(セキュア・ロール)があり、11のデフォルトのSQLNET.ALLOWED_LOGON_VERSION_SERVER設定でOracle Database 12cにアップグレードする(そのセキュア・ロールにはリリース10gの検証機能のみがあるため)場合、アップグレード後もセキュア・ロールが使用可能な状態になるように、管理者は各セキュア・ロールのパスワードをリセットする必要があります。

関連項目:

- パスワードのセキュリティの脅威から守る方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ユーザーのパスワード・バージョンの設定の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- 「SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨」

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

アップグレード後に、環境変数設定が正しいことを確認する必要があります。「Grid Infrastructureのインストールでの環境変数の使用」を参照してください。Oracle ASMは、Oracle Grid Infrastructureのインストールの一部として含まれています。クラスタのOracle ClusterwareとOracle ASMをアップグレードすると、Oracle ClusterwareとOracle ASMは両方ともGridホームと呼ばれる同じホームに配置されます。すべてのOracleソフトウェア・インストールを所有するインストール所有者を1人のみ割り当てることも、ロール割当て済の所有者を使用することもできますが、後者の場合は、Grid Infrastructureインストールに別のソフトウェア所有者、1つ以上のOracle Databaseインストールに別々のソフトウェア所有者を使用します。

関連項目:
ロール割当て済のインストール所有者の詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

4.4.1 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ホーム内のOracle ASMホームのディレクトリを指すように設定します。

- ORACLE_HOME

- PATH

また、oratabファイルおよびORACLE_HOME値を設定するOracle ASMのすべてのクライアント・スクリプトが、Gridホーム内のOracle ASMホームを指していることを確認します。

注意:
クラスタOracle ASMインストールをクラスタ用のOracle Grid Infrastructureにアップグレードする場合は、すべてのクラスタ・メンバー・ノードでこれらを確認してください。DBUAでは、oratabファイルは自動的に新しいOracleホームを指します。クライアント・スクリプトは、アップグレード方法に関係なく、確認する必要があります。

関連項目:

- ご使用のオペレーティング・システムでのその他の重要な環境変数の設定は、オペレーティング・システム固有の『Oracle Databaseインストレーション・ガイド』を参照してください。

- ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』または『Oracle Databaseインストレーション・ガイド』を参照してください。

- Oracle ASMインスタンスのアップグレードの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

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

Oracle Grid Infrastructureバイナリのオペレーティング・システム・ユーザー所有権と1つ以上のデータベースのOracle Databaseインストール所有者を分けた場合は、アップグレードしたOracle ASMまたはデータベースのホームのオペレーティング・システム・ユーザーを移行する必要があります。たとえば、1つのソフトウェア・バイナリ所有者(oracleなど)から複数のロール割当て済のソフトウェア所有者ユーザー・アカウント(grid、oracle1、oracle2など)に移行する場合、既存のOracle ASMインストール所有者を、Oracle Grid Infrastructureインストールで使用する予定のインストール所有者に変更します。

検討する例は次の3つです。

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

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

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

関連項目:
新しいリリースと互換性のあるOracle ASMディスク・グループの作成の詳細とOracle ASMのアップグレードの追加情報は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

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

既存のOracle ASMインストールに使用したのと同じオペレーティング・システム・ユーザーをOracle Grid Infrastructureインストールに使用する場合は、Oracle Universal Installer (OUI)を実行してGrid Infrastructureインストールを実行し、アップグレード・オプションを選択します。OUIによって、Gridホームで、既存のOracle ASMインストールが以前のリリースからOracle Database 12cに自動的にアップグレードされます。

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

以前のリリースのOracle ASMがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合に、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更する必要があるとします。これが役立つのは、Oracle ASMを使用するデータベースが2つあり、既存のデータベースの所有者と同じインストール所有者でOracle ASMをインストールした状態で、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようにOracle ASMのオペレーティング・システム・インストール所有者を変更する必要がある場合です(どちらのOracle Databaseインストール所有者にもOracle Grid Infrastructureバイナリ所有権がない場合)。

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

Oracle RACデータベースのオペレーティング・システム・ユーザーを変更する必要がある場合があります。たとえば、以前のリリースのデータベースがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合は、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更することを検討する必要があります。Oracle Databaseインストール所有者にGrid Infrastructureバイナリ所有権がない場合は、Oracle ASMのオペレーティング・システム・ユーザーを変更すると、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようになります。

関連項目:
Grid InfrastructureおよびOracle ASMを使用するOracle RACデータベースのオペレーティング・システム・ユーザーの変更手順については、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

4.6 Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

Oracle Databaseのアップグレード後に、次のタスクを行うことをお薦めします。これらの作業は、Oracle Databaseの優れた更新手法であり、アップグレードを手動で行ったかDBUAを使用して行ったかにかかわらずお薦めできる方法です。

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

- postupgrade_fixups.sqlスクリプトの実行

- DBMS_STATSを使用した固定オブジェクトの統計の収集

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

- Oracle Grid Infrastructureでの変更の理解

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

- 新機能の適宜追加

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

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

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

- Oracle Data Guard Brokerの構成

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

- アップグレードしたOracle Databaseの統合監査の使用への移行

- アップグレードされた本番Oracle Databaseのテスト

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

必ず本番データベースの全体バックアップを作成してください。この手順は必須ではありませんが、本番データベースをバックアップすることを強くお薦めします。

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

4.6.2 postupgrade_fixups.sqlスクリプトの実行

postupgrade_fixups.sqlスクリプトは、DBUAによってアップグレード・プロセスの一環として実行されますが、アップグレード後にいつでもこれを実行することができます。postupgrade_fixups.sqlスクリプトは、アップグレード対象データベースに対して、一般的な警告、エラーおよび推奨事項の3種類の情報を生成します。

このスクリプトは、DBUAまたは手動でアップグレードを完了した後に、任意の時点で実行します。Oracle_Baseが定義されている場合、生成されたスクリプトおよびログ・ファイルは、アップグレードを実行した元のデータベースのOracle_Base/cfgtoollogs/に作成されます。Oracle_Baseが定義されていない場合、生成されたスクリプトおよびログ・ファイルは、アップグレードを実行したデータベースのORACLE_HOME/cfgtoollogs/に作成されます。

出力を確認するために、結果をログ・ファイルにスプールするようにシステムを設定します。ただし、adminディレクトリにスプールしないでください。(新しくアップグレードされた場所ではなく)アップグレードを実行したデータベースの場所から、スクリプトを実行します。

SQL> SPOOL postupgrade.log

スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

注意:
PDBまたは他のスタンドアロン・データベースをサーバーAからサーバーBに移動する場合、postupgrade_fixups.sqlスクリプトを新しい場所にコピーし、新しい環境でアップグレード後にこれを実行する必要があります。

4.6.3 DBMS_STATSを使用した固定オブジェクトの統計の収集

Oracle Databaseのアップグレードの数日後に、DBMS_STATS.GATHER_FIXED_OBJECTS_STATS PL/SQLプロシージャを使用して固定オブジェクト統計を収集することをお薦めします。これはデータベース全体のパフォーマンスによい影響を及ぼすことがあります。DBMS_STATS.GATHER_FIXED_OBJECTS_STATSでは、init.ora/spfileから非表示またはアンダースコア・パラメータおよびイベントをすべて削除するための推奨事項も表示されます。

x$表の一時性質により、システムで代表的なワークロードがあるときに固定オブジェクト統計を収集することは重要です。統計の収集には追加のリソースが必要になるため、大規模なシステムでは、必ずしもこれが可能はわけではありません。負荷ピーク時にこれを行えない場合は、システムがウォーム・アップされ、固定オブジェクト表のキー・タイプが移入された後に実行する必要があります。

固定オブジェクトの統計を収集するには、次のPL/SQLプロシージャを実行します。

SQL> execute dbms_stats.gather_fixed_objects_stats;

関連項目:
GATHER_FIXED_OBJECTS_STATSプロシージャの使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

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

パスワードでの大/小文字の区別を強制できます。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。

データベースのアップグレード手順で既存ユーザーのパスワードをリセットする必要がある場合は、既存データベースに対して各ユーザーのパスワードをALTER USER文でリセットする必要があります。アップグレード後に新しく作成されたデータベースでは、追加の作業や追加の管理要件はありません。

11.1.0.7より前のリリースでパスワードの大/小文字区別の強制を利用するには、データベースのアップグレード手順で既存のユーザーのパスワードをリセットする必要があります。この場合、データベースのアップグレードでDBMS_VERIFIER.EXPIRE_ACCOUNTS_WITHOUT_LATEST_VERIFIERプロシージャを使用し、これによって、アカウントに最新の検証機能がないユーザーに対して、次回のログイン時にパスワードを変更することが強制されます。その際、サーバーで、アカウントに対して最新の検証機能が生成できます。新しいデータベースの場合は、追加の作業や追加の管理要件はありません。

SYSDBAユーザーおよびSYSOPERユーザーの場合は、新しいコマンドライン・スイッチignorecaseを使用して、新しいORAPWDファイルを生成できます。

注意:

- Oracle Database 12cのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。パスワードの長さの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- IGNORECASEパラメータはこのリリースでは非推奨になりました。このパラメータを使用しないことをお薦めします。

関連項目:
パスワードの大/小文字の区別の有効化の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

4.6.5 Oracle Grid Infrastructureでの変更の理解

Oracle ClusterwareおよびOracle ASMはどちらも、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 Grid Infrastructureインストレーション・ガイド』を参照してください。

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

以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Databaseリリース11.2以上では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされます。Oracle ASMは、Oracle RACとともにクラスタにインストールされた場合はOracle Clusterwareと、スタンドアロン・サーバーにインストールされた場合はOracle RestartとOracleホームを共有します。

関連項目:
詳細情報および手順については、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

4.6.7 新機能の適宜追加

『Oracle Database新機能ガイド』では、新しいOracle Database 12cリリースで使用可能な多くの新機能について説明されています。これらのどの新機能がデータベースおよびアプリケーションに有効かを判断してください。その後、これらの機能を使用する計画を立てることができます。

新しいOracle Databaseソフトウェアを使用するためにすぐに変更する必要はありません。データベースおよびそれに対応するアプリケーションに、これらの拡張機能を徐々に取り入れることもできます。

第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」では、新しいOracle Database 12cリリースの機能を利用するためにアプリケーションを拡張する方法について説明します。ただし、新機能を実装する前にアプリケーションをテストし、アップグレードしたデータベース上でアプリケーションを正常に動作させる必要があります。

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

新しいOracle Database 12cリリースの機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。

それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。

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

アップグレードされたOracle Database 12cデータベースでは、表領域アラートが無効になっています(しきい値がNULLに設定されています)。データベース内の監視対象の表領域を指定し、適切なしきい値を設定する必要があります。

新しく作成されたOracle Database 12cデータベースのデフォルトのしきい値は次のとおりです。

- 警告(表領域の使用率が85%の場合)

- クリティカル(表領域の使用率が97%の場合)

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

データベースがOracle Database 11gより前の場合は、ロールバック・セグメント(手動UNDO管理)を使用してアップグレードしたデータベースを、自動UNDO管理に移行する必要があります。

自動UNDO管理は、デフォルトのUNDO領域管理モードです。システムで使用するUNDO領域管理モードは、次のようにUNDO_MANAGEMENT初期化パラメータで指定します。

- UNDO_MANAGEMENT=AUTOの場合(またはUNDO_MANAGEMENTを設定しない場合)は、データベース・インスタンスは自動UNDO管理モードで起動します。
UNDO_MANAGEMENT初期化パラメータがNULLの場合のデフォルトは、Oracle Database 11gリリース1(11.1)では自動UNDO管理モードですが、前のリリースでは手動UNDO管理モードです。したがって、10.2または11.1のリリースをOracle Database 12cにアップグレードする際は注意が必要です。

- UNDO_MANAGEMENT=MANUALの場合、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構成の場合は、すべてのインスタンスでこれらの手順を繰り返します。

4.6.11 Oracle Data Guard Brokerの構成

DGConnectIdentifierの値は、常時、すべてのData Guardネットワーク・トラフィック用に使用されます。Oracle Databaseリリース10gの構成をアップグレードする場合は、最初にOracle Database 11gにアップグレードする必要があり、InitialConnectIdentifierの値は、そのデータベースのDGConnectIdentifierの新しい値として保持されます。Oracle RACデータベースをアップグレードする場合、データベース管理者は、InitialConnectIdentifierプロパティの値がすべてのインスタンスに到達できることを確認する必要があります。

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

LOBデータ型(BFILE、BLOB、CLOBおよびNCLOB)には、LONGデータ型よりも多くのメリットがあります。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およびラージ・オブジェクト開発者ガイド』を参照してください。

4.6.13 アップグレードしたOracle Databaseの統合監査の使用への移行

統合監査では、すべてのOracle Database監査証跡(データベース監査証跡ではSYS.AUD$、ファイングレイン監査ではSYS.FGA_LOG$、Database VaultではDVYS.AUDIT_TRAIL$など)は、1つの監査証跡にまとめられますが、これは、単一インスタンスのインストールではUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを、Oracle Real Application Clusters環境ではGV$UNIFIED_AUDIT_TRAILを問い合せることによって表示できます。完全な純統合監査機能を使用する場合は、「Oracle Databaseでの統合監査への移行」に従って手動で移行する必要があります。

関連項目:
このリリースでの監査機能の変更の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

この項には次のトピックが含まれます:

- Oracle Databaseでの統合監査の移行プロセスの概要

- Oracle Databaseでの統合監査への移行

- 統合監査への移行後の古い監査レコードの管理

- 統合監査機能の削除

- 統合監査を使用しない場合のドキュメント参照

4.6.13.1 Oracle Databaseでの統合監査の移行プロセスの概要

デフォルトでは、アップグレードされたデータベースでは、統合監査は有効化されていません。以前のリリースからOracle Database 12cアップグレードした場合は、データベースでは以前のリリースで使用していたものと同じ監査機能が使用されています。新しく作成されたデータベースでは、統合監査の混合モードの方式がデフォルトで有効化されます。統合監査への移行が完了すると、従来の監査は無効化され、新しい監査レコードが統合監査証跡に書き込まれます。

監査ポリシーを有効化して使用方法を構成するには、次のように1つの方法を選択します。

- 純統合監査機能を使用。
「Oracle Databaseでの統合監査への移行」に記載されている手順に従って、純統合監査機能を使用します。統合監査への移行手順が完了すると、新しい監査ポリシーを作成および有効化でき、事前定義された監査ポリシーも使用できます。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。以前の監査証跡および監査レコードは保持されますが、新しい監査レコードは以前の監査証跡には書き込まれません。

注意:
以前のリリースの監査構成は、統合監査システムでは効果がありません。統合監査証跡内では、統合監査ポリシーのみが監査レコードを生成します。

- 混合モードの監査機能を使用。
混合モードの監査機能は、従来の監査機能と統合監査機能の両方を同時に実行でき、新しいデータベースとアップグレードされたデータベースの両方に適用されます。混合モードの統合監査機能は、1つ以上の事前定義された統合監査ポリシーを有効化すると使用可能になります。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。Oracle Databaseの以前のリリースでの監査構成も使用可能で、この構成の監査レコードは以前の監査証跡に書き込まれます。純統合監査機能を使用する場合は、「Oracle Databaseでの統合監査への移行」の手順に従って、切り替えることができます。

注意:
データベースが書込み不可な場合、監査レコードは、$ORACLE_BASE/audit/$ORACLE_SIDディレクトリにある新しい形式のオペレーティング・システム・ファイルに書き込まれます。

関連項目:

- 事前定義された監査ポリシーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ora_SecureConfig監査ポリシーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

4.6.13.2 Oracle Databaseでの統合監査への移行

マルチテナント・コンテナ・データベース(CDB)環境で、rootで次の手順を実行します。この手順では、rootとすべての関連付けられたPDBを統合監査に移行します。

データベースを移行して統合監査を有効化するには、次の手順を実行します。

1. SYSDBA権限を持つユーザーSYSとしてSQL*Plusにログインします。

sqlplus sys as sysdba
Enter password: password

プラガブル・データベース環境では、このログインにより、rootに接続されます。

2. 次の問合せを実行して、Oracle Databaseが統合監査に移行されているかどうかを確認します。

SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

VALUE列への出力がTRUEの場合、データベースで統合監査がすでに有効化されています。次の手順については、「統合監査への移行後の古い監査レコードの管理」を参照してください。出力がFALSEの場合は、残りの手順を完了してください。

3. データベースを停止します。単一インスタンス環境では、SQL*Plusから次のコマンドを入力します。

SQL> SHUTDOWN IMMEDIATE
SQL> EXIT

Windowsシステムでは、Oracleサービスを停止します。

net stop OracleService%ORACLE_SID%

Oracle RACインスタンスの場合は、各データベース・インスタンスを次のように停止します。

srvctl stop database -db db_name

4. リスナーを停止します。(Oracle RACおよびGrid Infrastructureリスナーでは、リスナーを停止する必要はありません。)

lsnrctl stop listener_name

lsnrctl statusコマンドを実行すると、リスナーの名前を検索できます。名前は、別名設定で示されます。

5. $ORACLE_HOME /rdbms/libディレクトリに移動します。

6. 統合監査実行可能ファイルを次のように有効にします。

- UNIXでは、次のコマンドを実行します。

make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME

- Windowsでは、%ORACLE_HOME%/bin/orauniaud12.dll.dblファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dllに変更します。

7. リスナーを再起動します。

lsnrctl start listener_name

8. データベースを再起動します。SQL*Plusにログインしてから、次のように、STARTUPコマンドを入力します。

sqlplus sys as sysoper
Enter password: password

SQL> STARTUP

Windowsシステムでは、Oracleサービスを再度起動します。

net start OracleService%ORACLE_SID%

Oracle RACインストールの場合は、次のようにして、各データベース・インスタンスを起動します。

srvctl start database -db db_name

4.6.13.3 統合監査への移行後の古い監査レコードの管理

統合監査を使用するためのOracle Databaseの移行手順が完了すると、データベースで使用していた以前の監査レコードは以前の監査証跡に保持されます。これらの監査レコードをアーカイブして、監査証跡を削除できます。統合監査が使用可能な場合、新しい監査レコードは統合監査証跡に書き込まれます。

関連項目:

- 『Oracle Databaseセキュリティ・ガイド』の監査証跡のアーカイブに関する説明

- 『Oracle Databaseセキュリティ・ガイド』の監査証跡レコードの削除に関する説明

4.6.13.4 統合監査機能の削除

統合監査を使用するためにデータベースを有効化した後に統合監査を使用しないことにした場合は、統合監査機能を削除できます。この場合、「Oracle Databaseでの統合監査への移行」に記載されているとおり、データベースでは混合モードの監査機能が使用されます。

統合監査を削除にするには、次の手順を実行します。

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

sqlplus sys as sysoper
Enter password: password

SQL> SHUTDOWN IMMEDIATE
SQL> EXIT

Windowsシステムでは、Oracleサービスを停止します。

net stop OracleService%ORACLE_SID%

Oracle RACインスタンスの場合は、各データベース・インスタンスを次のように停止します。

srvctl stop database -db db_name

2. $ORACLE_HOME/rdbms/libディレクトリに移動します。

3. 統合監査実行可能ファイルを無効にします。

- UNIXの場合: 次のコマンドを実行します。

make -f ins_rdbms.mk uniaud_off ioracle ORACLE_HOME=$ORACLE_HOME

- Windows: %ORACLE_HOME%/bin/orauniaud12.dllファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dll.dblに変更します。

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

sqlplus sys as sysoper
Enter password: password

SQL> STARTUP
SQL> EXIT

Windowsシステムでは、Oracleサービスを再度起動します。

net start OracleService%ORACLE_SID%

Oracle RACインストールの場合は、次のようにして、各データベース・インスタンスを起動します。

srvctl start database -db db_name

4.6.13.5 統合監査を使用しない場合のドキュメント参照

Oracle Database 12cにアップグレード後に、統合監査に変更しないことを選択した場合は、OracleドキュメントおよびOracle Technology Networkで従来の非統合監査に関する情報を検索できます。

次の場所で非統合監査に関する情報を参照してください。

- Oracle Databaseセキュリティ・ガイド: このガイドは、監査を構成する際の主要な情報源です。このマニュアルのOracle Databaseリリース11gバージョンを使用する必要があります。このガイドにアクセスするには、次の手順を実行します。

1. 次のURLのOracle Technology Networkに移動します。
http://www.oracle.com/technetwork/index.html

2. 「ダウンロード」メニューで、「データベース」の下にある「Database 11g」を選択します。

3. 「ダウンロード」ページで、「ドキュメント」タブを選択します。

4. 最新のOracle Database 11g Release 2 (11.2)の「ドキュメント」ページから、「ライブラリの表示」リンクを選択して、リリース11gドキュメント・セットのホーム・ページを表示します。

5. 「検索」フィールドで、「マスター・ブック・リスト」リンクを選択します。

6. 「セキュリティ・ガイド」を検索します。

7. このガイドの「HTML」または「PDF」リンクのいずれかを選択します。

- Oracle Database SQL言語リファレンス: このガイドでは、統合監査および非統合監査の両方の環境でのAUDIT文およびNOAUDIT文の使用方法について説明しています。

- Oracle Databaseリファレンス: このガイドは、非統合監査環境に関連付けられている初期化パラメータおよびデータ・ディクショナリ・ビューの使用方法について説明しています。これらのリストについては、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- Oracle Database Vault管理者ガイド: このガイドでは、非統合監査環境でDatabase Vaultに対する監査を構成する方法を説明しています。

- Oracle Label Security管理者ガイド: このガイドでは、非統合監査環境でOracle Label Securityに対する監査を構成する方法を説明しています。

4.6.14 アップグレードされた本番Oracle Databaseのテスト

テスト・データベースを新しいOracle Databaseリリースにアップグレードしてテストした場合、新しいOracle Database 12cリリースにアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。

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

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

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

Oracle Real Application Clusters 12cリリース1 (12.1)では、単一クライアント・アクセス名(SCAN)が使用されます。SCANは、パブリック・ネットワークで3つのIPアドレスに解決される単一の名前です。11.2より前のリリースのOracle RACデータベースがアップグレードされると、リモート・リスナーとしてSCANリスナーに登録され、引き続きすべてのノード・リスナーにも登録されます。SCANを使用するか、または引き続きノード・リスナーを使用するようにクライアントを構成できます。SCANを使用するようにすべてのクライアント接続を移行する場合は、REMOTE_LISTENERSパラメータからノード・リスナーを削除できます。ただし、ノード・リスナーのみがデータベースの専用サーバーを作成できるため、リスナー自体を削除することはできません。

関連項目:
単一クライアント・アクセス名(SCAN)の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

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

Oracle ASMのアップグレード後に、Oracle ASMパスワードのリセットおよびディスク・グループの構成などの作業を行うことをお薦めします。

Oracle ASMのアップグレード後に行うことが推奨されている作業は次のとおりです。

- ASMディスク・グループでの共有パスワード・ファイルの作成

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

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

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

次の作業を実行することも検討してください。これらの作業については、この章の前の方で説明しています。

- 「新機能の適宜追加」

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

4.8.1 ASMディスク・グループでの共有パスワード・ファイルの作成

COMPATIBLE.ASMディスク・グループ属性を12.1に拡張した場合、ASMディスク・グループに共有パスワード・ファイルを作成する必要があります。ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

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

パスワードでの大/小文字の区別を強制できます。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。

Oracle Database 11gリリース1 (11.1)より前のリリースでは、パスワードで大文字と小文字は区別されませんでした。パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいOracle ASMインスタンスの場合は、追加の作業や追加の管理要件はありません。アップグレードしたOracle ASMのインスタンスの場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。

注意:
Oracle Databaseのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

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

ソフトウェア・バージョンをまたいで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.2'

この場合、ディスク・グループを管理できるのはリリース11.2以上のOracle ASMソフトウェアのみですが、データベース・クライアントはリリース10.2以上であれば、このディスク・グループを使用できます。

関連項目:
ディスク・グループの互換性の詳細は『Oracle Automatic Storage Management管理者ガイド』を、ALTER DISKGROUP文およびCREATE DISKGROUP文のディスク・グループ互換性属性の詳細は『Oracle Database SQL言語リファレンス』を参照してください。

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

Oracle ASMの管理者は、一部のディスクを他のディスクより優先して読取りI/O操作に使用するよう指定できます。Oracle ASMの優先読取りの障害グループを定義した場合、Oracle ASMでは常にプライマリ・コピーから読み取るのではなく、最も近いエクステントから読み取ることができます。

関連項目:

- 拡張クラスタへの障害グループの設定については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- Oracle ASMの優先読取りの障害グループ、および新しいASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータを指定してクラスタ内の各ノードに優先読取りディスクを含む障害グループ名をリストする方法の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

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

Oracle Database Expressのデータベースに含まれているのは、Oracle Database Standard EditionまたはOracle Database Enterprise Editionのデータベースで使用できるコンポーネントのサブセットのみです。新しいOracle Databaseリリースにアップグレードした後、Database Configuration Assistant (DBCA)を使用して追加のコンポーネントをデータベースにインストールできます。

4.10 Oracle Application Expressパッケージ・アプリケーションのオプションでの更新

元のデータベースにOracle Application Expressバージョン4.2からバージョン4.2.5.00.08までが含まれていた場合は、4.2.5パッチ・セットが適用されていました。しかし、Oracle Application Expressに付属のパッケージ・アプリケーションが、パッチ・セットの適用時に4.2.5バージョンに更新されていませんでした。スクリプトを実行して、パッケージ・アプリケーションを更新する必要があります。Oracle Application Expressが非CDBにインストールされているか、ローカルでPDBにインストールされている場合、ここに示す手順に従ってください。

非CDBでパッケージ・アプリケーションを更新するには、次の手順を実行します。

1. 現行ディレクトリをOracleホームの最上位レベルの"apex"ディレクトリに設定します。

2. SQL*Plusを起動し、Oracle Application Expressをインストールするデータベースに、SYSDBAロールが指定されているSYSとして接続します。
Windowsの場合:

C:\ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password

Linuxの場合:

$ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password

3. 次の例に示すように、apex_pkgapp_ins.sqlを実行します。

@apex_pkgapp_ins.sql

CDBでパッケージ・アプリケーションを更新するには、次の手順を実行します。

1. 現行ディレクトリをOracleホームの最上位レベルの"apex"ディレクトリに設定します。

2. SQL*Plusを起動し、Oracle Application Expressをインストールするデータベースに、SYSDBAロールが指定されているSYSとして接続します。
Windowsの場合:

C:\ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password

Linuxの場合:

$ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password

3. 次の例に示すように、apex_pkgapp_con.sqlを実行します。

@apex_pkgapp_con.sql

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

DBUAを使用せず手動でOracle Databaseのアップグレードを実行している場合は、データベースをアップグレードした後で、必要な作業を実行する必要があります。

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

- ORAPWDを使用したパスワード・ファイルの作成または移行

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

- Oracle Textのアップグレード

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

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

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

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

アップグレード元のリリースによっては、新しいアカウントが提供されている場合があります。SYSおよびSYSTEM以外のオラクル社が提供するアカウントは、すべてロックしてパスワードを期限切れにし、アカウントのロックを解除したときに新しいパスワードの指定が要求されるようにすることをお薦めします。

注意:
Oracle Database 12cのデフォルトのセキュリティ設定が適用されている場合、パスワードは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;

4.11.2 ORAPWDを使用したパスワード・ファイルの作成または移行

REMOTE_LOGIN_PASSWORDFILE初期化パラメータがexclusiveまたはsharedに設定されている場合、ORAPWDでパスワード・ファイルを作成および移行します。Oracle Database 12cでは、既存のデータベースからパスワード・ファイルを移行するために、ORAPWDに新しいオプションが提供されています。

関連項目:
パスワード・ファイルの作成および移行の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

従来の初期化パラメータ・ファイルを使用している場合は、次の手順でサーバー・パラメータ・ファイルへ移行します。

1. 初期化パラメータ・ファイルがクライアント・コンピュータ上にある場合は、クライアント・コンピュータからサーバー・コンピュータに転送します。

注意:
Oracle RACを使用している場合は、すべてのインスタンス固有の初期化パラメータ・ファイルを単一の初期化パラメータ・ファイルに結合する必要があります。クラスタ・データベース用のサーバー・パラメータ・ファイルの使用方法およびその他のアクションについては、次のマニュアルを参照してください。

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- ご使用のオペレーティング・システム用の『Oracle Real Application Clustersインストレーション・ガイド』

2. CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを作成します。この文は、初期化パラメータ・ファイルを読み取り、サーバー・パラメータ・ファイルを作成します。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。

3. 新しく作成されたサーバー・パラメータ・ファイルを使用して、インスタンスを起動します。

関連項目:

- サーバー・パラメータ・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。

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

4.11.4 Oracle Textのアップグレード

新しいOracle Database 12cリリースへアップグレードした後、次のファイルを以前の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リファレンス』を参照してください。

- 以前のリリースのOracle Textからのアプリケーションのアップグレードについては、『Oracle Textアプリケーション開発者ガイド』を参照してください。

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

Oracle Clusterwareを使用している場合は、データベースのOracle Clusterwareキーをアップグレードする必要があります。

Oracle Database 12cのsrvctlを実行してデータベースをアップグレードします。次に例を示します。

ORACLE_HOME/bin/srvctl upgrade database -db name -o ORACLE_HOME

関連項目:
srvctl upgrade databaseの構文は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

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

Oracle Databaseの新しいリリースごとに新しい初期化パラメータが導入され、非推奨となったり、サポートが終了した初期化パラメータもあります。ご使用のシステムに有効な新しい初期化パラメータを使用するために、これらの変更に対してパラメータ・ファイルを調整する必要があります。また、DBUAを使用しないで手動アップグレードを実行した場合、tnsnames.oraファイルには新しい構成情報と設定が自動的に移入されません。したがって、手動でtnsnames.oraを更新し、local_listenerおよびremote_listenerパラメータ参照を調節する必要があります(これらを解決する必要がある場合)。

関連項目:

- Oracle Database 12cの新しい初期化パラメータのリストおよび各パラメータの詳細は、『Oracle Databaseリファレンス』のOracle Databaseリファレンスの新機能に関する説明を参照してください。

- Oracle Database 12cでサポート終了および非推奨になった初期化パラメータについては、第8章「Oracle Database 12cでの非推奨となった機能とサポートが終了した機能」を参照してください。

- 付録A「以前のリリースのOracle Databaseの変更点」

4.11.6.1 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の位置を指定するパラメータ・ファイルを指定することが必要になる場合があります。

3. 初期化パラメータ・ファイルを使用している場合は、次の手順を実行します。

1. インスタンスが実行している場合は、停止します。

SQL> SHUTDOWN IMMEDIATE

2. 初期化パラメータ・ファイルを編集して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータをfor Oracle Database release 12.1に設定するには、初期化パラメータ・ファイルに次を入力します。

COMPATIBLE = 12.1.0

3. STARTUPを使用してインスタンスを起動します。

注意:
ASMディスク・グループを使用している場合、ディスク・グループの互換性属性は、init.oraのデータベース互換性パラメータの値以下である必要があります。

4.11.6.2 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インストレーション・ガイドfor Microsoft Windows x64(64-Bit)のネット・サービス名(tnsnames.oraファイル)に関する説明を参照してください。

- 『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX Systems』のネット・サービス名(tnsnames.oraファイル)に関する説明

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

Oracle RACデータベースのアップグレードでは、「アップグレードのための新しいOracleホームの準備」に、クラスタ・データベースをアップグレードする前にCLUSTER_DATABASE初期化パラメータをfalseに設定するよう指示がありました。アップグレードが完了した時点で、この初期化パラメータをtrueに設定する必要があります。

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

新しいリリースのOracle Databaseにアップグレードすると、多くの新機能および拡張機能を使用できます。 新機能を最大限に利用する場合は、新しいリリースで実行されているアプリケーションをアップグレードする必要があります。

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

- 新しいOracle Databaseリリースでのアプリケーションのアップグレードの概要

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

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

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

5.1 新しいOracle Databaseリリースでのアプリケーションのアップグレードの概要

新しいOracle Databaseの新しいリリースで実行される既存のアプリケーションは以前のリリースと同様に機能し、同等以上のパフォーマンスを得ることができます。Oracle Databaseの新しいリリースで使用可能になった機能を使用しない既存のアプリケーションは、変更する必要がありません。

Oracle Databaseの新しいリリースにアップグレードすると、多くの新機能および拡張機能を使用できます。機能やファンクションが追加された機能がある一方、パフォーマンスが向上した機能もあります。アプリケーションをアップグレードする前に、これらの新機能を確認して、どの機能を使用するかを判断する必要があります。

関連項目:

- Oracle Database 12cで使用可能な新機能については、『Oracle Database新機能ガイド』を参照してください。

- Oracle Database 12cの個々のデータベース製品またはオプションの使用方法に関する情報は、Oracle Technology Network (OTN) (http://www.oracle.com/technetwork/indexes/documentation/)を参照してください。

5.2 Oracle Databaseの異なるリリースでのアプリケーションの互換性の問題

Oracle Databaseの異なるリリース間には、アプリケーションに影響を与えかねない互換性の問題がある場合があります。これらの互換性の問題は、Oracle Databaseの様々なリリースにおける相違によるものです。また、Oracle Databaseのリリースが新しくなるたびに、Oracleの新しい予約語が追加され、初期化パラメータおよびデータ・ディクショナリが変更されている場合があります。

Oracle Databaseソフトウェアを新しいリリースにアップグレードする場合は、アプリケーションでOracleの予約語が使用されていないか、アプリケーションにデータベースの初期化パラメータとの互換性があるか、アプリケーションにデータベースのデータ・ディクショナリとの互換性があるかを確認してください。新しいリリースのOracle Databaseソフトウェアでは、特定のリリースのオペレーティング・システムまたは特定のパッチ・セットの適用が必要な場合があります。

関連項目:

- 初期化パラメータおよびデータ・ディクショナリの変更の詳細は、付録A「以前のリリースのOracle Databaseの変更点」を参照してください。

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

- オペレーティング・システムの要件の詳細は、ご使用のオペレーティング・システム固有のOracleドキュメント(『Oracle Databaseインストレーション・ガイド』)を参照してください。

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

プリコンパイラとOracle Call Interface (OCI)アプリケーションのアップグレード・パスは非常に似ています。

- 本番環境をアップグレードする前に、テスト環境を作成します。

- テスト環境に、アップグレードされたアプリケーションおよび新しいOracle Databaseソフトウェアを含めてください。

- テスト環境で、アプリケーションの現実的なテストが行われることを確認します。

関連項目:

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

- 『Pro*C/C++プログラマーズ・ガイド』

- Pro*COBOLプログラマーズ・ガイド

- 『Oracle Call Interfaceプログラマーズ・ガイド』

5.4 Oracle Databaseでのソフトウェアのアップグレードおよびクライアントとサーバー構成

プリコンパイラおよびOracle Call Interface (OCI)アプリケーションのアップグレードのオプションを理解するには、まず、実行するソフトウェアのアップグレードのタイプとクライアントおよびサーバー構成を理解する必要があります。

- Oracle Databaseのクライアントおよびサーバー・ソフトウェアのソフトウェア・アップグレードのタイプ

- Oracle Databaseで使用可能なクライアントおよびサーバーの構成

5.4.1 Oracle Databaseのクライアントおよびサーバー・ソフトウェアのソフトウェア・アップグレードのタイプ

Oracle Databaseのクライアントおよびサーバー・ソフトウェアでは、Oracle Databaseのメジャー・リリースとOracle Databaseのメンテナンス・リリースの2つのタイプのアップグレードを行うことができます。

- Oracle Databaseのメジャー・リリースのアップグレード

- Oracle Databaseのメンテナンス・リリースのアップグレード

5.4.1.1 Oracle Databaseのメジャー・リリースのアップグレード

このアップグレードは、リリース番号の最初の数字を変更します。たとえば、Oracle Database 11gからOracle Database 12cへのアップグレードは、データベースのメジャー・リリースのアップグレードです。

5.4.1.2 Oracle Databaseのメンテナンス・リリースのアップグレード

このアップグレードは、リリース番号の2番目の数字を変更します。たとえば、Oracle Database 11gリリース1 (11.1)からOracle Database 11gリリース2 (11.2)へのアップグレードは、データベースのメンテナンス・リリースのアップグレードです。

5.4.2 Oracle Databaseで使用可能なクライアントおよびサーバーの構成

プリコンパイラおよびOCIアプリケーションはクライアント/サーバー環境のクライアントで実行されます(ここでのサーバーは、Oracle Databaseサーバーです)。ご使用の環境で、次の1つ以上のクライアント/サーバー構成を使用できます。

- 異なるコンピュータ上に存在するOracle Databaseクライアントおよびサーバー

- 同じコンピュータ上の異なるOracleロケーションに存在するOracle Databaseクライアントおよびサーバー

- 同じOracleロケーション上に存在するOracle Databaseクライアントおよびサーバー

5.4.2.1 異なるコンピュータ上に存在するOracle Databaseクライアントおよびサーバー

クライアント・ソフトウェアおよびサーバー・ソフトウェアが異なるコンピュータにあり、それぞれがネットワークで接続されています。クライアント環境とサーバー環境は独立しています。

5.4.2.2 同じコンピュータ上の異なるOracleロケーションに存在するOracle Databaseクライアントおよびサーバー

クライアント・ソフトウェアおよびサーバー・ソフトウェアは同じコンピュータ上にありますが、異なるOracleホーム・ディレクトリにインストールされています。クライアント環境とサーバー環境は独立しています。

5.4.2.3 同じOracleロケーション上に存在するOracle Databaseクライアントおよびサーバー

クライアント・ソフトウェアおよびサーバー・ソフトウェアが同じコンピュータ上の同じOracleホームにインストールされています。この場合、サーバー・ソフトウェアをアップグレードすると、クライアント・ソフトウェアもアップグレードされます。

関連項目:
クライアント/サーバー環境の詳細は、『Oracle Database概要』を参照してください

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

Oracle Databaseクライアントまたはサーバー・ソフトウェアのアップグレード時に、互換性規則が適用されます。この規則は、実行するソフトウェア・アップグレードのタイプおよびクライアント/サーバー構成のタイプに基づきます。

この項では、アップグレードのタイプに応じた互換性規則について説明します。

- Oracle Databaseサーバー・ソフトウェアのアップグレードに対する規則

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

注意:
この項では、「Oracle Databaseでのソフトウェアのアップグレードおよびクライアントとサーバー構成」で説明する用語を使用しています。

5.5.1 Oracle Databaseサーバー・ソフトウェアのアップグレードに対する規則

Oracle Databaseのサーバー・ソフトウェアのアップグレード時には、データベース環境に応じて様々な規則が適用されます。

- クライアント環境を変更しない場合、再リンクは不要

- Oracle Databaseサーバーの新/旧リリースでアプリケーションの実行が可能

5.5.1.1 クライアント環境を変更しない場合、再リンクは不要

クライアントとサーバーが異なるコンピュータにあるか、または同じコンピュータの異なるOracleホーム・ディレクトリにあるときに、クライアント・ソフトウェアを変更しないでOracle Databaseサーバー・ソフトウェアをアップグレードする場合は、アプリケーションをプリコンパイル、コンパイルまたは再リンクする必要はありません。このような場合、クライアント・ソフトウェアはサーバー・ソフトウェアから独立しており、サーバーに対し継続して機能します。

ただし、アプリケーションがOracle Databaseサーバーと同じOracleホームを使用している場合は、サーバー・ソフトウェアをアップグレードするとクライアント・ソフトウェアもアップグレードされます。この場合、「Oracle Databaseクライアント・ソフトウェアのアップグレード」の規則に従う必要があります。

注意:
Oracle Databaseサーバー・ソフトウェアと、プリコンパイラまたはOCIクライアント・ソフトウェア用に同じOracleホームを使用している場合、新しいプリコンパイラまたはOCIクライアント・ソフトウェアはインストールしないで、サーバー・ソフトウェアをアップグレードすることができます。この場合、クライアント・ソフトウェアはアップグレードされません。ただし、このような構成はお薦めしません。

5.5.1.2 Oracle Databaseサーバーの新/旧リリースでアプリケーションの実行が可能

データベース・サーバーに対してプリコンパイラまたはOCIアプリケーションを実行する場合、クライアント・ソフトウェア・リリース以上のリリースのデータベース・サーバー・ソフトウェアを使用することをお薦めしますが、この構成が厳密に必要なわけではありません。たとえば、クライアント・ソフトウェアがOracle9iリリース2 (9.2.0.8)である場合、サーバーに対してクライアント上でプリコンパイラ・アプリケーションを実行するには、Oracle9iリリース2 (9.2.0.8)以上のサーバー・ソフトウェアを使用することをお薦めします。

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

ご使用のクライアント・ソフトウェアをアップグレードして、現行のサーバー・ソフトウェアと一致させることをお薦めします。たとえば、サーバーをOracle Database 12cにアップグレードする場合、クライアント・ソフトウェアもOracle Database 12cにアップグレードすることをお薦めします。サーバー・ソフトウェアとクライアント・ソフトウェアのリリース番号を同じにしておくと、アプリケーションの最大の安定性を得ることができます。また、最新のOracle Databaseクライアント・ソフトウェアには、それまでのリリースにはなかった機能が追加されていたり、パフォーマンスが向上している可能性があります。

アプリケーションのリンク方法に応じて、Oracle Databaseのクライアント・ソフトウェアのアップグレード時に適用される規則が異なります。

- Oracle Databaseサーバーの新/旧リリースでアプリケーションの実行が可能

- アプリケーションは、より新しいライブラリにリンクできる

- 静的にリンクされたアプリケーションを常に再リンクさせる必要がある

- 動的にリンクされたアプリケーションの再リンク

5.5.2.1 アプリケーションは、より新しいライブラリにリンクできる

プリコンパイラ・アプリケーションによって生成されたコードは、サーバーのリリース以上のクライアント・ライブラリのリリースにリンクできます。

OCIアプリケーションは、そのアプリケーションが開発されたOCIライブラリのリリース以上のOCIランタイム・ライブラリのリリースとリンクできます。

5.5.2.2 静的にリンクされたアプリケーションを常に再リンクさせる必要がある

静的にリンクされたOCIアプリケーションは、メジャー・リリースおよびマイナー・リリースの両方に再リンクさせる必要がありますが、これは静的にリンクされたOracleのクライアントサイド・ライブラリのコードと、アップグレード後のORACLE_HOMEでのエラー・メッセージとの互換性が失われている可能性があるためです。たとえば、エラー・メッセージにパラメータが追加される更新があった場合、このエラー・メッセージは、静的にリンクされたコードとは非互換になります。

5.5.2.3 動的にリンクされたアプリケーションの再リンク

Oracle Database 10gリリース1(10.1)以上のリリースの動的にリンクされたOCIアプリケーションでは、現行のリリースとの上位互換性が保たれます。つまり、Oracleのクライアントサイド動的ライブラリには、前のバージョンのライブラリとの上位互換性があります。Oracle Universal Installerによって前のバージョンのライブラリへのシンボリック・リンクが作成され、このシンボリック・リンクが現行バージョンのライブラリに解決されます。したがって、前のバージョンのOracleクライアントサイド動的ライブラリと動的にリンクされたアプリケーションは、現行バージョンのOracleクライアントサイド・ライブラリと再リンクしなくても動作します。

注意:
アプリケーションがランタイム・ライブラリの検索パス(Linuxでの-rpathなど)にリンクされていると、リンクされているバージョンのOracleクライアントサイド・ライブラリを使用して引き続き実行される場合があります。現行バージョンのOracleクライアントサイド・ライブラリを使用して実行するには、アプリケーションを再リンクする必要があります。
アプリケーションが遅延オプション(静的にリンクされているアプリケーションなど)にリンクされている場合は、再リンクする必要があります。

Oracle Database 10gリリース1 (10.1)より前のリリースのアプリケーションを使用している場合は、再リンクする必要があります。

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

Oracle Databaseの新しいリリース上で実行するプリコンパイラおよびOracle Call Interface (OCI)アプリケーションのアップグレード用に、いくつかのオプションが提供されています。

アップグレードのオプションは、難易度が高く、考えられるメリットが大きくなる順序に記述されています。つまり、選択肢1は最も簡単ですが、考えられるメリットは最も小さくなり、選択肢3は最も難しい方法ですが、考えられるメリットは最も大きくなります。

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

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

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

5.6.1 オプション1: アプリケーションを変更しない

アプリケーションおよびその環境を変更しません。アプリケーションを再リンク、プリコンパイルまたはコンパイルせず、また、アプリケーション・コードを変更しません。アプリケーションは、新しいOracle Database 12cリリースで引き続き動作します。この選択肢では、アプリケーションのOracleホーム環境をアップグレードしないでください。アプリケーションは変更しなくても、Oracle Database 12cサーバーで引き続き使用できます。この選択肢の主なメリットは、単純で簡単であることです。さらに、この選択肢では、クライアント・コンピュータをアップグレードする必要がないため、管理の必要性が最も少なくなります。多くのクライアント・コンピュータがある場合は、すべてのコンピュータのアップグレードに費やす管理コストを削減することが大変重要になります。

このオプションの主なデメリットは、Oracle Databaseの新しいリリースで使用可能な機能をアプリケーションで使用できないことです。また、期待できる新しいOracle Database 12cのすべてのパフォーマンス上のメリットをアプリケーションで活用することができません。

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

Oracle Databaseの新しいリリースを使用して、プリコンパイルまたはコンパイルし、次にアプリケーションを再リンクします。APIが非推奨になったか、または変更されている場合は、アプリケーション・コードを変更する必要があります。新しいリリースのOracle Databaseソフトウェアにアップグレードする場合、APIが非推奨になったか変更されたために必要になったコード変更を行った後、新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする必要があります。

この選択肢では、各クライアント・コンピュータに新しいOracle Databaseクライアント・ソフトウェアをインストールする必要があります。クライアントの数にかかわらず、必要なアプリケーションのプリコンパイルまたはコンパイルおよび再リンクは1回のみです。

再コンパイルすることによって、アプリケーション・コードの構文チェックを実行します。新しいOracleソフトウェアを使用してプリコンパイルまたはコンパイルすると、Oracleソフトウェアの以前のリリースでは検出されなかったアプリケーション・コードのいくつかの問題が、検出される場合があります。したがって、新しいソフトウェアを使用したプリコンパイルまたはコンパイルは、以前に検出されなかった可能性があるアプリケーション・コードの問題の検出および解決に役立ちます。

また、アプリケーションは新しいOracleソフトウェアで動作するため、再コンパイルすることによって、アプリケーションの最大の安定性を得ることができます。さらに、使用可能な最新のツール製品および機能を使用して、ご使用の環境で新しい開発を行うことができます。さらに、再コンパイルおよび再リンクの実行後のみ、新しいOracleソフトウェアで得られるパフォーマンスの向上を得ることができます。

5.6.3 オプション3: アプリケーション・コードを変更して、新しいOracle Databaseの機能を使用する

Oracle Database 12cの新しい機能を使用するために、アプリケーション・コードを変更します。コードをプリコンパイルまたはコンパイルし、再リンクさせます。アプリケーションのコードを変更することで、Oracle Databaseの新しい機能を利用できます。この選択肢は最も難しい方法ですが、考えられるメリットも最大です。この選択肢では、「選択肢2: 新しいソフトウェアを使用してアプリケーションをプリコンパイルまたはコンパイルする」で説明したすべてのメリットを実現できます。また、アプリケーションを変更することにより、Oracle Databaseの新しいリリースで得られるパフォーマンスおよびスケーラビリティのメリットを活用できます。さらに、新しいリリースでのみ使用できる新機能を、アプリケーションに追加できます。

『Oracle Database新機能ガイド』を読んで、新しいOracle Database 12cの機能を理解してください。使用する機能の実装方法については、ご使用の開発環境のOracleマニュアルを参照してください。プリコンパイラの詳細は、『Pro*C/C++プログラマーズ・ガイド』および『Pro*COBOLプログラマーズ・ガイド』を参照してください。OCIの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

使用する新機能を決定したら、これらの機能を使用するためにアプリケーションのコードを変更します。ご使用の開発環境に基づいて、次の項の該当する指示に従ってください。

- プリコンパイラ・アプリケーションの変更

- OCIアプリケーションの変更

5.6.3.1 プリコンパイラ・アプリケーションの変更

プリコンパイラ・アプリケーションを変更してOracle Database 12cの機能を使用するには、次の手順を実行します。

1. Oracle Database 12cの新しい機能を利用する場合は、これらの新機能のコードを既存のアプリケーションに取り込みます。

2. Oracleプリコンパイラを使用して、アプリケーションをプリコンパイルします。

3. アプリケーションをコンパイルします。

4. プリコンパイラに付属する新しいOracle Database 12cのランタイム・ライブラリ(SQLLIB)を、アプリケーションと再リンクさせます。

5.6.3.2 OCIアプリケーションの変更

OCIアプリケーションを変更してOracle Database 12cの機能を使用するには、次の手順を実行します。

1. 新しいOracle Database 12cのOCIコールを既存のアプリケーションに取り込みます。

2. アプリケーションをコンパイルします。

3. 新しいOracle Database 12cのランタイム・ライブラリを、アプリケーションと再リンクさせます。

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

新しいOracle Databaseリリースの機能およびファンクションを使用するには、新しいOracle Databaseリリースの構文を使用するように既存のSQLスクリプトを変更します。既存のSQLスクリプトで新しいOracle Databaseリリースの機能およびファンクションを使用しない場合は、既存のSQLスクリプトはそのまま新しいOracle Databaseリリースで実行されるため、変更は不要です。

新しいOracle Databaseリリースではエラー確認機能が強化されているため、実行時ではなくコンパイル時にエラーを識別できる場合があります。

5.7.1 数値リテラルの評価

数値リテラルの評価方法が変更され、リテラルを使用する数値計算の場合は、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言語リファレンス』を参照してください。

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

Formsアプリケーションは、Oracle9i、Oracle Database 10gおよびOracle Database 11gで同様に動作します。Oracle Database 12cでは、『Oracle Database開発ガイド』の題名が『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』に変更されています。

アプリケーション開発用に説明されている新しい機能および変更を確認してください。また、『Oracle Database新機能ガイド』で説明されている新機能を確認して、Oracle Database 12cの機能がアプリケーションに有効か、アプリケーションに影響を与えるかどうかを判断してください。

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

Oracle Databaseのサポートされているリリースでは、最後にアップグレードしたリリースにデータベースをダウングレードできます。たとえば、最近、リリース11.2.0.4からOracle Database 12cにアップグレードし、互換性のある初期化パラメータを12.1以上に変更しなかった場合、リリース11.2.0.4にダウングレードできます。ご使用のOracle Database 12cがリリース12.1.0.2で、互換性のある初期化パラメータを12.1.0.2に変更しなかった場合、リリース12.1.0.1などにダウングレードできます。

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

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

- Oracle Databaseをダウングレードするときの非互換性の確認

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

- Oracle Databaseをダウングレードする前に必要な手順の実行

- CDBまたは非CDBのOracle Databaseのダウングレード

- 単一のプラガブルOracle Database (PDB)のダウングレード

- Oracle Databaseをダウングレードする場合のダウングレード後の作業

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

関連項目:
オペレーティング・システム固有のダウングレードの説明については、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

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

データベースがアップグレードされる前の元のOracle Databaseのリリースに基づいて、メジャー・リリースとパッチ・セット・リリースの両方をダウングレードできます。メジャー・リリースのダウングレードは、Oracle Database 11gリリース2 (11.2.0.2)と後続の11.2リリース、およびOracle Database 11gリリース1 (11.1.0.7)へのダウングレードがサポートされています。パッチ・セットのダウングレードは、Oracle Databaseリリース11.2のパッチ・セットへのダウングレードがサポートされています(リリース11.2.0.1は除く)。

表6-1に、ダウングレードでサポートされるリリースのサマリーを示します。この表を使用する際には、「Oracle Databaseをダウングレードするときの非互換性の確認」で互換性についても確認してください。

表6-1 ダウングレードがサポートされているリリースおよびエディション

Oracle Databaseのリリースまたはエディション

ダウングレード可能

注意

12.1.0.2

Y

COMPATIBLE初期化パラメータを12.1.0.2に設定すると、データベースをダウングレードできません。

互換性が12.1.0.1に設定されている場合のみ、プラガブル・データベース(PDB)に対するダウングレードが可能になります。

CDBのダウングレード、またはPDBの切断およびダウングレードには、パッチ・セット更新PSU4が必要です。PSUは、https://support.oracle.com/にあるMy Oracle Support (MOS)でダウンロードできます。最新のパッチ・セットおよび必要な追加修正のセットを入手するには、MOSノート756671.1を参照してください。(「パッチと更新版」ページの一般検索ボックスで検索します。)

Oracle Database 12cの最小の互換性設定は11.0であるため、リリース10.2.0.5にダウングレードすることはできません。

12.1.0.1

Y

12.1.0.1 PDBを12.1.0.1データベースから切断し、同じPDBを12.1.0.2データベースに接続してアップグレードすると、12.1.0.2データベースの互換性のある初期化パラメータが12.1.0.1.0より後の場合はPDBをダウングレードできません。

Oracle Database 12cの最小の互換性設定は11.0であるため、リリース10.2.0.5にダウングレードすることはできません。

Oracle Enterprise Manager

N

サポートされている以前のリリースにダウングレードする場合、Oracle Enterprise Managerの制御を再構成する必要があります。「Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア」を参照してください。

Oracle Database Express Edition

N

Oracle Database Express Editionからアップグレードされたデータベースをダウングレードすることはできません。

重要:

次の情報は、ダウングレードできる場合に互換性に関して理解するためには、非常に重要です。

- COMPATIBLE初期化パラメータを12.1.0.2に設定すると、データベースをダウングレードできません。

- 互換性が12.1.0.1に設定されている場合のみ、プラガブル・データベース(PDB)に対するダウングレードが可能になります。

- リリース12.1.0.1のPDBを12.1.0.1データベースから切断した後、このPDBをリリース12.1.0.2データベースに接続した場合、このPDBをダウングレードすることはできません。

- PSU4 (つまりパッチ・セット更新)は、CDBのダウングレード、またはPDBの切断およびダウングレードに必要です。最新のパッチ・セットおよび必要な追加修正のセットを入手するには、https://support.oracle.com/のMy Oracle Support (MOS)でMOSノート756671.1を参照してください。

注意:
Oracle Database 12cの最小の互換性設定は11.0であるため、リリース10.2.0.5にダウングレードすることはできません。また、Oracle Database Express Editionからアップグレードされたデータベースをダウングレードすることはできません。

サポートされている以前のリリースでは、Oracle Databaseのダウングレードについて、次の推奨事項があります。

- このリリースにはマルチテナント・アーキテクチャが含まれ、マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)用の機能が提供されます。そのため、このリリースへのアップグレード後にCOMPATIBLE初期化パラメータを最上位レベルに設定すると、ダウングレードする機能が妨げられます。

- このリリースでは、SELECTに加えて、新しいオブジェクト権限READが含まれています。ダウングレード後に、次が行われます。

- SELECTおよびREADオブジェクト権限がある場合、READ権限が削除されます。

- READオブジェクト権限のみがある場合、これはSELECTオブジェクト権限に変換されます。

READおよびSELECTオブジェクト権限の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ダウングレードできる最も古いリリースは、Oracle Databaseリリース11.1.0.7です。Oracle Database 12cの互換性の最低は11.0のため、リリース12.1にアップグレードした後に、互換性を11.0以上に設定する必要があります。互換性が設定されると、データベースのディスク上の構造が変更され、互換性設定によって制御される新しい機能が有効になります。そのため、11.1.0.7より前のリリースへのダウングレードは選択できません。

- アップグレードするデータベースにOracle XML DBが存在しない場合は、ダウングレード時にOracle XML DBがアンインストールされます。たとえば、Oracle Database 11gリリース2 (11.2)とともにOracle XML DBをインストールしなかった場合、Oracle Database 12cへのアップグレード時にOracle XML DBがインストールされます(このリリースに含まれるため)。Oracle Database 11gリリース2 (11.2)へのダウングレード時には、Oracle XML DBは削除されます。

- Oracle Database 12cへのアップグレード時に、Database (DB) Controlリポジトリは削除されます。ダウングレードする場合は、ダウングレードした以前のリリースでDatabase (DB) Controlを再び使用するために再構成する必要があります。「Oracle Enterprise Manager Database Controlの構成およびデータの保存」を参照してください。

- Oracle Enterprise Managerのダウングレードはサポートされていません。サポートされている以前のリリースにダウングレードする場合、Oracle Enterprise Managerの制御を再構成する必要があります。「Oracle Databaseのダウングレード後のOracle Enterprise Managerのリストア」を参照してください。

- Oracle Database 12cのOracle Clusterwareでは、Windows上でのOracle Databaseリリース10.2およびリリース11.1へのダウングレードはサポートされていません。リリース11.2より前のリリースには、フレッシュ・インストールが必要です。

関連項目:
「直接のアップグレードをサポートするOracle Databaseのリリース」

6.2 Oracle Databaseのダウングレード時の非互換性の確認

ご使用のデータベースの互換性レベルをチェックして、非互換性があるかどうかを確認します(非互換性がある場合は、ダウングレードできません)。Oracle Database 12cデータベースの互換性レベルが12.1.0の場合はダウングレードできません。

関連項目:
「Oracle Databaseの互換性レベルの確認」

Oracle Database 11gリリース2 (11.2.0.2)、Oracle Database 11gリリース2 (11.2.0.3)またはOracle Database 11gリリース2 (11.2.0.4)にダウングレードする場合は、COMPATIBLE初期化パラメータを11.2.0以下に設定する必要があります。リリース11.2.0.1へのダウングレードはサポートされていません。

Oracle Database 11gリリース1(11.1.0.7)にダウングレードする場合は、COMPATIBLE初期化パラメータを11.1.0以下に設定する必要があります。Oracle Database 11gリリース1では、リリース11.1.0.7へのダウングレードのみがサポートされています。

注意:
Oracle ASMディスク・グループでは、データベースのアップグレード時にディスク・グループの互換性を12.1.0.0.0に変更した場合は、以前のリリースへのダウングレード時にOracle ASMディスク・グループをマウントできなくなります。
ダウングレードの前にOracle ASMディスク・グループの互換性を手動でリストアする必要があります。そうしない場合、ダウングレード後に、インスタンスはディスク・グループをマウントできません。

ASMディスク・グループの互換性の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

関連項目:
「Oracle Databaseのアップグレードでのダウングレードおよび互換性の概要」および付録A「以前のリリースのOracle Databaseの変更点」

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

サポートされている以前のリリースにダウングレードする前に、Oracle Database 12cデータベースの完全バックアップを実行することを強くお薦めします。

関連項目:
RMANバックアップの実行方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

6.4 Oracle Databaseをダウングレードする前に必要な手順の実行

アップグレード前の以前のリリースにダウングレードする前に、必須の準備を完了する必要があります。たとえば、まず、データベース内のコンポーネントを無効にする必要があるかどうかを決定する必要があります。

ダウングレードの準備をするには、次の手順を実行します。

1. Oracle Databaseリリース12.1.0.2で、CDBをダウングレードするか、またはPDBを切断およびダウングレードする場合、最初にPSU4 (パッチ・セット更新4)を適用する必要があります。https://support.oracle.com/にあるMy Oracle Supportにアクセスして、PSU4および必要な追加修正のセットを入手します。パッチ・セットの情報およびリンクは、MOSノート756671.1に掲載されています。「パッチと更新版」ページの一般検索ボックスで756671.1を検索します。これはダウングレードするための要件です。

2. Oracle Databaseリリース11.1にダウングレードする場合、ダウングレード手順を開始する前に、新しく作成するデータベース・リンクのパスワードを確認します。これらは、リリース11.2または12.1の実行中に作成した可能性があるデータベース・リンクです。Oracle Databaseリリース11.1にダウングレードした後でデータベース・リンク・パスワードをリセットする必要があるため、データベース・リンク・パスワードが必要です。詳細は、「ダウングレード後のデータベース・リンクのパスワードの問題」を参照してください。

3. データベースでOracle Database Vaultを有効化している場合は、データベースをダウングレードする前にOracle Database Vaultを無効化します。
Oracle Database Vaultが有効化されているかどうかを確認するには、次のようにV$OPTION動的ビューを問い合せます。

この問合せに示すとおりの大文字/小文字を使用してOracle Database Vaultを入力します。出力がTRUEの場合は、Oracle Database Vaultが有効化されているため、無効化する必要があります。手順は、『Oracle Database Vault管理者ガイド』を参照してください。

4. データベースでOracle Label Securityを使用していて、リリース11.2以前にダウングレードする場合、新しいOracle Database 12cのOracleホームでOracle Label Security (OLS)事前処理ダウングレードolspredowngrade.sqlスクリプトを実行します。リリース12.1.0.2からリリース12.1.0.1にダウングレードする場合、olspredowngrade.sqlを実行する必要はありません。

重要:
Oracle Label SecurityおよびOracle Database Vaultを使用するデータベースでは、Oracle Database 12cからデータベース・リリース11.2 (以前)にダウングレードする前に、olspredowngrade.sqlスクリプトを実行する必要があります。

1. Oracle Label Securityが有効化されているかどうかを確認するには、次のようにV$OPTION動的ビューを問い合せます。

SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Oracle Label Security';

2. olspredowngrade.sqlスクリプトを実行します。

SQL> @ORACLE_HOME/rdbms/admin/olspredowngrade.sql

詳細は、Oracle Label Security管理者ガイドを参照してください。

5. 統合監査が有効化されている場合は、統合監査証跡をオプションでバックアップおよび消去します。

1. 統合監査レコードが存在するかどうかを確認します。

2. 既存の監査データを表にバックアップします。次に例を示します。

SQL> CREATE TABLE UA_DATA AS (SELECT * FROM V$UNIFIED_AUDIT_TRAIL);

3. 監査証跡をクリーンアップします。

EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, use_last_arch_timestamp => FALSE);

6. 以前にタイムゾーン・ファイルの最新バージョンをインストールし、DBMS_DST PL/SQLパッケージを使用してTIMESTAMP WITH TIME ZONEデータをそのバージョンにアップグレードした場合は、ダウングレード先のリリースに同じバージョンのタイムゾーン・ファイルをインストールします。データベースのアップグレード後にDBMS_DSTを使用してTIMESTAMP WITH TIME ZONEデータをそのタイム・ゾーン・ファイルの最新バージョンにアップグレードした場合は、ダウングレード先のリリースにこの最新バージョンのタイムゾーン・ファイルをインストールします。これにより、TIMESTAMP WITH TIME ZONEデータが取得中に論理的に破損することがなくなります。
データベースで現在使用されているタイムゾーン・ファイルのバージョンを確認するには、次のようにV$TIMEZONE_FILEに問い合せます。

SQL> select * from  V$TIMEZONE_FILE;

現在のOracleホームからダウングレードするOracheホームにタイムゾーン・ファイルをコピーします。たとえば、問合せの結果を確認した後で、次から選択します。

%ORACLE_HOME%\oracore\zoneinfo\timezlrg_18.dat
%ORACLE_HOME%\oracore\zoneinfo\timezone_18.dat

タイムゾーン・ファイルのアップグレードの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を、DBMS_DSTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

7. Oracle Database 12cへのアップグレード時にORA_TZFILE環境変数をタイム・ゾーン・ファイルのフルパス名に設定した場合は、後でデータベースをダウングレードする際にその設定を解除する必要があります。
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グローバリゼーション・サポート・ガイド』を参照してください。

8. オプション: Oracle Database 11gリリース1 (11.1.0.7)にダウングレードする際にデータベースにOracle Application Expressがある場合は、Oracle Database 12c ORACLE_HOME/apex/ディレクトリからOracleホーム外部のディレクトリ(システムの一時ディレクトリなど)にapxrelod.sqlファイルをコピーする必要があります。
このファイルの新しい場所を記録します。この手順で後ほど必要になります。

9. 固定オブジェクトに基づいてオブジェクトを作成した場合は、これらのオブジェクトを削除して、ORA-00600エラーの発生を回避します。ダウングレード後にこれらのオブジェクトを再作成できます。

10. データベースにOracle Enterprise Managerが構成されている場合は、Enterprise Managerユーザーを削除します。

DROP USER sysman CASCADE;

注意:
この手順を実行すると、MGMT*シノニムが無効になる場合があります。ダウングレードしたデータベースでOracle Enterprise Managerの制御を使用するには、Oracle Enterprise Managerを再構成する必要があります。

6.5 CDBまたは非CDBのOracle Databaseのダウングレード

Oracle Database 12cデータベースを、サポートされているメジャー・リリースまたは関連するパッチ・セット・アップグレードにダウングレードするための手順が提供されています。リリース12.1.0.2以上からリリース12.1.0.1にダウングレードする場合、マルチテナント・コンテナ・データベース(CDB)またはCDB内の1つのプラガブル・データベース(PDB)にあるすべてのデータベースをダウングレードできます。Oracle Database 12cより前のOracle Databaseリリースでは、マルチテナント・アーキテクチャを使用しませんでした。1つのPDBをダウングレードするためのプロシージャについては、「単一のプラガブルOracle Database (PDB)のダウングレード」を参照してください。

この項の手順は、「Oracle Databaseのダウングレードがサポートされているリリース」を理解していることを前提としています。

CDBであるかどうかに関係なく、サポートされている以前のリリースにデータベースをダウングレードするには、次の手順を実行します。

1. Oracle Database 12cのOracleホーム・ディレクトリの所有者として、システムにログインします。

2. システム・プロンプトで、ORACLE_HOME/rdbms/adminディレクトリへ移動します(ORACLE_HOMEはシステムのOracleホームです)。

注意:
クラスタ・データベースをダウングレードしている場合は、データベースを完全に停止し、CLUSTER_DATABASE初期化パラメータをFALSEに設定します。ダウングレードが完了した後、このパラメータの設定をTRUEに戻す必要があります。

3. SQL*Plusを使用して、SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

sqlplus sys as sysdba
Enter password: password

4. 新しいOracle Database 12cのOracleホームの所有者として、システムにログインします。

5. ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。

6. アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。

CONNECT / AS SYSDBA

7. 使用するOracle Databaseインスタンス・タイプに応じて、SQL*Plusで次のコマンドを発行し、ダウングレード・モードでインスタンスを起動します。PFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。
非CDBインスタンスの場合

SQL> startup downgrade pfile=pfile_name

CDBインスタンスの場合

SQL> startup downgrade pfile=pfile_name
SQL> alter pluggable database all open downgrade;

初期化パラメータ・ファイルPFILEの場所を指定します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

8. オプション: 非CDBをダウングレードする場合、変更および問題を追跡するために、結果をログ・ファイルにスプールするようにシステムを設定できます。(CDBは自動的にcatcon_logsに出力をスプールするため、CDBの場合はこの手順をスキップできます。)

SQL> SPOOL downgrade.log

9. catdwgrd.sqlを実行します。
非CDBの場合:

SQL> @catdwgrd.sql

CDBの場合:

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -d
$ORACLE_HOME/rdbms/admin -e -b catdwgrd -l <output directory> -r
catdwgrd.sql

CDBの例では、catcon.plはcatdwgrdとともに実行されます。最初にPERLを起動します。-dパラメータは、catcon.plにcatdwgrdの入手先を指定します。-lパラメータは、ログ・ファイルの出力ディレクトリを指定します(rdbms/adminディレクトリに書き込むかわりとなります)。-rパラメータを使用して、2つのスクリプトを一緒に実行する必要があります。

注意:

- Oracle Database 12cに付属するcatdwgrd.sqlスクリプトのバージョンを使用する必要があります。

- Oracle Database 12c環境でcatdwgrd.sqlを実行する必要があります。

- 2つのスクリプトを同時に一緒に実行するには、-rパラメータを指定する必要があります。

- catdwgrd.sqlスクリプトによって、データベース内のすべてのOracle Databaseコンポーネントがサポートされているアップグレード元のメジャー・リリースまたはパッチ・リリースにダウングレードされます。

catdwgrd.sqlスクリプトまたは残りの手順のいずれかのスクリプトを実行中になんらかの問題が発生した場合は、問題を解決してスクリプトを再実行します。必要に応じて、この章で説明されているスクリプトのいずれかを実行できます。

注意:
コンポーネントのダウングレードに失敗した場合、ORA-39709エラーが表示され、SQL*Plusセッションは、Oracle Databaseデータ・ディクショナリをダウングレードせずに終了します。すべてのコンポーネントは、Oracle Databaseのデータ・ディクショナリをダウングレードする前に、正常にダウングレードする必要があります。catdwgrd.sqlスクリプトを再実行する前に、問題を特定して修正する必要があります。

10. 非CDBの場合のみ、スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

次に、スプール・ファイルを確認して、ダウングレード中にエラーが発生しなかったかどうかを検証します。手順8で、スプール・ファイル名をdowngrade.logとしました。このファイルで見つけた問題を修正し、必要に応じてダウングレード・スクリプトを再実行します。

注意:
ダウングレード・スクリプトを初めて実行した結果を保存する場合は、再実行する前に、downgrade.logを他の名前に変更してください。

11. インスタンスを停止します。

SQL> SHUTDOWN IMMEDIATE

12. SQL*Plusを終了します。

13. ご使用のオペレーティング・システムがLinuxまたはUNIXの場合、次の環境変数がダウングレード先のリリースのディレクトリを指定するように変更してください。

- ORACLE_HOME

- PATH

また、oratabファイル、およびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、ダウングレードされたOracleホームを指していることを確認する必要があります。

ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関する詳細は、オペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

14. ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。

1. Oracle Database 12cデータベースのすべてのOracleサービス(OracleServiceSID Oracleサービスなど)を停止します(SIDはインスタンスの名前)。
たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。

C:\> NET STOP OracleServiceORCL

WindowsでのOracleサービスの停止の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

2. コマンド・プロンプトでORADIMコマンドを発行して、Oracleサービスを削除します。
たとえば、SIDがORCLの場合、次のコマンドを入力します。

C:\> ORADIM -DELETE -SID ORCL

3. コマンド・プロンプトでORADIMコマンドを使用して、ダウングレードするデータベースのOracleサービスを作成します。

C:\> ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS
-STARTMODE MANUAL -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

ORADIMを使用したOracle Databaseインスタンスの管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。ORADIMの構文には次の変数が含まれます。

変数

説明

SID

ダウングレードするデータベースのSIDと同じSID名です。

PASSWORD

データベース・インスタンスのパスワードです。SYSDBA権限で接続するユーザー用のパスワードです。-INTPWDオプションは必須ではありません。パスワードの入力を求められた場合は、このWindowsプラットフォームの標準のユーザー・アカウントのパスワードを使用します。

USERS

SYSDBA権限およびSYSOPER権限を付与できるユーザーの最大数です。

ORACLE_HOME

ダウングレード先のデータベースのOracleホーム・ディレクトリです。-PFILEオプションを使用して、(Oracleホーム・ディレクトリのドライブを含む)フルパス名を指定する必要があります。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

たとえば、SIDがORCL、PASSWORDがTWxy5791、USERSの最大数が10、ORACLE_HOMEディレクトリがC:\ORANTの場合、次のコマンドを入力します。

C:\> ORADIM -NEW -SID ORCL -INTPWD TWxy5791 -MAXUSERS 10
-STARTMODE MANUAL -PFILE C:\ORANT\DATABASE\INITORCL.ORA

注意:
ORADIMコマンドによって、Oracleホームのユーザー・アカウントのパスワードの入力が求められます。ORADIMを使用して、他のオプションを指定できます。
データベースをダウングレードする際に、Windowsレジストリの設定を変更する必要はありません。必要な変更は、すべてORADIMユーティリティによって自動的に行われます。

15. ダウングレード先のリリースの構成ファイル(パラメータ・ファイル、パスワード・ファイルなど)をリストアします。
Oracle RACデータベースの場合は、次のコマンドを実行して、データベースを単一インスタンス・モードに戻します。

SET CLUSTER_DATABASE=FALSE

注意:
クラスタ・データベースをダウングレードしている場合は、このクラスタ・データベースのインスタンスが構成されているすべてのノードでこの手順を実行してください。CLUSTER_DATABASE初期化パラメータをFALSEに設定します。ダウングレードが完了した後、この初期化パラメータの設定をTRUEに戻す必要があります。
Oracle RACでの初期化パラメータの使用の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

16. システム・プロンプトで、ダウングレードする以前のリリースのORACLE_HOME/rdbms/adminディレクトリに移動します。

17. SQL*Plusを開始して、SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

非CDBの場合:

SQL> CONNECT / AS SYSDBA
SQL> STARTUP UPGRADE

CDBの場合:

connect / as sysdba
startup database mount;
alter database open upgrade;
alter pluggable database all open upgrade;

18. オプション: 非CDBの場合、変更および問題を追跡するために、結果をログ・ファイルにスプールするようにシステムを設定します。この手順はCDBには必要ありません。

SQL> SPOOL reload.log

19. catrelod.sqlを実行します。
非CDBの場合:

SQL> @catrelod.sql

CDBの場合:

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catrelod -d '''.''' catrelod.sql

catrelod.sqlスクリプトによって、ダウングレードしたデータベース内の各データベース・コンポーネントに該当するバージョンが再ロードされます。

20. Oracle Database 11gリリース1 (11.1.0.7)にダウングレードする際にデータベースにOracle Application Expressがある場合は、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

21. 非CDBでスプーリングをオンにした場合、スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

次に、スプール・ファイルを確認して、すべてのパッケージおよびプロシージャのコンパイルが成功したかどうかを検証します。このログ・ファイルで見つけた問題を処理し、必要に応じて適切なスクリプトを再実行します。

22. 通常の操作のために、インスタンスを停止し、再起動します。

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

PFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

23. データベースがOracle Label Security用に構成されている場合は、この手順を実行します。

1. olstrig.sqlスクリプトを、Oracle Database 12cのOracleホームからダウングレード後のデータベースのリリースのOracleホームにコピーします。

2. ダウングレード先のリリースのOracleホームからolstrig.sqlを実行し、Oracle Label Securityのポリシーを適用して、表のDMLトリガーを再作成します。

SQL> @olstrig.sql

Oracle Label Securityの詳細は、Oracle Label Security管理者ガイドを参照してください。

24. utlrp.sqlスクリプトを実行します。
非CDBの場合:

SQL> @utlrp.sql

CDBの場合、catcon.plを実行して、utlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql

utlrp.sqlスクリプトは、以前INVALID状態だったパッケージ、プロシージャ、型などのすべての既存のPL/SQLモジュールを、再コンパイルします。ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。

25. SQL*Plusを終了します。

26. クラスタ・データベースをダウングレードする場合は、次のコマンドを実行してOracle Clusterwareのデータベース構成をダウングレードする必要があります。

$ srvctl downgrade database -d db-unique-name -o oraclehome -t to_version

[ここで、db-unique-nameはインスタンス名ではなくデータベース名であり、oraclehomeは、ダウングレードされるデータベースの古いOracleホームの場所で、to_versionは、データベースがダウングレードされるデータベースのリリースです。(例: 11.2.0.3.0)]

注意:
このコマンドは、データベースのダウングレード後のOracleホームからではなく、現在のOracle Database 12cのOracleホームから実行してください。

データベースがダウングレードされました。

6.6 単一のプラガブルOracle Database (PDB)のダウングレード

Oracle Database 12cの最新リリースをダウングレードする場合、CDB全体をダウングレードせずに1つのPDBをダウングレードできます。たとえば、リリース12.1.0.2のCDBからPDBを切断し、それをダウングレードした後、リリース12.1.0.1のCDBに接続するか、そのデータベースをスタンドアロン・データベースに変換することができます。

この項の手順は、「Oracle Databaseのダウングレードがサポートされているリリース」を理解していることを前提としています。

手順1   PDBのダウングレード

この手順では、PDBをリリース12.1.0.1にダウングレードします。

1. リリース12.1.0.2のPDBをDOWNGRADEモードで起動します。これを行うとき、CDBは標準モードになります。

SQL> alter pluggable database CDB1_PDB1 open downgrade;

2. catdwgrdを実行してPDBをダウングレードします。この例ではPDB1です。
次のようにcatdwgrdを実行します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -d
$ORACLE_HOME/rdbms/admin -n 1 -l <output directory> -e -b catdwgrd -c 'PDB1'
catdwgrd.sql

例では、catcon.plはcatdwgrdとともに実行されます。最初にPERLを起動します。-dパラメータは、catcon.plにcatdwgrdの入手先を指定します。-lパラメータは、ログ・ファイルの出力ディレクトリを指定します(rdbms/adminディレクトリに書き込むかわりとなります)。2つのスクリプトを同時に一緒に実行するには、-rパラメータを使用する必要があります。

3. PDBを閉じます。

手順2   CDBからのPDBの切断

この手順では、ダウングレードされたPDBをリリース12.1.0.2のCDBから切断します。

1. 12.1.0.2のCDBに接続します。

2. 切断するPDBを閉じます。

SQL> alter pluggable database PDB1 close;

3. ダウングレードされた12.1.0.1のPDBを切断します。

SQL> alter pluggable database PDB1 unplug into 'path/PDB1.xml';

「プラガブル・データベースが変更されました。」が表示されます。

手順3   ダウングレードされた12.1.0.1のPDBの接続

この手順では、ダウングレードされた12.1.0.1のPDBを12.1.0.1のCDBに接続します。これを行うには、このCDBでPDBを作成する必要があります。この例では、PDB1を作成します。

1. 12.1.0.1のCDBに接続します。

2. 12.1.0.1のPDBを接続します。

SQL> create pluggable database PDB1 using 'path/PDB1.xml';

「プラガブル・データベースが作成されました。」が表示されます。

3. この手順の後続のステップで示すスクリプトを実行するには、PDBをアップグレード・モードで開きます。

SQL> alter pluggable database PDB1 open upgrade;

4. PDBに接続します。

SQL> alter session set container=PDB1;

5. PDBでcatrelodを実行します。

SQL> @$ORACLE_HOME/rdbms/admin/catrelod.sql

catrelod.sqlスクリプトによって、ダウングレードしたデータベース内の各データベース・コンポーネントに該当するバージョンが再ロードされます。

6. PDBでutlrpを実行します。

SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql

utlrp.sqlスクリプトは、以前INVALID状態だったパッケージ、プロシージャ、型などのすべての既存のPL/SQLモジュールを、再コンパイルします。

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

変更が、互換性、コンポーネントおよびサポートされるプロトコルに影響するため、Oracle Databaseのダウングレード後に追加の作業が必要になる場合があります。

この項には次のトピックが含まれます:

- Oracle DatabaseダウングレードでのOracle XML DB認証の推奨事項

- リリース11.1.0.7にダウングレードする際のネットワーク・リスナーの再作成

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

- Oracle Clusterwareの構成のリストア

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

- 以前のバージョンへのOracle Application Expressのリストア

6.7.1 Oracle DatabaseダウングレードでのOracle XML DB認証の推奨事項

ダイジェスト認証がサポートされていないOracle Database 12cより前のリリースにダウングレードする場合、ダイジェスト認証が無効化され、認証の選択肢として使用できなくなります。これは、Oracle XML DBリポジトリのHTTP認証に影響します。ダイジェスト認証を使用せず、かわりにデフォルトの構成を使用している場合は、これ以上のアクションは必要ありません。

関連項目:
データベースのインストール、アップグレードおよびダウングレードに対するOracle XML DBを使用した認証の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

6.7.2 リリース11.1.0.7にダウングレードする際のネットワーク・リスナーの再作成

Oracle Database 11gリリース1 (11.1.0.7)にダウングレードする場合は、ダウングレード手順の実行後にリスナーを再作成する必要があります。Oracle Net Managerを実行して古いリスナーを削除し、新しいリスナーを作成します。

- Oracle Enterprise ManagerのコンソールからOracle Net Managerを起動するには、「ツール」メニューから「サービス管理」を選択し、「Oracle Net Manager」を選択します。

- Windowsの場合、「スタート」メニューから「プログラム」を選択し、「Oracle - HOME_NAME」を選択します。次に、「Configuration and Migration Tools」を選択し、「Net Manager」を選択します。

関連項目:
『Oracle Database Net Services管理者ガイド』

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

Oracle Database Vaultを使用している場合は、データベースをダウングレードする前にこれを無効にするように指示されている場合があります。ダウングレード後にOracle Database Vaultを使用するには、これを再有効化する必要があります。

関連項目:
完全な手順は、『Oracle Database Vault管理者ガイド』を参照してください。

6.7.4 Oracle Clusterwareの構成のリストア

Oracle Clusterware構成をOracle Clusterware 12cリリース1 (12.1)のアップグレード前の状態にリストアできます。構成をリストアするには、アップグレード前のリリースをリストアする必要があります。Oracle Database 12cのアップグレード処理中またはアップグレード処理後に実行した構成変更は削除され、リカバリできません。

関連項目:

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

- 『Oracle Grid Infrastructureインストレーション・ガイドfor Microsoft Windows x64(64-Bit)』

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

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

この項で説明するリストア・タスクは、なんらかの形式でダウングレード中であり、Oracle Enterprise Managerがホストに構成されている場合にのみ実行する必要があります。Oracle Enterprise Managerを以前の状態にリストアするには、Oracle Enterprise Managerの構成ファイルおよびデータをアップグレードの前に保存しておく必要があります。構成をリストアするには、まずこの項の説明に従ってOracle Enterprise Manager構成アシスタント(EMCA)を実行し、「Enterprise Manager Database Controlをリストアするためのemdwgrdユーティリティの実行」の説明に従ってemdwgrdユーティリティを実行します。

関連項目:
「Oracle Enterprise Manager Database Controlの構成およびデータの保存」

これが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 Database 12cバージョンのemcaを使用します。emcaの詳細は、『Oracle Database管理者ガイド』を参照してください。

emcaに指定するオプションは、データベースがシングル・インスタンス・データベースか、Oracle RACデータベースか、Oracle ASMデータベースかによって異なります。

- Oracle ASMがない単一インスタンスのOracle Databaseでのemcaの実行

- Oracle ASMがないOracle RACデータベースでのemcaの実行

- 単一インスタンスのOracle ASMインスタンスでのemcaの実行

- Oracle RACインスタンス上のOracle ASMでのemcaの実行

- Oracle ASMがある単一インスタンスのOracle Databaseでのemcaの実行

- Oracle RACデータベースおよびOracle ASMインスタンスでのemcaの実行

Oracle ASMがない単一インスタンスのOracle Databaseでのemcaの実行

ORACLE_HOME/bin/emca -restore db

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースSID

- リスナー・ポート番号

Oracle ASMがないOracle RACデータベースでのemcaの実行

ORACLE_HOME/bin/emca -restore db -cluster

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースの一意の名前

- リスナー・ポート番号

単一インスタンスのOracle ASMインスタンスでのemcaの実行

ORACLE_HOME/bin/emca -restore asm

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- Oracle ASMポート

- Oracle ASM SID

Oracle RACインスタンス上のOracle ASMでのemcaの実行

ORACLE_HOME/bin/emca -restore asm -cluster

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- Oracle ASMポート

Oracle ASMがある単一インスタンスのOracle Databaseでのemcaの実行

ORACLE_HOME/bin/emca -restore db_asm

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースSID

- リスナー・ポート番号

- Oracle ASMポート

- Oracle ASMホーム

- Oracle ASM SID [+ASM]

Oracle RACデータベースおよびOracle ASMインスタンスでのemcaの実行

ORACLE_HOME/bin/emca -restore db_asm -cluster

次の情報の入力を求められます。

- リストアするデータベースのOracleホーム

- データベースの一意の名前

- リスナー・ポート番号

- Oracle ASMポート

- Oracle ASM Oracleホーム

- Oracle ASM SID [+ASM]

emcaの出力は、指定するオプションおよびプロンプトで入力する値によって様々です。この手順は、Oracle RAC環境内のすべてのノードに対して繰り返す必要があります。

ここで、Oracle Enterprise Manager Database Controlおよびデータをリストアするためにemdwgrdユーティリティを実行する必要があります。

関連項目:
「Enterprise Manager Database Controlをリストアするためのemdwgrdユーティリティの実行」

6.7.5.1 Enterprise Manager Database Controlをリストアするためのemdwgrdユーティリティの実行

emca -restoreプロシージャの終了後に、emdwgrdユーティリティを使用して、Oracle Enterprise Manager Database Controlおよびデータをリストアする準備ができます。Oracle Database 12cホームからemdwgrdユーティリティを実行する必要があります。次に、ORACLE_HOMEおよび他の環境変数を、アップグレードが実行されたOracleホームを指すように設定する必要があります。

次の手順は、LinuxおよびUNIX用です。この手順をWindowsで実行する場合は、emdwgrdをemdwgrd.batに置き換えてください。

次の手順に従って、Oracle Enterprise Manager Database Controlおよびデータをリストアします。

1. ORACLE_HOMEを、データベースがアップグレードされる前のOracleホームに設定します。

2. ORACLE_SIDを、アップグレード後にダウングレードされたデータベースのSIDに設定します。

3. データベースがアップグレードされる前のOracleホームを指すように、PATH、LD_LIBRARY_PATHおよびSHLIB_PATHを設定します。

4. Oracle Database 12cのOracleホームに移動します。

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

Oracleホームが共有デバイス上にある場合は、前述のコマンドラインに-sharedを追加します。

6. emdwgrdにより要求された場合は、SYSおよびSYSMANパスワードを入力します。

7. emdwgrdが終了すると、Oracle Enterprise Manager Database Controlは古いOracleホームにダウングレードされます。

6.7.6 以前のバージョンへのOracle Application Expressのリストア

アップグレードされたデータベースに、バージョン4.2より前のバージョンのOracle Application Expressがある場合、データベースをダウングレードすると、Oracle Application Expressもダウングレードされます。以前のバージョンのOracle Application Expressソースから、SYS所有のオブジェクトWWV_FLOW_VALおよびWWV_DBMS_SQLをコンパイルする必要があります。

1. 作業ディレクトリを、以前のバージョンのApplication Expressソースのコア・ディレクトリに変更します。

2. データベースにSYS/SYSDBAとして接続します。

3. 次のスクリプトを表示されている順に実行します。

1. @wwv_flow_val.plb

2. @wwv_dbms_sql.sql

3. @wwv_dbms_sql.plb

4. Oracle XML DB Protocol Serverの埋込みPL/SQLゲートウェイを使用していた場合、次のように、イメージ・ディレクトリを以前のバージョンにリストアする必要があります。

1. 作業ディレクトリを、以前のバージョンのApplication Expressソースに変更します。

2. 次の例のように、以前のバージョンのソースへのパスを渡すSYS as SYSDBAとして接続されたapxldimg.sqlを起動します。

@apxldimg.sql /tmp/apex32

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

Oracleでは、Oracle Databaseをダウングレードする際に発生する可能性のある問題に関してトラブルシューティング情報を提供しています。この項では、発生する可能性のある既知の問題と必要な場合に対応するための回避策について説明します。

この項には次のトピックが含まれます:

- Oracle Multimediaのダウングレードおよびimrelod.sqlスクリプトのエラー

- Oracle Database Vaultおよびdvrelod.sqlスクリプトのエラー

- アップグレードの成功または失敗後のGrid Infrastructureスタンドアロン(Oracle Restart)のダウングレード

- Oracle ACFSおよびOracle Grid Infrastructureのダウングレードの問題

- ダウングレード後のデータベース・リンクのパスワードの問題

6.8.1 Oracle Multimediaのダウングレードおよびimrelod.sqlスクリプトのエラー

Oracle Databaseをリリース12.1からリリース11.2.0.2にダウングレードする場合、リリース11.2.0.2に付属するimrelod.sqlスクリプトからエラーが発生する場合があります。

ORA-20000: レジストリ内のOracle ORDIMコンポーネントのステータスがDOWNGRADEDです。Oracle Multimediaをアップグレード、ダウングレードまたはパッチ適用する前にOracle ORDIMをインストールし、有効化しておく必要があります。

原因: imrelod.sqlスクリプトがORDIMのステータスを認識していないために、このエラーが発生します。

処置: 処置は必要ありません。このエラーは無視しても支障ありません。

6.8.2 Oracle Database Vaultおよびdvrelod.sqlスクリプトのエラー

Oracle Databaseをリリース12.1からリリース11.2.0.3にダウングレードする場合に、Oracle Database Vaultを使用するデータベースで、リリース11.2.0.3に付属するdvrelod.sqlスクリプトからエラーが発生する場合があります。

ORA-31011: XML解析に失敗しました; リリース11.2.0.3へのOracle Database Vaultのダウングレード

原因: dvrelod.sqlスクリプトはXML解析のステータスを認識していません。

処置: 処置は必要ありません。このエラーは無視しても支障ありません。

6.8.3 アップグレードの成功または失敗後のGrid Infrastructureスタンドアロン(Oracle Restart)のダウングレード

Oracle Restartをダウングレードするには、構成解除してからOracle Grid Infrastructureを再インストールする必要があります。その後、データベースおよびサービスを戻すことができます。

関連項目:

- My Oracle Support(http://support.oracle.com)のサポート・ノート1364412.1

- アップグレード後のOracle Clusterwareのダウングレードの詳細は、『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』または『Oracle Grid Infrastructureインストレーション・ガイドfor Microsoft Windows x64 (64-Bit)』を参照してください。

6.8.4 Oracle ACFSおよびOracle Grid Infrastructureのダウングレードの問題

Oracle ASM Cluster File System (Oracle ACFS)を使用していて、Oracle Grid Infrastructure 12c (クラスタまたはOracle Restartスタンドアロン・サーバーのどちらの場合も)にアップグレードする場合、Oracle Grid Infrastructure 11g リリース2 (11.2)へのダウングレードを選択し、リリース11.2のソフトウェア・スタックの開始を試みる前にリリース11.2のOracleホームからコマンドacfsroot installを実行する必要があります。

関連項目:
ご使用のオペレーティング・システム・プラットフォームの問題および解決策の最新の情報については、『Oracle Databaseプラットフォーム共通日本語README』およびリリース・ノートを参照してください。

6.8.5 ダウングレード後のデータベース・リンクのパスワードの問題

Oracle Databaseリリース11.1にダウングレードした後、リリース11.2または12.1で作成されたデータベース・リンクのパスワードをリセットする必要があります。「Oracle Data Pumpのエクスポートを使用した、既存のすべてのデータベース・リンクが含まれるダンプ・ファイルの作成」を参照してください。データベース・リンク・パスワードをリセットしないと、そのデータベース・リンクを使用しようとすると内部エラーが表示されます。なお、Oracleサーバーがデータベース・リンクのパスワードを取得できないときにOracleトレース・ファイルに記録される内部エラーは、「ORA-00600: [kzdlk_zt2 err], [18446744073709551601]」です。

リリース11.1にダウングレードした後にデータベース・リンクのパスワードをリセットするには、ALTER DATABASE LINKコマンドを使用して元のパスワードをIDENTIFIED BY句に指定することで、パスワードを元のパスワードに戻します。ALTER DATABASE LINKについては『Oracle Database SQL言語リファレンス』を、データベース・リンクによって確立される接続の管理については『Oracle Database管理者ガイド』を参照してください。

このパスワードの問題がないOracle Databaseリリース11.2または12.1の実行中に新しいデータベース・リンクを作成する場合は、CREATE DATABASE LINKコマンドのIDENTIFIED BY VALUES句の使用方法について、Oracleサポートへお問い合せいただけます。

6.8.5.1 Oracle Data Pumpのエクスポートを使用した、既存のすべてのデータベース・リンクが含まれるダンプ・ファイルの作成

ダウングレードを実行する前に、Oracle Data Pumpのエクスポートを使用して、既存のすべてのデータベース・リンクが含まれるダンプ・ファイルを作成してください。これには、新しく作成したデータベース・リンクも含まれます。この手順では、expdpコマンドでFULL=YおよびINCLUDE=DB_LINKパラメータを使用します。既存のすべてのデータベース・リンクが含まれるダンプ・ファイルを作成するには、次の手順を実行します。

1. SQL*Plusにログインします。

sqlplus system/manager

2. ダンプ・ディレクトリが存在する場合は削除します。

SQL> DROP DIRECTORY dpump_dir;
SQL> CREATE DIRECTORY dpump_dir AS '/location_to_write_datapump_dump_file';

3. 次のようにデータベース・リンクをエクスポートします。

$ expdp system/manager FULL=Y directory=dpump_dir
dumpfile=saved_dblinks.dmp INCLUDE=DB_LINK;

4. トラブルシューティング用のオプション手順です。ダウングレードの後、ダウングレードしたいずれかのデータベース・リンクが適切に動作していない(たとえば、内部エラーORA-00600が表示される)場合、次のように、これを削除してダンプ・ファイルからインポートすることで、その後は意図したとおりに動作するようになります。

$ impdp system/manager directory=dpump_dir dumpfile=saved_dblinks.dmp;

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

Oracle Databaseのアップグレードを容易にするために、Oracle Data Pumpのエクスポートおよびインポート・ユーティリティを使用して、1つのデータベースから別のデータベースにデータを移行できます。Oracle Data Pumpでは、高パフォーマンスのエクスポート(expdp)およびインポート(impdp)ユーティリティが提供されています。

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

- データの移行でのデータ・ポンプおよびエクスポート/インポートの概要

- Oracle Databaseのアップグレード時のデータ・ポンプを使用したデータの移行

- Oracle Databaseのダウングレード時のデータ・ポンプの要件

関連項目:
データ・ポンプおよびエクスポート/インポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

7.1 データの移行でのデータ・ポンプおよびエクスポート/インポートの概要

1つのOracle Databaseから別のデータベースにデータを移行(移動)するための、データ・ポンプ・エクスポートおよびインポートが提供されています。これはOracle Databaseのアップグレード後に便利です。

データ・ポンプには次のような利点があります。

- オブジェクトおよびオブジェクトの種類に基づいてエクスポートおよびインポートされたメタデータを、INCLUDEおよびEXCLUDEパラメータを使用してフィルタ処理できます。

- データベースの一部を様々なモード(全体データベース・モード、スキーマ・モード、表モード、表領域モード、トランスポータブル表領域モードなど)でアンロード/ロードできます。(『Oracle Databaseユーティリティ』のデータ・ポンプ・エクスポートのモードおよびデータ・ポンプ・インポートのモードに関する説明を参照してください。)

- インポート操作中のパーティション表の処理方法を、PARTITION_OPTIONSパラメータを使用して指定できます。

- 全種類のデータ型がサポートされます。

関連項目:

- データ・ポンプ・エクスポートおよびインポートの概要は、『Oracle Databaseユーティリティ』を参照してください。

- この方法を使用するタイミングの詳細は、「Oracle Databaseのアップグレード時のデータの移行でエクスポート/インポートする方法」を参照してください。

7.2 Oracle Databaseのアップグレード時のデータ・ポンプを使用したデータの移行

Oracle Databaseソフトウェアをインストールする前にソース・データベースからデータをエクスポートし、その後、アップグレードしたターゲット・データベースにデータをインポートするためにOracle Data Pumpを活用できます。

アップグレード手順でOracle Data Pumpを使用するには、次の手順を実行します。

1. 現行データベースに付属のエクスポート・ユーティリティを使用して、現行データベースのデータをエクスポートします。現行データベースでのエクスポート・ユーティリティの使用方法の詳細は、現行の『Oracle Databaseユーティリティ』ドキュメントを参照してください。

一貫性のあるエクスポート結果を得るには、エクスポートの実行中と実行後は現行データベースが更新不可である必要があります。エクスポート実行後にユーザーが現行データベースを更新できるようにする場合は、現行データベースで行われた変更を、インポート完了後に新しいデータベースにコピーするための手順をプロシージャを配置し、その後で現行データベースを使用可能にします。

2. 新しいOracle Databaseソフトウェアをインストールします。Oracle Databaseのインストール手順は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。オペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

3. 新しいデータベースに現行データベースと同じ名前を付ける場合は、新しいデータベースを作成する前に現行データベースを停止します。

4. 新しいデータベースを作成します。

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

5. SQL*Plusを新しいOracle Database環境で起動します。

6. SYSDBA権限を持つユーザーとして、データベース・インスタンスに接続します。

7. STARTUPを使用してOracle Databaseインスタンスを起動します。

8. オプションで、ソース・データベースとは異なる記憶域パラメータを指定できます。
新しいデータベースに表領域、ユーザーおよび表を事前に作成し、記憶域パラメータを変更することにより、ディスク領域の使用状況を改善できます。SQL*Plusを使用して表を事前に作成する場合は、元のデータベースとの互換モードで実行するか、またはインポート中に発生する特定のデータ定義の変換を許可するようにします。

項目が事前に作成されている場合は、データ・ポンプ・インポートでTABLE_EXISTS_ACTION=APPENDオプションを指定します。

注意:
新しいデータベースをソース・データベースと同じコンピュータ上に作成し、ソース・データベースのデータ・ファイルを上書きしない場合は、事前に表領域を作成し、インポート時に次のオプションを指定する必要があります。

- データ・ポンプ・インポートでREUSE_DATAFILES=Nを指定
ダンプ・ファイル・セット内の古い名前に対する参照が、競合しない新しい名前にマップしなおされるように、REMAP_DATAFILE、REMAP_TABLESPACEおよびREMAP_TABLEオプションの使用を、必要に応じて検討します。

- オリジナルのインポート・ユーティリティでDESTROY=Nを指定

9. 新しいデータベースのインポート・ユーティリティを使用して、現行データベースからエクスポートしたオブジェクトをインポートします。インポート・セッションからファイルに情報メッセージやエラー・メッセージを保存するには、次のようにパラメータを組み込みます。

- データ・ポンプ・インポートでLOGFILEパラメータを指定

- オリジナルのインポート・ユーティリティでLOGパラメータを指定

関連項目:
インポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

10. インポート作業が完了したら、正常に終了した特定のオブジェクトのインポートに関する情報を、インポート・ログ・ファイルで確認します。失敗したものがある場合は、失敗したオブジェクトに関する情報を確認します。

関連項目:

- 『Oracle Databaseユーティリティ』

- 『Oracle Databaseプラットフォーム共通日本語README』

11. 『Oracle Databaseユーティリティ』に記載されているその他のインポート方法を使用するか、またはデータベース・オブジェクトを作成するSQLスクリプトを使用して、インポートに失敗したオブジェクトをクリーンアップします(または、完全に新規のインポートを開始します)。

注意:
データ・ポンプ・エクスポートまたはインポートのジョブでリカバリ不能なエラーが発生した場合は、エラーの原因となった条件を修正した後でジョブを再起動できます。ジョブは、エラーが発生した箇所から自動的に続行されます。

12. エクスポートの実行後に現行データベースに変更を加える場合は、ユーザーに使用可能にする前に、それらの変更が新しいデータベースに伝播されるようにします。この手順の手順1を参照してください。

13. 第4章「Oracle Databaseのアップグレード後の作業」に示す手順を実行します。

7.2.1 ネットワーク・リンクを使用したOracle Database全体のインポート

データベース・リンクを介してデータ・ポンプ・インポート・ユーティリティを使用して、中間ダンプ・ファイルなしでソース・データベースからインポート先データベースへデータベース全体のインポートを実行できます。この方法は、「Oracle Databaseのアップグレード時のData Pumpを使用したデータの移行」にかわる手順です。

注意:
相互運用性のエラーを回避するために、アップグレードするデータベースに適切なパッチ・セットが適用されていることを確認します。最新のパッチ・セットを取得するには、My Oracle Support(http://support.oracle.com)を参照してください。
また、サポート・ノートID 4511371.8で、ORA-6544およびORA-4052エラーに関する説明を参照することもできます。

データ・ポンプ・インポート・ユーティリティ(impdp)でネットワーク・リンクを使用するには、次の手順を実行します。

1. ソース・データベースでエクスポートを実行するユーザーにDATAPUMP_EXP_FULL_DATABASEロールがあることを確認します。
データベース・リンク作成時に、このユーザーを指定する必要があります。

2. インポート先データベースでインポートを実行するユーザーにDATAPUMP_IMP_FULL_DATABASEロールがあることを確認します。

3. ソース・データベースとインポート先データベースとの間にデータベース・リンクを作成してテストします。

4. 次のコマンドを実行します。import_userはインポートを実行するユーザーのユーザー名で、db_linkはエクスポートを実行するユーザーが所有するデータベース・リンクの名前です。

IMPDP import_user NETWORK_LINK=db_link FULL=Y;

5. インポート操作のログ・ファイルが、DATA_PUMP_DIRディレクトリに書き込まれます。このディレクトリの場所は、次のコマンドを実行して検出できます。

SQL> select * from dba_directories where DIRECTORY_NAME like 'DATA_PUMP_DIR';

注意:
XMLオブジェクトはソース・データベースからエクスポートされません。

関連項目:
データベース・リンクを使用したデータ・ポンプ・インポートの詳細は、My Oracle Support (http://support.oracle.com)のNote 466181.1を参照してください。

注意:
インポート操作によって新しいインポート先サーバーにユーザーが再作成され、dba_usersの作成日付は実際のインポート日付を示します。有効期限は、creation_date + password_life_timeに更新されます。新しいサーバーの上のdba_usersのパラメータは、インポート元サーバーの上のdba_usersパラメータとは異なります。

7.3 Oracle Databaseのダウングレード時のデータ・ポンプの要件

ダウングレード処理でData Pumpを使用すると、ダウングレードするOracle Databaseリリースを最大で1つ前のリリースにできます。

データ・ポンプ・エクスポートを使用して下位互換性のあるダンプ・ファイルを取得するには、次を行います。

- 現行のリリースでデータ・ポンプ・エクスポート・ユーティリティを使用し、VERSIONパラメータをダウングレードする以前のターゲットのリリースに設定します。
データ・ポンプ・インポートは、現在のデータベース・リリースより後のデータベース・リリースで作成されたダンプ・ファイル・セットを読み込むことができません(ただし、読み込むダンプ・ファイル・セットが、VERSIONパラメータをターゲット・データベースのリリース番号に設定して作成されている場合は除きます)。したがって、ダウングレードを行う際の最適な方法は、VERSIONパラメータをダウングレードするターゲット・データベースのリリース番号に設定して、データ・ポンプ・エクスポートを使用することです。

関連項目:
VERSIONパラメータの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

8 Oracle Database 12cで非推奨となった機能とサポートが終了した機能

Oracle Database 12cでは、新機能に加え、データベースの動作変更が導入されました。変更された動作には、非推奨になったかサポートが終了した初期化パラメータ、オプション、構文および機能とコンポーネントの非推奨およびサポート終了が含まれます。この章では、Oracle Database 12cで導入された新しい機能およびOracle Databaseの以前のリリースでの変更については説明しません。

この章では、このリリースで非推奨になったか、サポートが終了した機能での動作の変更について説明します。非推奨になると、機能は強化されなくなりますが、12.1リリースの有効期間中は引き続きサポートされます。サポートが終了すると、Oracleではその機能に関連するバグは修正されなくなり、コードが完全に削除される可能性があります。記載がある場合、非推奨となった機能は今後のメジャー・リリースではサポートされなくなる可能性があります。サポートの考慮事項の詳細は、My Oracle Support (http://support.oracle.com)を参照してください。

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

- Oracle Databaseの変更点

- Oracleビジネス・インテリジェンスおよびデータ・ウェアハウスの変更点

- Oracle Database Securityの変更点

- Oracleグローバリゼーション・サポートの変更点

- Oracle Multimediaの変更点

- Oracle Net Servicesの変更点

- Oracle XML Databaseの変更点

- Oracle Textの変更点

関連項目:

- このリリースで導入された新機能の完全なリストについては、『Oracle Database新機能ガイド』を参照してください。

- 新しい初期化パラメータ、新しい静的データ・ディクショナリ・ビューおよび新しい動的パフォーマンス・ビューのリストについては、『Oracle Databaseリファレンス』を参照してください。

- ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』

- 付録A「以前のリリースのOracle Databaseの変更点」

8.1 Oracle Databaseの変更点

Oracle Database 12cでは、一般に、Oracle Databaseに影響する変更が導入されました。

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

- 非CDBアーキテクチャの非推奨

- catupgrd.sqlスクリプトの非推奨および新しいcatctl.plユーティリティの導入

- Oracle Enterprise Manager Database Controlのサポート終了

- Oracleベースの削除およびクリーンアップに関する変更点

- 非推奨およびサポート終了のパラメータ

- 非推奨となったビュー

- Oracle Streamsの非推奨

- 非推奨となったアドバンスト・レプリケーション

- 1文字SRVCTL CLIオプションの非推奨

- Microsoft Windowsプラットフォームでのサポートが終了した機能

- クラスタ管理での管理ユーザーの格納されたリストの非推奨

- RAW記憶域デバイスのサポート終了

- QOSCTL Quality of Service (QoS)コマンドの-checkpasswdの非推奨

- VARCHAR2、NVARCHAR2およびRAWデータ型の変更

- JPublisherの非推奨

- Oracle JDBCおよびSQLJの変更点

- Oracle Call Interfaceの変更点

- resource_limitパラメータのデフォルトの変更

8.1.1 非CDBアーキテクチャの非推奨

非CDBアーキテクチャはOracle Database 12cでは非推奨で、Oracle Database 12c リリース2より後でサポートされず、使用できない場合があります。CDBアーキテクチャの使用をお薦めします。

注意:
CDBアーキテクチャで正常に動作しない機能がいくつか残っています(READMEの第2.2.1項「マルチテナント・コンテナ・データベースで制限される機能または使用できない機能」を参照)。これらの機能を使用する必要がある場合、それらがCDBアーキテクチャで正常に動作するようになるまで、非CDBアーキテクチャを使用してください。

8.1.2 catupgrd.sqlスクリプトの非推奨および新しいcatctl.plユーティリティの導入

Oracle Database 12cでは、新しいパラレル・アップグレード・ユーティリティ(catctl.pl)が導入されました。このユーティリティは、以前のリリースで使用されていたcatupgrd.sqlスクリプトを置き換えます。catupgrd.sqlの使用は可能ですが、Oracle Database 12cからは非推奨になり、今後のリリースでは削除されます。データベースのアップグレードは、新しいパラレル・アップグレード・ユーティリティ(catctl.pl)で実行することをお薦めします。

catctl.plの実行ではなく、catupgrd.sqlスクリプトを実行することを選択した場合、現在は、次のとおり、追加の入力パラメータが必要です。

SQL> catupgrd.sql PARALLEL=NO

パラメータを使用せずにcatupgrd.sqlを実行した場合、次のエラー・メッセージが表示されます。

NOTE

The catupgrd.sql script is being deprecated in the 12.1 release of
Oracle Database. Customers are encouraged to use catctl.pl as
the replacement for catupgrd.sql when upgrading the database dictionary.

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -n 4 catupgrd.sql

Refer to the Oracle Database Upgrade Guide for more information.

This database upgrade procedure must be called with the following
argument when invoking from the SQL prompt:

@catupgrd.sql PARALLEL=NO

関連項目:
catctl.plの情報および実行方法は、「Oracle Databaseのパラレル・アップグレード・ユーティリティの概要」を参照してください。

8.1.3 Oracle Enterprise Manager Database Controlのサポート終了

Oracle Database 12c以上では、Oracle Enterprise Manager Database Controlはサポートが終了したため、使用できません。代替として、Oracle Enterprise Manager Database Express (Oracle EM Express)が導入されました。Oracle EM Expressは、Oracle Database 12cにアップグレードするときにインストールされます。

関連項目:

- Oracle EM Expressの概要は『Oracle Database概要』を参照してください。

- Oracle EM Expressの使用の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- Oracle Enterprise Manager Cloud Controlの概要は、『Oracle Database概要』を参照してください。

8.1.4 Oracleベースの削除およびクリーンアップに関する変更点

次の各項目では、Oracleベースの削除およびクリーンアップに関する変更点について説明します。

- スタンドアロン削除ツールの変更点

- CLEANUP_ORACLE_BASEプロパティのサポート終了

- -cleanupOBaseの非推奨

8.1.4.1 スタンドアロン削除ツールの変更点

Oracle Database 12c以上では、削除スタンドアロン・ユーティリティは、Oracle Universal Installer (OUI)を使用した削除オプションに置き換えられました。削除ツールは、-deinstallおよび-homeオプションを指定して、LinuxおよびUNIXではrunInstallerコマンド(Windowsではsetup.exe)を使用して、Oracle Database、Oracle Database ClientまたはOracle Grid Infrastructureのインストール・メディアのベース・ディレクトリから実行することもできます。

関連項目:

- OUIおよびrunInstallerの使用の詳細は、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

- ご使用のオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』

8.1.4.2 CLEANUP_ORACLE_BASEプロパティのサポート終了

Oracle Database 12cでは、CLEANUP_ORACLE_BASEプロパティが削除され、サイレント・モードまたはレスポンス・ファイル・モードで削除中にOracleベースの削除はサポートされません。

8.1.4.3 -cleanupOBaseの非推奨

削除ツールの-cleanupOBaseフラグは、このリリースでは非推奨です。

関連項目:
ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』

8.1.5 非推奨およびサポート終了のパラメータ

Oracle Database 12cでは、一部のデータベース・パラメータは非推奨となりサポートが終了したか、削除されました。

現在の非推奨のパラメータのリストを取得するには、SQL*Plusで次の問合せを実行します。

SQL> SELECT name from v$parameter
WHERE isdeprecated = 'TRUE' ORDER BY name;

この問合せでは、実行した日時時点の非推奨のパラメータのリストが返されます。次の例は、表示される問合せ結果を示しています。

active_instance_count
background_dump_dest
buffer_pool_keep
buffer_pool_recycle
commit_write
cursor_space_for_time
fast_start_io_target
global_context_pool_size
instance_groups
lock_name_space
log_archive_start
max_enabled_roles
parallel_automatic_tuning
parallel_io_cap_enabled
parallel_server
parallel_server_instances
plsql_v2_compatibility
remote_os_authent
resource_manager_cpu_allocation
sec_case_sensitive_logon
serial_reuse
sql_trace
standby_archive_dest
user_dump_dest

8.1.5.1 LOG_ARCHIVE_LOCAL_FIRST

LOG_ARCHIVE_LOCAL_FIRST初期化パラメータは、Oracle Database 12cでは削除され、サポートが終了しました。

8.1.5.2 SEC_CASE_SENSITIVE_LOGON

SEC_CASE_SENSITIVE_LOGON初期パラメータは、このリリースでは非推奨になりました。SEC_CASE_SENSITIVE_LOGON初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

8.1.5.3 FILE_MAPPING

FILE_MAPPING初期化パラメータは非推奨です。これは、下位互換性を保つためにのみサポートされています。FILE_MAPPING初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

8.1.5.4 O7_DICTIONARY_ACCESSIBILITYパラメータのDELETE_CATALOG_ROLE

Oracle Database 12cでは、DELETE_CATALOG_ROLEロールは非推奨です。このロールおよびディクショナリ・オブジェクトの詳細は、『Oracle Databaseリファレンス』を参照してください。

8.1.5.5 RDBMS_SERVER_DN

RDBMS_SERVER_DNは、リリース12.1.0.2では非推奨です。かわりにLDAP_DIRECTORY_ACCESSを使用する必要があります。このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

8.1.6 非推奨となったビュー

次の各ビューは、Oracle Database 12cでは非推奨です。

- ALL_SCHEDULER_CREDENTIALSビュー。詳細は、『Oracle Databaseリファレンス』を参照してください。

- DBA_NETWORK_ACL_PRIVILEGESビュー。詳細は、『Oracle Databaseリファレンス』を参照してください。

- DBA_NETWORK_ACLSビュー。詳細は、『Oracle Databaseリファレンス』を参照してください。

- DBA_SCHEDULER_CREDENTIALSビュー。詳細は、『Oracle Databaseリファレンス』を参照してください。

- USER_NETWORK_ACL_PRIVILEGESビュー。詳細は、『Oracle Databaseリファレンス』を参照してください。

- USER_SCHEDULER_CREDENTIALSビュー。詳細は、『Oracle Databaseリファレンス』を参照してください。

- V$OBJECT_USAGEビュー。かわりにUSER_OBJECT_USAGEビューを使用してください。詳細は、『Oracle Databaseリファレンス』を参照してください。

関連項目:
スケジューラのジョブの資格証明の指定の詳細は、『Oracle Database管理者ガイド』を参照してください。

8.1.7 Oracle Streamsの非推奨

Oracle StreamsはOracle Database 12cでは非推奨となり、今後のOracle Databaseリリースではサポートが終了して使用できない場合があります。Oracle GoldenGateを使用して、Oracle Streamsのすべてのレプリケーション機能を置き換えます。

注意:
Oracle Databaseアドバンスド・キューイングはOracle Streamsとは無関係で、今後も機能強化されます。

関連項目:
詳細は、Oracle GoldenGateのドキュメントを参照してください。

8.1.8 非推奨となったアドバンスト・レプリケーション

Oracle Databaseアドバンスト・レプリケーションは、Oracle Database 12cでは非推奨です。Oracle GoldenGateを使用して、マルチマスター・レプリケーション、更新可能なマテリアライズド・ビュー、階層マテリアライズド・ビューおよびデプロイメント・テンプレートを含むアドバンスト・レプリケーションのすべての機能を置き換えます。

関連項目:
詳細は、Oracle GoldenGateのドキュメントを参照してください。

8.1.9 1文字SRVCTL CLIオプションの非推奨

サーバー制御ユーティリティ(SRVCTL)のコマンドライン・インタフェース(CLI)では、以前のリリースで使用されていた短いCLIオプションに加えて、GNUスタイルの長いオプションもサポートされます。Oracle Database 12c以上では、1文字オプションは非推奨で、後続のリリースではサポートが終了する可能性があります。

関連項目:
SRVCTLの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

8.1.10 Microsoft Windowsプラットフォームでのサポートが終了した機能

Oracle Database 12cでは、Windowsプラットフォームの一部の機能が非推奨になったかサポートが終了しました。次の各項では、これらの変更点について説明します。

- WindowsでのOracle COM Automationのサポート終了

- Oracle Objects for OLEのサポート終了

- Oracle Counters for Windows Performance Monitorのサポート終了

- WindowsでのOracle Cluster File System (OCFS)のサポート終了

- Oracle Data Provider for .NETの変更点

8.1.10.1 WindowsでのOracle COM Automationのサポート終了

Oracle Database 12cにはOracle COM Automationは含まれません。これは、Oracle Database 11g (データベース・コンポーネントOracle COM Automationを含む最後のデータベース・リリース)で非推奨になりました。ご使用のOracle COMアプリケーションをNET Frameworkなどの最近のテクノロジに移行することをお薦めします。

関連項目:
My Oracle Support (http://support.oracle.com)のNote 1175293.1「Obsolescence Notice: Oracle COM Automation」

8.1.10.2 Oracle Objects for OLEのサポート終了

Oracle Database 12cにはOracle Objects for OLEは含まれません。これはOracle Database 11gで非推奨となりました。コードをOLE DBデータ・アクセス標準およびActiveX Data Objects (ADO)に移行するか、アプリケーションを.NET (またはJavaあるいは別のアプリケーション・アーキテクチャ)に移行して別のドライバを使用できます。

関連項目:
My Oracle Support (http://support.oracle.com)のNote 1175303.1「Obsolescence Notice: Oracle Objects for OLE」

8.1.10.3 Oracle Counters for Windows Performance Monitorのサポート終了

Oracle Database 12cにはOracle Counters for Windows Performance Monitorは含まれません。これはOracle Database 11gで非推奨となりました。以前のリリースでは、カウンタはデフォルトではインストールされず、カウンタはWindows上でのみ動作します。監視には、Oracle Enterprise Manager Cloud Controlを使用することをお薦めします。

関連項目:
My Oracle Support (http://support.oracle.com)のNote 1175297.1「Obsolescence Notice: Oracle Counters for Windows Performance Monitor」

8.1.10.4 Oracle Data Provider for .NETの変更点

トランザクション・ガード用の次のOracle Data Provider for .NETアプリケーション・プログラミング・インタフェースは、Oracle Database 12c (12.1.0.2)では非推奨となり、今後のリリースではサポートされなくなる可能性があります。

- OracleLogicalTransactionStatusクラス

- OracleConnection.LogicalTransactionIdプロパティ

- OracleConnection.GetLogicalTransactionStatusメソッド

8.1.11 WindowsでのOracle Cluster File System (OCFS)のサポート終了

Oracle Database 12c以上では、Oracle Cluster File System (OCFS)のWindowsでのサポートが終了しました。このサポート終了通知によるLinuxでのOCFS (OCFSおよびOCFS2)のサポートおよび配布に対する影響はありません。

現在Windows上で、Oracleクラスタ・ファイル(Oracle Cluster Registryおよび投票ファイル)またはデータベース・ファイル、またはその両方をホストするためにOCFSを使用しているデータベースでは、Oracle Database 12cにアップグレードする前に、これらのファイルをOCFSに移行する必要があります。

関連項目:

- Oracle Automatic Storage Management (Oracle ASM)を使用するためのデータベースの移行の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- My Oracle Support (http://support.oracle.com)のNote 1392280.1「Desupport of Oracle Cluster File System (OCFS) on Windows with Oracle Database 12」

- 「Oracle Databaseリリース10.2または11.1およびOCFSとRAWデバイスのアップグレードの概要」

8.1.11.1 Oracle Databaseリリース10.2または11.1およびOCFSとRAWデバイスのアップグレードの概要

WindowsまたはRAWデバイスのOCFSにOracle Clusterwareファイルを格納するOracle Databaseリリース10.2.0.5またはリリース11.1.0.7環境をアップグレードする場合、Oracle Database 12cへ直接アップグレードすることはできません。まず、Oracle Databaseリリース11.2への中間アップグレードを実行し、Oracle ClusterwareファイルをOracle Automatic Storage Management (Oracle ASM)に移行する必要があります。その後、リリース11.2からOracle Database 12cにアップグレードできます。

関連項目:

- リリース10.2.0.5または11.1.0.7からのアップグレードの手順は、リリース11.2の『Oracle Databaseアップグレード・ガイド』を参照してください。Oracle Technology Network (http://www.oracle.com/technetwork/)からこのドキュメントをダウンロードする必要があります。

- Oracle Databaseソフトウェアのインストールの手順は、ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』を参照してください。

- Oracle Automatic Storage Management (Oracle ASM)を使用するためのデータベースの移行の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

8.1.11.2 OCFS用のcluvfy comp cfsのサポート終了

Oracle Cluster File System (OCFS)がサポートされなくなったため、cluvfy comp cfsコンポーネント検証コマンドはOracle Databaseから削除されました。

関連項目:
クラスタ管理の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

8.1.12 クラスタ管理での管理ユーザーの格納されたリストの非推奨

Oracle Database 12c以上では、管理ユーザーの格納されたリストを使用したクラスタの管理方法は、ポリシー・セットのアクセス制御リストを構成することによる管理ユーザー・ロールのより包括的な管理によって置き換えられています。

関連項目:
クラスタ管理の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

8.1.13 RAW記憶域デバイスのサポート終了

Oracle Database 12c以降、Oracle DatabaseおよびOracle Clusterwareなどの関連テクノロジは、RAW (ブロック)記憶域デバイスの直接使用をサポートしていません。つまり、Oracle Clusterware 12cにアップグレードするには、ファイルをOracle ASMまたはサポート対象の共有ファイル・システム(クラスタ・ファイル・システムまたはネットワーク・ファイル・システム(NFS))に移動する必要があります。

これは、Oracle ClusterwareのOCRおよび投票ファイルにも影響します。OCRまたは投票ファイルをRAWデバイスに格納することはできません。アップグレードする前に、RAWデバイス上に格納されているOracle Clusterwareファイルは、Oracle ASM、クラスタ・ファイル・システムまたはネットワーク・ファイル・システム(NFS)に移動する必要があります。

関連項目:
「Oracle Databaseリリース10.2または11.1およびOCFSとRAWデバイスのアップグレードの概要」

8.1.14 QOSCTL Quality of Service (QoS)コマンドの-checkpasswdの非推奨

構文qosctl -checkpasswd username passwordは非推奨となりました。QOSCTL構文およびコマンドの詳細は、『Oracle Database Quality of Service Managementユーザーズ・ガイド』を参照してください。

8.1.15 VARCHAR2、NVARCHAR2およびRAWデータ型の変更点

Oracle Database 12c以上では、COMPATIBLE初期化パラメータが12.0に設定され、MAX_STRING_SIZE初期化パラメータがEXTENDEDに設定されている場合に、VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズが32767バイトに増えました。

関連項目:
MAX_STRING_SIZEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

8.1.16 JPublisherの非推奨

2014年10月以降、Oracle JPublisherはOracle Database 12cリリース1で非推奨になり、またJPublisherのすべての機能はOracle Database 12cリリース2でサポート対象外となり、使用できなくなります。次に示す代替方法を使用することをお薦めします。

- 引き続きWebサービス・コールアウトを使用するには、Webサービス・コールアウト・ユーティリティの代わりとなるOJVM Webサービス・コールアウト・ユーティリティを使用することをお薦めします。

- PL/SQLプログラムおよびSQLオブジェクトにJavaクライアント・アプリケーションを作成するには、開発者は、Java STRUCTクラスの作成を支援する他のJDK開発ツールおよび他の事前構成済オプションを使用することをお薦めします。

関連項目:

JPublisherの非推奨およびサポート終了の詳細は、My Oracle SupportのNote 1937939.1を参照してください。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1937939.1

Oracle Technology NetworkのJDKツールおよびユーティリティ:

http://docs.oracle.com/javase/8/docs/technotes/tools/

8.1.17 Oracle JDBCおよびSQLJの変更点

Oracle Database 12cでは、Database (Oracle JVM)のJDBC、UCP、SQLJ、JPublisherおよびJavaに影響する一部の機能が非推奨になったかサポートが終了しました。JDBCのJavadocにも非推奨のすべてのAPIのページがあります。

次の機能は、このリリースのOracle JDBCおよびSQLJでは、非推奨になったかサポートが終了しました。

- サーバー内部SQLJの非推奨

- 非推奨となったOracleバッチ更新

- 非推奨となったEndToEndMetricsに関連するAPI

- 非推奨となったストアド・アウトライン

- 非推奨となったoracle.sqlパッケージの具象クラス

- 暗黙的接続キャッシュのサポート終了

8.1.17.1 サーバー内部SQLJの非推奨

データベース・サーバー内部でSQLJを使用することは、このリリースで非推奨です。データベース内部でSQLJアプリケーションを翻訳して実行する機能は、これらかのリリースでは使用できません。SQLJは、Oracle Databaseに接続し、クライアントとして実行するために使用するアプリケーションの翻訳用クライアント・ツールとしてのみ使用できます。SQLJはストアド・プロシージャ、ストアド・ファンクションまたはストアド・トリガー内部では使用できません。

8.1.17.2 非推奨となったOracleバッチ更新

Oracleバッチ更新はOracle Database 12cでは非推奨です。かわりに標準バッチ更新を使用してください。

次のAPIは非推奨となり、JDBCのJavadocでは非推奨とマークされます。

- OraclePreparedStatement.setExecuteBatch()

- OraclePreparedStatement.getExecuteBatch()

- OracleCallableStatement.setExecuteBatch()

関連項目:
Oracleバッチ更新の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

8.1.17.3 非推奨となったEndToEndMetricsに関連するAPI

EndToEndMetrics関連のAPIは、Oracle Database 12cでは非推奨です。かわりに、ユニバーサル接続プールを使用してください。

次のAPIは非推奨となり、JDBCのJavadocでは非推奨とマークされます。

- getEndToEndMetrics

- getEndToEndECIDSequenceNumber

- setEndToEndMetrics

- setApplicationContext

- clearAllApplicationContext

関連項目:
JDBCユニバーサル接続プールの詳細は、『Oracle Database JDBC開発者ガイド』およびJDBCのJavadocを参照してください。

8.1.17.4 非推奨となったストアド・アウトライン

ストアド・アウトラインは、Oracle Database 12cでは非推奨です。かわりに、計画ベースラインを使用してください。

関連項目:
計画ベースラインの詳細は、Oracle Database SQLJ開発者ガイドを参照してください。

8.1.17.5 非推奨となったoracle.sqlパッケージの具象クラス

oracle.sqlパッケージの具象クラスは、Oracle Database 12cでは非推奨です。これらは、oracle.jdbcパッケージの新しいインタフェースで置き換えられます。

関連項目:
oracle.jdbcの新しいインタフェースの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

8.1.17.6 非推奨となったdefineColumnTypeメソッド

JDBCメソッドdefineColumnTypeは、このリリースでは非推奨になりました。

8.1.17.7 非推奨となったCONNECTION_PROPERTY_STREAM_CHUNK_SIZEプロパティ

JDBCプロパティCONNECTION_PROPERTY_STREAM_CHUNK_SIZEは、このリリースでは非推奨になりました。

8.1.17.8 暗黙的接続キャッシュのサポート終了

暗黙的接続キャッシュは、Oracle Database 12cではサポートが終了しました。かわりに、ユニバーサル接続プールを使用してください。

関連項目:
詳細は、『Oracle Universal Connection Pool for JDBC開発者ガイド』を参照してください。

8.1.18 Oracle Call Interfaceの変更点

次のOracle Call Interface (OCI)機能はOracle Database 12cでは非推奨となり、将来のリリースでサポートが終了する可能性があります。

- sqlnet.oraのOCIデプロイ・パラメータは非推奨です。これらには次のパラメータが含まれます。

- OCIのクライアント結果キャッシュ・パラメータ: OCI_RESULT_CACHE_MAX_SIZE、OCI_RESULT_CACHE_MAX_RSET_SIZEおよびOCI_RESULT_CACHE_MAX_RSET_ROWS

8.1.19 resource_limitパラメータのデフォルトの変更

OracleのRESOURCE_LIMITパラメータは、リソース制限がデータベース・プロファイルで施行されるかどうかを判断します。このリリースでは、RESOURCE_LIMITパラメータはデフォルトでTRUEに設定されます。Oracleのリソース制限が無効化された場合、定義されたプロファイル制限は無視されます。これは、パスワード・リソースには適用されません。

SQL*Plusからresource_limit設定を確認するには、次のように実行します。

SQL> select value from v$parameter where name = 'resource_limit';

8.2 Oracleビジネス・インテリジェンスおよびデータ・ウェアハウスの変更点

Oracle Database 12cでは、ビジネス・インテリジェンス・アプリケーションおよびデータ・ウェアハウス・アプリケーションと機能が変更されています。

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

- Oracle Warehouse Builder (OWB)はOracle Databaseでインストールされない

- チェンジ・データ・キャプチャのサポート終了

- Oracle Data Miningモデルのアップグレードに対する変更点

- OLAPカタログ(AMD)のサポート終了

8.2.1 Oracle Warehouse Builder (OWB)はOracle Databaseでインストールされない

Oracle Database 12c以上では、Oracle Warehouse Builder (OWB)は、Oracle Databaseのソフトウェアの一部としてインストールされません。Oracle Warehouse Builderのインストーラは、Oracle Technology Networkで入手できます。以前のリリースから存在しているOWBコンポーネントは、Oracle Databaseのアップグレード処理の一部としてアップグレードされません。

関連項目:
「Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件」

8.2.2 チェンジ・データ・キャプチャのサポート終了

Oracleチェンジ・データ・キャプチャは、Oracle Database 12cに含まれておらず、Oracle GoldenGateに置き換えられました。

関連項目:
詳細は、Oracle GoldenGateのドキュメントを参照してください。

8.2.3 Oracle Data Miningのサポートが終了した機能

次の各Oracle Data Mining機能は、Oracle Database 12cではサポートが終了しました。

- Oracle Data Mining Java APIは使用できません。Oracle Data Mining 12cに対するプログラム・インタフェースは、DBMS_DATA_MININGおよびDBMS_DATA_MINING_TRANSFORMの2つのPL/SQLパッケージと、データのスコアリング用のSQL言語の関数ファミリで構成されます。

関連項目:
Data Mining PL/SQLパッケージの詳細は、Oracle Data Miningユーザー・ガイドを参照してください。

- Adaptive Bayes Network (ABN)アルゴリズムは使用できません。Oracle Data Mining 12cでは、ディシジョン・ツリーアルゴリズムはABNを置き換えます。

関連項目:
ディシジョン・ツリー・アルゴリズムの詳細は、Oracle Data Mining概要を参照してください。

8.2.4 Oracle Data Miningモデルのアップグレードに対する変更点

Oracle Database 12c以上では、Data Mining Java APIおよびAdaptive Bayes Network (ABN)アルゴリズムは、サポートが終了しました。そのため、Oracle Data Mining Java APIによって作成されたモデルは、Oracle Database release 11gからOracle Database 12cにはアップグレードできません。その他のすべてのモデルおよびメタデータは、リリース11gからOracle Database 12cへのアップグレード時に自動的にアップグレードされます。ABNモデルのアップグレードは可能ですが、Oracle Database 12cデータベースでそれらを使用することはできません。アップグレードの前または後にABNモデルを削除する必要があります。ABNモデルは、Oracle Database 12cデータベースで新しい分類モデルを作成することによって置き換えが可能です。

関連項目:
Data Mining APIおよびデータ・マイニング・モデルの詳細は、Oracle Data Miningユーザー・ガイドを参照してください。

8.2.5 OLAPカタログ(AMD)のサポート終了

Oracle Database 12c以上では、共通ウェアハウス・メタモデル(CWM)標準のOLAPカタログ(AMD)に対するサポートが終了しました。このサポートはOracle Database 11gリリース2 (11.2)で非推奨となりました。既存のデータベースでOLAPカタログにCWMメタデータがあり、Oracle Database 12cにアップグレードした場合は、アップグレードしたデータベースにはAMDコンポーネントがあります。アップグレードしたデータベースにAMDコンポーネントがない場合は、新しいOracle Database 12cインストールにAMDが含まれていないため、アップグレードしたOracle Database 12cデータベースにもAMDコンポーネントがありません。データベースにAMDコンポーネントがあり、それを削除する場合は、アップグレードの前後にORACLE_HOME/olap/admin/catnoamd.sqlスクリプトを実行します。

注意:
アップグレードするデータベースにOLAPカタログが存在する場合、AMD OLAP Catalog OPTION OFFおよび無効なCWM OLAPオブジェクトが表示されることがあります。無効なOLAPオブジェクトは不要なため、無視しても問題ありません。

関連項目:

- Java APIメタデータの詳細は、Oracle OLAP Java API開発者ガイドを参照してください。

- Oracle DatabaseのOLAPオプションおよびオンライン分析処理の詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

8.3 Oracle Database Securityの変更点

Oracle Database 12cでは、Oracle Database VaultおよびOracle Data Guardのセキュリティ機能とその他の領域が変更されています。この項の内容は次のとおりです。

- セキュリティ監査機能の変更点

- Oracle Label Securityで非推奨となった機能とパラメータ

- IGNORECASEおよびSEC_CASE_SENSITIVE_LOGONの非推奨

- SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨

- AUDIT_ADMINおよびAUDIT_VIEWERロールの注意

- NTLMプロトコルを使用したWindows NTS認証の非推奨

- 透過的データ暗号化に対する公開鍵インフラストラクチャの非推奨

- Secure Sockets Layer (SSL)の暗号スイートのサポート終了

- データベースのRules Manager (RUL)およびExpression Filter (EXF)のサポート終了

- Oracle Data Guard Brokerの変更点

- Oracle Database Vaultの変更点

- Oracle Databaseのセマンティク・テクノロジの変更点

8.3.1 セキュリティ監査機能の変更点

監査機能は、Oracle Database 12cで再設計されました。Oracle Database 12cで新しいデータベースを作成すると、監査の拡張機能のフル・セットが自動的に使用可能になります。以前のリリースからアップグレードした場合は、新しい監査機能の一部およびアップグレード元のリリースからの監査機能を使用するためのオプションが提供されます。最新の監査機能のフル・セットに移行することを強くお薦めします。

関連項目:

- 新しい監査機能およびセキュリティの変更の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- 「アップグレードしたOracle Databaseの統合監査の使用への移行」

8.3.2 Oracle Label Securityで非推奨となった機能とパラメータ

次のOracle Label Security機能はOracle Database 12cでは非推奨となり、将来のリリースでサポートが終了する可能性があります。

- LEAST_UBOUND。かわりにOLS_GREATEST_LBOUNDを使用します。GREATEST_LBOUNDでの下限の最大値の検索の詳細は、Oracle Label Security管理者ガイドを参照してください。

- LUBD。かわりにOLS_GLBDを使用します。OLS_GLBDの詳細は、Oracle Label Security管理者ガイドを参照してください。

- DOMINATES。OLS_DOMINATESのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- DOM。OLS_STRICTLY_DOMINATESのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- STRICTLY_DOMINATES。OLS_STRICTLY_DOMINATESのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- S_DOM。OLS_STRICTLY_DOMINATESのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- DOMINATED_BY。OLS_DOMINATED_BYのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- DOM_BY。OLS_DOMINATED_BYのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- STRICTLY_DOMINATED_BY。OLS_STRICTLY_DOMINATED_BYのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

- S_DOM_BY。OLS_STRICTLY_DOMINATED_BYのスタンドアロン機能の詳細は、Oracle Label Security管理者ガイドを参照してください。

8.3.3 非推奨となったDBMS_NETWORK_ACL_ADMIN PL/SQLパッケージのプロシージャ

Oracle Database 12cでは、DBMS_NETWORK_ACL_ADMIN PL/SQLパッケージの次のプロシージャは非推奨です。

- CREATE_ACL

- ADD_PRIVILEGE

- DELETE_PRIVILEGE

- ASSIGN_ACL

- UNASSIGN_ACL

- DROP_ACL

- ASSIGN_WALLET_ACL

- UNASSIGN_WALLET_ACL

- CHECK_PRIVILEGE

- CHECK_PRIVILEGE_ACLID

関連項目:
PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。

8.3.4 IGNORECASEおよびSEC_CASE_SENSITIVE_LOGONの非推奨

ORAPWDのIGNORECASE引数およびSEC_CASE_SENSITIVE_LOGONシステム・パラメータは、Oracle Database 12cでは非推奨です。デフォルトでは、Oracle Database 12cのパスワードでは大文字と小文字が区別されます。

関連項目:
認証およびパスワード保護の構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

8.3.5 SQLNET.ALLOWED_LOGON_VERSIONパラメータの非推奨

SQLNET.ALLOWED_LOGON_VERSIONパラメータはOracle Database 12cでは非推奨です。このパラメータは、次の2つの新しいOracle Net Servicesパラメータで置き換えられています。

- SQLNET.ALLOWED_LOGON_VERSION_SERVER (詳細は、『Oracle Database Net Servicesリファレンス』を参照してください)

- SQLNET.ALLOWED_LOGON_VERSION_CLIENT (詳細は、『Oracle Database Net Servicesリファレンス』を参照してください)

関連項目:

- この非推奨の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください

- 「SQLNET.ALLOWED_LOGON_VERSIONパラメータが設定されていないシステムのアップグレード」

- 「SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認」

8.3.5.1 SQLNET.ALLOWED_LOGON_VERSIONパラメータが設定されていないシステムのアップグレード

SQLNET.ALLOWED_LOGON_VERSIONパラメータが設定されていない(デフォルトの8を使用していた)システムをアップグレードする場合は、以前のリリースのクライアントとの互換性を維持するために、アップグレードしたOracle Database 12cサーバーで、SQLNET.ALLOWED_LOGON_VERSION_SERVERの値を8に設定する必要がある場合があります。それ以外の場合、アップグレードしたOracle Database 12cサーバーでSQLNET.ALLOWED_LOGON_VERSION_SERVER (または非推奨のSQLNET.ALLOWED_LOGON_VERSION_SERVER)パラメータを設定しないと、新しいOracle Database 12cの新しいデフォルト値が11になります。

Oracle Database 12cでSQLNET.ALLOWED_LOGON_VERSION_SERVERの新しいデフォルト値が11であることの影響は、Oracle Databaseリリース10g以上を使用しているクライアントがOracle Database 12cサーバーに接続できるようになることです。クリティカル・パッチ更新CPUOct2012以上のパッチが適用されていない、Oracle Databaseリリース11.2.0.3未満のリリースを使用しているクライアントは、10gのパスワード・バージョンを使用する必要があります。

設定12を使用すると最もセキュアになります。ただし、この設定ではOracle Database 12cクライアントの接続のみが許可されます。

関連項目:
『Oracle Databaseプラットフォーム共通日本語README』のパスワード推測攻撃に対する防御に関する説明を参照してください。SQLNET.ALLOWED_LOGON_VERSION_SERVERの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください

8.3.6 AUDIT_ADMINおよびAUDIT_VIEWERロールの注意

Oracle Database 12cには、アップグレードに影響するAUDIT_ADMINおよびAUDIT_VIEWERの2つのロールがデータベースに存在する可能性があります。

アップグレード前情報ツールおよびDBUAはアップグレード前チェックを実行して、データベースにそのようなユーザーまたはロールが存在しないことを確認します。データベースでそれらの名前を使用しないことをお薦めします。これらのユーザーまたはロールが存在する場合は、Oracle Database 12cにアップグレードする前に、必要に応じて、それらの名前を変更するか削除してください。

関連項目:
データベースのセキュリティに関する権限およびロール認証の構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

8.3.7 NTLMプロトコルを使用したWindows NTS認証の非推奨

Windowsユーザーは、NT Lan Manager (NTLM)プロトコルが必要なWindowsクライアントおよびサーバー上でNTSアダプタを使用して認証することはできません。セキュリティ脆弱性の理由から、NTLMは、Oracle Database 12cでは非推奨です。WindowsユーザーはKerberosは使用できます。NTLMは、ローカル・ユーザーの認証、およびデータベース・サービスがローカル・ユーザーで実行されている場合にはまだ使用できます。

新しいクライアント側sqlnet.oraのブール・パラメータNO_NTLM (デフォルト値はFALSE)を使用すると、NTS認証でNTLMを使用できるかどうかを制御できます。NO_NTLMをTRUEに設定すると、このパラメータ値により、NTLMがWindows NTS認証で使用されなくなります。

関連項目:
このリリースでのWindowsプラットフォームに影響する変更の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。

8.3.8 透過的データ暗号化に対する公開鍵インフラストラクチャの非推奨

透過的データ暗号化(TDE)に対する公開鍵インフラストラクチャ(PKI)は、Oracle Database 12cでは非推奨です。TDEを構成するには、ADMINISTER KEY MANAGEMENT SQL文を使用します。その他のPKIの実装に影響はありません。

関連項目:
TDEの構成の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

8.3.9 Secure Sockets Layer (SSL)の暗号スイートのサポート終了

Oracle Advanced Securityでは、Oracle Database 12cの次の暗号スイートのサポートが終了しました。

- SSL_DH_anon_WITH_DES_CBC_SHA

- SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

- SSL_RSA_EXPORT_WITH_RC4_40_MD5

- SSL_RSA_WITH_DES_CBC_SHA

関連項目:
サポートされるSSL暗号スイートの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

8.3.10 データベースのRules Manager (RUL)およびExpression Filter (EXF)のサポート終了

Oracle Database 12c以上では、Expression Filter (EXF)およびデータベースのRules Manager (RUL)機能のサポートが終了しました。Rules Managerを使用している場合、Oracle Fusion MiddlewareのコンポーネントであるOracle Business Rulesへの移行を検討することをお薦めします。Oracle DatabaseのContinuous Query Notification機能は、Expression Filterに置き換えられました。

このスクリプトはアップグレード・プロセスによって実行されます。アップグレード前にこれらのコンポーネントを削除する場合は、アップグレード前にcatnoexf.sqlスクリプトを実行できます。catnoexf.sqlスクリプトは、ORACLE_HOME/rdbms/admin/の下にあります。

関連項目:
My Oracle Support (http://support.oracle.com/)のSupport note 1244535.1「Rules Manager and Expression Filter Features of Oracle Database」

8.3.11 Oracle Data Guard Brokerの変更点

義務の分離機能に対するOracle Data Guard Brokerのサポートの一部として、Oracle Database 12cでは次のブローカ・プロパティが非推奨であり、代替となるものはありません。

- LsbyASkipCfgPr

- LsbyASkipErrorCfgPr

- LsbyASkipTxnCfgPr

- LsbyDSkipCfgPr

- LsbyDSkipErrorCfgPr

- LsbyDSkipTxnCfgPr

- LsbySkipTable

- LsbySkipTxnTable

8.3.12 Oracle Data Pumpのエクスポート・ユーティリティの変更点

Oracle Data PumpエクスポートのDATA_OPTIONSパラメータのXML_CLOBSオプションは非推奨です。

関連項目:
エクスポートのDATA_OPTIONSパラメータの詳細は、『Oracle Databaseユーティリティ』を参照してください。

8.3.13 Oracle Database Vaultの変更点

Oracle Database 12c以上では、Database Vaultコンフィギュレーション・アシスタント(DVCA)およびDatabase Vault Administrator (DVA)は非推奨になっています。Oracle Database Vaultの構成および管理にOracle Enterprise Manager Cloud Controlを使用します。

次のような追加のOracle Database Vault機能が、このリリースでは非推奨になっています。

- 非推奨となったデフォルトのルール・セット

- 非推奨となったデフォルトのレルム

- 非推奨となったAPI

8.3.13.1 非推奨となったデフォルトのルール・セット

次のルール・セットは、今回のリリースでは非推奨になっています。

- 「Oracle Data Pump操作を許可」ルール・セット

- 「スケジューラ・ジョブの許可」ルール・セット

関連項目:
デフォルトのルール・セットの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

8.3.13.2 非推奨となったデフォルトのレルム

Oracleデータ・ディクショナリのレルムおよびOracle Enterprise Managerのレルムは、このリリースでは非推奨になりました。以前Oracleデータ・ディクショナリのレルムで保護されていたオブジェクトは、新しいレルムに移行されています。

関連項目:
新しいレルムおよびデフォルトのレルムの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

8.3.13.3 非推奨となったAPI

DVSYS.DBMS_MACADM.SYNC_RULESプロシージャは、その機能がルール作成機能に組み込まれたため、非推奨となりました。

関連項目:
ルール作成の詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

8.3.14 Oracle Databaseのセマンティク・テクノロジの変更点

次の各機能は、Oracle Database 12cのOracle Databaseのセマンティク・テクノロジでは非推奨です。

- Oracle Databaseのセマンティク・テクノロジのVPDサポート

- Oracle Databaseのセマンティク・テクノロジのバージョン対応モデルのサポート

8.3.14.1 Oracle Databaseのセマンティク・テクノロジのVPDサポート

仮想プライベート・データベース(VPD)に依存する既存のセマンティク・テクノロジ・アプリケーションを、Oracle Label Security (OLS)をかわりに使用するように移行します。

関連項目:
RDFデータに対するファイングレインなアクセス制御の詳細は、Oracle Databaseのセマンティク・テクノロジ開発者ガイドを参照してください。

8.3.14.2 Oracle Databaseのセマンティク・テクノロジのバージョン対応モデルのサポート

セマンティク・データでワークスペース・マネージャの使用に対する具体的な代替方法は、アプリケーションの目的によって異なります。ユースケースおよび推奨される代替方法は、My Oracle SupportのNote 1468273.1を参照してください。

関連項目:
RDFデータに対するワークスペース・マネージャのサポートの詳細は、Oracle Databaseのセマンティク・テクノロジ開発者ガイドを参照してください。

8.4 Oracleグローバリゼーション・サポートの変更点

Oracle Database 12cでは、グローバリゼーションのサポート方法が変更されています。

このセクションには次のトピックが含まれます。

- CSSCANおよびCSALTERのサポート終了

8.4.1 CSSCANおよびCSALTERのサポート終了

Oracle Database Migration Assistant for Unicode (DMU)の導入に伴い、CSSCANおよびCSALTERのレガシー・データベース・ツールのサポート終了を進めています。DMUでは、データベース管理者に対する包括的なエンドツーエンドのユニコード移行ソリューションが提供されます。Oracle Database 12c以上では、DMUはOracle Databaseに含まれ、CSSCANおよびCSALTERツールは含まれず、サポートもされません。

関連項目:

- My Oracle Support (http://support.oracle.com/)のサポート・ノート「CSSCAN and CSALTER To Be Desupported After DB 11.2」(Doc ID 1418321.1)

- データベースのキャラクタ・セットの移行処理の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。

8.5 Oracle Multimediaの変更点

Oracle Database 12cでは、DICOMのORDImageサポートは非推奨です。

関連項目:
ORDImageの詳細は、Oracle Multimediaリファレンスを参照してください。

8.6 Oracle Net Servicesの変更点

このリリースでは、Oracle Net Servicesは非推奨で、一部の機能、パラメータおよびコマンドはサポートされません。この項には次のトピックが含まれます:

- Oracle Netの接続プーリングのサポート終了

- Oracle Namesのサポート終了

- Oracle Net Listenerパスワードのサポート終了

- Oracle Net ServicesのSQLNET.KERBEROS5_CONF_MITパラメータのサポート終了

- Oracle Net ServicesのOracle Names制御ユーティリティのサポート終了

- 非推奨となったOracle Net Services用のNT LAN Manager (NTLM)プロトコル

8.6.1 Oracle Netの接続プーリングのサポート終了

Oracle Database 12cでは、Oracle Netの接続プーリングはサポートされません。Oracle Netの接続プーリングはOracle Database 11gで非推奨となりました。これには、DISPATCHERS属性のTICKS、SESSIONSおよびCONNECTIONSが含まれます。

関連項目:
My Oracle Support (http://support.oracle.com/)のOracle Netの接続プーリングに関するサポート・ノート1469466.1

8.6.2 Oracle Namesのサポート終了

Oracle Namesは、Oracle Database 11g以上では、ネーミング・メソッドとしてサポートされていません。ディレクトリ・ネーミングに移行する必要があります。

関連項目:
ディレクトリ・ネーミングへの移行の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

8.6.3 Oracle Net Listenerパスワードのサポート終了

Oracle Database 12cでは、Oracle Net Listenerのパスワード機能はサポートされません。認証はローカル・オペレーティング・システムの認証機能によって実施されるため、セキュリティが失われることはありません。

関連項目:
Oracle Net Listenerのセキュリティの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

8.6.4 Oracle Net ServicesのSQLNET.KERBEROS5_CONF_MITパラメータのサポート終了

SQLNET.KERBEROS5_CONF_MITネットワーク・パラメータは、sqlnet.oraでは必要ありません(サポートされません)。このパラメータはデフォルトでFALSEに設定され、Kerberos構成に影響はありません。以前は、TRUEに設定すると、このパラメータは、MIT Kerberos 5で指定された形式で構成ファイルを解析することを指定していました。Oracle Database 12c以上では、この形式のKerberos構成のみがサポートされます。したがって、このパラメータは必要なくなりました。

関連項目:
sqlnet.oraファイルのKerberosパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

8.6.5 Oracle Net ServicesのOracle Names制御ユーティリティのサポート終了

Oracle Names制御ユーティリティは、サポートされておらず、Oracle Database 10g以上では使用できません。これには、関連するすべての制御ユーティリティ・コマンドが含まれます。Oracle Databaseクライアントは、接続文字列の解決にNames Serverを使用できません。アプリケーションをOracle Internet DirectoryにLDAPディレクトリ・ネーミングを使用して移行します。

関連項目:
ディレクトリ・ネーミング・メソッドの構成の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

8.6.6 非推奨となったOracle Net Services用のNT LAN Manager (NTLM)プロトコル

ドメイン認証用のNT LAN Manager (NTLM)プロトコルは、Oracle Windowsアダプタでは非推奨となっています。Kerberos認証のみがNTSアダプタで使用されます。

ヒント:
sqlnet.oraファイルのKerberosパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

8.7 Oracle XML Databaseの変更点

Oracle Databaseソフトウェアでインストールされた機能に加え、Oracle XML Databaseでは、Oracle Database 12cで次のような機能が変更されました。

- Oracle XML DBは必須でアンインストールできない

- Oracle XML Databaseの非推奨となった機能

- Oracle TextおよびOracle XML DBでのCTXXPATHのサポート終了

8.7.1 Oracle XML DBは必須でアンインストールできない

Oracle Database 12c以上では、Oracle XML DBは、Oracle Databaseの必須コンポーネントです。Oracle XML DBをアンインストールすることはできず、Oracle Databaseの作成時にそれを除外するためのオプションはありません。Oracle XML DBは、既存のデータベースをOracle Database 12cにアップグレードするときに自動的にインストールまたはアップグレードされます。

関連項目:
『Oracle XML DB開発者ガイド』

8.7.2 Oracle XML Databaseの非推奨となった機能

次の機能は今回のリリースで非推奨となり、今後のリリースではサポートされない可能性があります。完全なリストおよび詳細は、『Oracle XML DB開発者ガイド』を参照してください。

- XMLTypeのCLOB記憶域(非構造化記憶域とも呼ばれる)は非推奨になりました。かわりにXMLTypeのバイナリXML記憶域を使用してください。
無意味な空白を維持する必要がある場合は、元のXML文書のコピーを2つ(1つはデータベースとXMLの処理で使用するXMLTypeインスタンスとして、もう1つはドキュメントの再現性を実現するCLOBインスタンスとして)格納します。

- オブジェクト・リレーショナルXMLTypeデータに埋め込まれているCLOBインスタンスとして格納されたXMLフラグメントに対するXMLIndex索引の作成は、非推奨になりました。このようなフラグメントのデータを索引付けする必要がある場合は、オブジェクト・リレーショナル記憶域ではなく、バイナリXML記憶域を使用して文書を格納します。

- 次に示す、パッケージDBMS_XMLSCHEMA内のPL/SQLサブプログラムは非推奨になりました。

- generateSchema

- generateSchemas

これらの構造体の代用はなく、この変更に対する回避策はありません。

- DBMS_XDB_CONFIGは新しいPL/SQLパッケージです。Oracle XML DBのすべての構成関数、プロシージャおよび構造体は、パッケージDBMS_XDBからDBMS_XDB_CONFIGに移動されています。これらは、パッケージDBMS_XDBでは非推奨です。かわりにパッケージDBMS_XDB_CONFIGで使用することをお薦めします。
パッケージDBMS_XDBで非推奨となったサブプログラムは次のとおりです。

- ADDHTTPEXPIREMAPPING

- ADDMIMEMAPPING

- ADDSCHEMALOCMAPPING

- ADDSERVLET

- ADDSERVLETMAPPING

- ADDSERVLETSECROLE

- ADDXMLEXTENSION

- CFG_GET

- CFG_REFRESH

- CFG_UPDATE

- DELETEHTTPEXPIREMAPPING

- DELETEMIMEMAPPING

- DELETESCHEMALOCMAPPING

- DELETESERVLET

- DELETESERVLETMAPPING

- DELETESERVLETSECROLE

- DELETEXMLEXTENSION

- GETFTPPORT

- GETHTTPPORT

- GETLISTENERENDPOINT

- SETFTPPORT

- SETHTTPPORT

- SETLISTENERENDPOINT

- SETLISTENERLOCALACCESS

パッケージDBMS_XDBで非推奨となった定数は次のとおりです。

- XDB_ENDPOINT_HTTP

- XDB_ENDPOINT_HTTP2

- XDB_PROTOCOL_TCP

- XDB_PROTOCOL_TCPS

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』の「DBMS_XDB_CONFIG」

- XMLデータを更新するためのOracle SQL関数はすべて非推奨になっています。かわりに、XQuery Updateを使用することをお薦めします。非推奨のXML更新関数は次のとおりです。

- updateXML

- insertChildXML

- insertChildXMLbefore

- insertChildXMLafter

- insertXMLbefore

- insertXMLafter

- appendChildXML

- deleteXML

関連項目:
非推奨になったXMLデータの更新および置換に関する推奨については、『Oracle XML DB管理者ガイド』のOracle SQL関数を説明した付録を参照してください。

- Oracle SQL関数sys_xmlgenは非推奨になりました。かわりにSQL/XML生成関数を使用することをお薦めします。

関連項目:
XMLデータを作成するために使用できるSQL関数の詳細は、『Oracle XML DB管理者ガイド』を参照してください。

- 次のOracle XQuery関数は非推奨になりました。かわりに、対応する標準のXQuery関数(同じ名前に名前空間接頭辞fnの付いた関数)を使用してください。

- ora:matches: かわりにfn:matchesを使用

- ora:replace: かわりにfn:replaceを使用

- XML変換をサポートする次のOracle構造体は非推奨になりました。

- PL/SQLパッケージDBMS_XMLTRANSLATIONS

- Oracle XPath関数ora:translate

- XML Schema注釈xdb:maxOccurs、xdb:srclangおよびxdb:translate

これらの構造体の代用はなく、この変更に対する回避策はありません。

関連項目:
詳細は、『Oracle XML DB開発者ガイド』を参照してください。

- 次のXML Schema注釈は非推奨になりました。

- xdb:defaultTableSchema

- xdb:maintainOrder

- xdb:mapUnboundedStringToLob

- xdb:maxOccurs

- xdb:SQLCollSchema

- xdb:SQLSchema

- xdb:srclang

- xdb:storeVarrayAsTable

- xdb:translate

これらの構造体の代用はなく、この変更に対する回避策はありません。

- エクスポート・パラメータdata_optionsの値xml_clobsは、Oracle Database 12cから非推奨になりました。

関連項目:
XMLType表のエクスポートおよびインポートの情報については、『Oracle XML DB開発者ガイド』を参照してください。

8.8 Oracle Textの変更点

Oracle Database 12cでは、Oracle Textが変更が導入されました。

- Oracle TextおよびOracle XML DBでのCTXXPATHのサポート終了

- テキスト索引のALTER INDEX OPTIMIZEのサポート終了

- テキスト索引のSYNC [MEMORY memsize]のサポート終了

8.8.1 Oracle TextおよびOracle XML DBでのCTXXPATHのサポート終了

Oracle Database 12cで、CTXSYS.CTXXPATH索引のサポートは終了しました。これはCTXCATには影響しません。かわりにXMLIndex索引を使用します。

関連項目:
XMLIndexの詳細は、『Oracle XML DB開発者ガイド』を参照してください。

8.8.2 テキスト索引のALTER INDEX OPTIMIZEのサポート終了

ALTER INDEX OPTIMIZE [token index_token | fast | full [maxtime (time | unlimited)]操作は、Oracle Database 12cではサポートされません。索引を最適化するには、CTX_DDL.OPTIMIZE_INDEXを使用してください。

関連項目:
OPTIMIZE_INDEXの詳細は、『Oracle Textリファレンス』を参照してください。

8.8.3 テキスト索引のSYNC [MEMORY memsize]のサポート終了

SYNC [MEMORY memsize]操作は、Oracle Database 12cではサポートされません。索引を同期化するには、CTX_DDL.SYNC_INDEXを使用してください。

関連項目:
SYNC_INDEXの詳細は、『Oracle Textリファレンス』を参照してください。

A 以前のリリースのOracle Databaseの変更点

Oracle Database 10gリリース2 (10.2)、Oracle Database 11gリリース1 (11.1)およびOracle Database 11gリリース2 (11.2)の間には、動作に関する重要な変更点があります。一般に、Oracle Databaseのアップグレード後の動作の変更によって発生する可能性がある危険性を最小限に抑えるために、データベース管理者(DBA)は詳細な情報を得て決定を行う必要があります。

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

- Oracle Database 11gリリース2 (11.2)での動作の変更

- Oracle Database 11gリリース1 (11.1)での動作の変更

- Oracle Database 10gリリース2 (10.2)での動作の変更

関連項目:

- このリリースで導入された新機能の完全なリストについては、『Oracle Database新機能ガイド』を参照してください。

- 新しい初期化パラメータ、新しい静的データ・ディクショナリ・ビューおよび新しい動的パフォーマンス・ビューのリストについては、『Oracle Databaseリファレンス』のOracle Databaseリファレンスの新機能に関する説明を参照してください。

- ご使用のオペレーティング・システムの『Oracle Databaseインストレーション・ガイド』

注意:

- 付録A「以前のリリースのOracle Databaseの変更点」では、Oracle Databaseの各リリースで変更されたすべての動作および新機能については説明していません。新機能の完全な情報については、『Oracle Database新機能ガイド』を参照してください。

- この付録で示す初期化パラメータの一部は、オペレーティング・システム固有です。これらの初期化パラメータの詳細は、ご使用のオペレーティング・システム固有のOracleマニュアルを参照してください。

A.1 Oracle Database 11gリリース2 (11.2)での動作の変更

Oracle Database 11gリリース2 (11.2)では、互換性および相互運用性に影響を与える新機能および変更が導入されています。次の変更は、アップグレード処理に影響する可能性があります。

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

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

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

- 非推奨となったXML DB構造体

- Oracle Databaseで非推奨のCursor_sharing=similar

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

- データ・マイニングJava APIの非推奨

- 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パラメータの変更

A.1.1 Oracle Netリスナーで非推奨のSNMPサポート

Oracle Databaseのリリース11.2.0.3のOracle Net ListenerでSNMPサポートが非推奨となりました。新しい実装ではSNMPを使用しないことをお薦めします。

関連項目:
My Oracle Support (http://support.oracle.com)のNote 1341834.1「Planned end of support for SNMP in Oracle Net Listener」

A.1.2 PL/SQLプロシージャの変更点

一部のPL/SQLプロシージャは、Oracle Databaseのリリース11.2.0.3で、パッケージDBMS_XDBからパッケージDBMS_XDB_ADMINに移動されました。

DBMS_XDB_ADMINに移動されたプロシージャは、次のとおりです。

- moveXDB_tablespace

- rebuildHierarchicalIndex

関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

A.1.3 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のアップグレード時にこの設定を無視できます。データベースがUPGRADEモードでオープンされると、ジョブが実行できないようにdbms_jobまたはスケジューラ化で内部的に強制されます。UPGRADEモードでJOB_QUEUE_PROCESSESが何に設定されているかは問題ではありません。

関連項目:
このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

A.1.4 非推奨となった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記憶域のCLOB部分(オブジェクト・リレーショナル記憶域内に埋込みのCLOBデータ)上のXMLIndex索引

関連項目:
『Oracle XML DB開発者ガイド』

A.1.5 Oracle Databaseで非推奨のCursor_sharing=similar

cursor_sharing=similarパラメータはOracle Databaseリリース11.2.0.3では非推奨です。かわりに、適応カーソル共有を使用してください。

関連項目:
適応カーソル共有の詳細は、Oracle Database SQLチューニング・ガイドを参照してください

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

Oracleチェンジ・データ・キャプチャは、Oracle GoldenGateに置き換えられています。そのため、新しいアプリケーションにはOracle GoldenGateを使用することを強くお薦めします。

Oracle Database 11gリリース2(11.2)では、チェンジ・データ・キャプチャは以前のリリースと同様に機能します。チェンジ・データ・キャプチャを現在使用している場合、当分は引き続き使用できます。ただし、チェンジ・データ・キャプチャは今後、拡張はされません。

A.1.7 データ・マイニングJava APIの非推奨

Oracle Databaseのリリース11.2.0.3以上では、データ・マイニング Java APIは非推奨です。現在Oracle Data Miningでは、Oracle Data Minerの新しいリリースがサポートされています。以前のリリース(Oracle Data Miner Classic)は、Oracle Technology Network (OTN)からダウンロードして入手できますが、開発は終了しています。

A.1.8 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

A.1.9 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

A.1.10 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)

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

次の動的パフォーマンス・ビューは、Oracle Database 11gリリース2 (11.2)で非推奨となりました。

V$FLASH_RECOVERY_AREA_USAGE(V$RECOVERY_AREA_USAGEに変更)

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

Oracle Databaseの機能はOracle Database 11gリリース2 (11.2)で非推奨となりました。非推奨となった機能は、下位互換性のためにこのリリースでサポートされています。ただし、これらの非推奨となった機能は移行の対象外とすることをお薦めします。

- ディクショナリ管理表領域

- MAX_JOB_SLAVE_PROCESSES

ディクショナリ管理表領域

ローカル管理表領域を作成することをお薦めします。ローカル管理表領域は、ディクショナリ管理表領域より非常に効率的に管理されます。

MAX_JOB_SLAVE_PROCESSES

MAX_JOB_SLAVE_PROCESSESは非推奨となりました。かわりにJOB_QUEUE_PROCESSESを使用してください。

A.1.13 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以上に設定した場合のみです。

A.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)で非推奨となった機能

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

- Oracle 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パラメータの新しいデフォルト設定

- 自動診断リポジトリ

A.2.1 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に変更)

A.2.2 Oracle Database 11gリリース1 (11.1)でサポート終了の初期化パラメータ

次の初期化パラメータは、Oracle Database 11gリリース1 (11.1)でサポートが終了しました。

DDL_WAIT_FOR_LOCKS
LOGMNR_MAX_PERSISTENT_SESSIONS
PLSQL_COMPILER_FLAGS

注意:
サポートが終了した1つ以上の初期化パラメータを使用してデータベースを開始することはできますが、警告が返され、アラート・ログに記録されます。

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

Oracle Database 11gリリース1(11.1)では、次の静的データ・ディクショナリ・ビューの列が削除されました。

静的データ・ディクショナリ・ビュー

削除された列

V$DATAFILE

PLUGGED_IN

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

この項では、Oracle Database 11gリリース1(11.1)で非推奨となった機能を示します。下位互換性を保持する目的で、これらの機能がこのリリースでサポートされています。ただし、これらの非推奨となった機能は移行の対象外とすることをお薦めします。

- Oracle Ultra Search
Oracle Secure Enterprise Searchを使用することをお薦めします。

- Java Development Kit(JDK)1.4
JDK 5.0の使用をお薦めしますが、JDK 1.5も完全にサポートされます。

- CTXXPATH索引
かわりにXMLIndexを使用することをお薦めします。

関連項目:
『Oracle XML DB開発者ガイド』

A.2.5 自動メンテナンス・タスク管理

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管理者ガイド』を参照してください。

A.2.6 Oracle ASM管理用の新しいSYSASM権限とOSASMグループ

Oracle Database 11gリリース1 (11.1)には、Oracle ASM管理タスクの実行目的に特化した新しいSYSASM権限が導入されています。SYSDBA権限のかわりにSYSASM権限を使用することにより、ASMの管理職務とデータベースの管理職務を明確に区別できます。

ディスク・グループのメンテナンス(CREATE DISKGROUP、MOUNT/DISMOUNT、ADD/DROP DISK、ONLINE/OFFLINE DISK、DROP DISKGROUP)をSYSDBAで実行すると、Oracle ASMのalert.logに警告メッセージが表示されます。これらの作業はSYSDBAでは非推奨になっており、SYSASMで実行する必要があります。

OSASMは、Oracle ASM専用に使用される新しいオペレーティング・システム・グループです。OSASMグループのメンバーはオペレーティング・システム認証を使用してAS SYSASMで接続が可能であり、Oracle ASMに対するすべてのアクセス権限を持ちます。

関連項目:
Oracle ASMインスタンスへのアクセスの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

A.2.7 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 Automatic Storage Management管理者ガイド』を参照してください。

A.2.8 COMPUTE STATISTICS句およびESTIMATE STATISTICS句

以前のリリースでは、ANALYZE...COMPUTE STATISTICSおよびANALYZE...ESTIMATE STATISTICS句を使用して、索引での統計の収集を開始および停止できました。これらの句はサポートが終了しています。Oracle Database 11gリリース1(11.1)では、索引の作成中および再構築中に統計が自動的に収集されます。今回のバージョンでは、これらの句はサポートされていません。

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

Oracle Database 11gリリース1(11.1)へのアップグレード中に、DMSYSスキーマ・オブジェクトは大きな制約もなく、ユーザー・スキーマに存在するユーザー・モデルとともにアップグレードされます。アップグレード完了時に、マイニングのメタデータはSYSスキーマに移行されますが、ユーザー・モデルは新しいメタデータで継続して機能します。COMPATIBLE初期化パラメータを11.0.0に設定した後、DMSYSスキーマを削除することをお薦めします。また、DBAは、既存のユーザーが引き続きマイニング・モデルを作成できるように、新しい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)にデータベースをダウングレードする場合は、ダウングレードする前に新しいマイニング・モデルを削除する必要があります。

A.2.10 Oracle Data Miningスコアリング・エンジン

Oracle Database 11gリリース1(11.1)以上では、Oracle Data Mining Scoring Engineのインストールができなくなりました。

関連項目:
Oracle Data Miningユーザー・ガイド

A.2.11 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プロファイルが使用できないということはありませんでした。SYSAUX表領域をオフラインにすると、SQLのパフォーマンスに影響が出る可能性があります。

下位互換性

Oracle Database 11gリリース1(11.1)では、下位互換性は次のようになっています。

- SQL文のストアド・アウトラインがユーザー・セッションに対してアクティブな場合(たとえば、ストアド・アウトラインのカテゴリがユーザー・セッションのカテゴリと一致する場合)、文はストアド・アウトラインを使用してコンパイルされます。

- SQL文に対してプライベート・アウトラインが使用可能な場合、文はプライベート・アウトラインを使用してコンパイルされます。

SQL文に対してストアド・アウトラインが使用可能な場合、SQL計画管理機能は使用されません。ただし、別のユーザー・セッションで同じSQL文がアクティブなストアド・アウトラインなしで使用されている場合は、SQL計画管理機能が使用されます。

関連項目:

- SQL計画管理の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

- DBMS_SPMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

A.2.12 Oracle XML DatabaseでのバイナリのXMLのサポート

Oracle Database 11gリリース1(11.1)の新しいオプションであるバイナリのXML記憶域オプションは、COMPATIBLE初期化パラメータを11.0.0以上に設定した場合に使用できます。この記憶域オプションを使用して表または列を作成すると、互換性の最小要件が確認されます。最小要件は、バイナリのXMLドキュメントを直接XML DBリポジトリに格納しようとしたときにも確認されます。

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

データベースをOracle Database 11gリリース1(11.1)にアップグレードするときに、既存のユーザーXMLType表およびインスタンスの変更は一切行われません。アップグレードの完了後に、新しい記憶域形式を使用して既存の表を変更したり、その後で新しい表を作成することができます。XML DBの表XDB$CONFIGおよびXDB$ACLと、対応するXMLスキーマは、データベースをOracle Database 11gリリース1 (11.1)にアップグレードするときに、バイナリのXML記憶域に移行されます。

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

Oracle Database 11gリリース1(11.1)のPL/SQLでは、互換性および相互運用性が変更されました。

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

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

A.2.13.1 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のみが残されています。したがって、DBAはPL/SQLネイティブ・コンパイルを考慮する必要はありません。

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

ネットワーク・ユーティリティ・パッケージに対するアクセス制御のデフォルトの動作が変更され、権限を持たないすべてのユーザーに対してネットワーク操作が許可されなくなりました。このデフォルトの動作はこれまでのバージョンのOracle Databaseとは異なる動作であり、互換性がなくなりました。

Oracle Database 11gリリース1(11.1)にアップグレードするデータベース・ユーザーの場合、PL/SQLネットワーク・ユーティリティ・パッケージに依存するアプリケーションは問題なくコンパイルできます。ただし、権限が必要なネットワーク操作を実行しようとすると、実行時にアプリケーションで例外が受信される可能性があります。ネットワーク操作の実行に必要な権限をワイルドカードを使用してPUBLICに付与することで互換性を回復することはできますが、データベース管理者はそれぞれの状況を個別に慎重に調査し、必要な場合にのみ権限を付与することを強くお薦めします。

注意:
Oracle XML DBでは、アクセス制御リストを適切に維持する必要があります。まだシステムにOracle XML DBがインストールされていない場合は、アップグレード作業中にインストールされます。

関連項目:
「外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成」

A.2.14 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は非推奨です。

A.2.15 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開発者ガイド』を参照してください。

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

DBMS_OLAPパッケージは非推奨でり、SQLアクセス・アドバイザに置き換えられています。

A.2.17 SQLアクセス・アドバイザのタスク

SQLアクセス・アドバイザ・リポジトリの内部構造が変更されたため、データベースをアップグレードすることにより、既存のSQLアクセス・アドバイザのタスクはすべて初期状態にリセットされます。つまり、アップグレード前に正常に完了していたタスクに対する推奨情報は、すべて削除されます。

アップグレード後に、既存のSQLアクセス・アドバイザのタスクを再実行することにより、推奨情報を回復できます。

A.2.18 Standard Editionの初期データベース

Standard Edition(SE)の初期データベースをアップグレードする場合、次のコンポーネントに必要なオプションがStandard Editionにはインストールされていないため、次のコンポーネントはSEサーバーでアップグレードすることはできません。

- OLAPカタログ

- OLAPアナリティック・ワークスペース

- Oracle OLAP API

アップグレード後、これらのコンポーネントをDBA_REGISTRYビューで参照すると、STATUSの値がOPTION OFFと表示され、関連付けられたコンポーネント・スキーマに無効なオブジェクトが含まれます。Database Upgrade Assistant(DBUA)には、これらのコンポーネントのアップグレードが失敗したことが表示されます。

A.2.19 コア・ダンプの位置

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という名前のディレクトリに配置されます。

A.2.20 UNDO_MANAGEMENTの新しいデフォルト値

Oracle Database 11gリリース1(11.1)以上では、UNDO_MANAGEMENTパラメータのデフォルト値はAUTOであるため、自動UNDO管理はデフォルトで有効になっています。パラメータをMANUALに設定し、必要に応じて自動UNDO管理をオフにする必要があります。

UNDO_MANAGEMENTおよびROLLBACK_SEGMENTS初期化パラメータは、基本初期化パラメータから基本初期化パラメータ以外に変更になりました。正しく効率的に実行するためにほとんどのデータベースで必要とされているのは、基本パラメータの設定のみです。

関連項目:
『Oracle Databaseリファレンス』の「UNDO_MANAGEMENT」

A.2.21 LOG_ARCHIVE_DEST_nパラメータ

LOG_ARCHIVE_DEST_nパラメータを使用して、Oracle Standard Editionを実行するデータベース・インスタンス上にローカルのアーカイブ先を指定できます。以前は、このパラメータで指定できるのはOracle Enterprise Editionを実行するデータベース・インスタンス上のみでした。

A.2.22 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に設定します。

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

Oracle Database 11gリリース1(11.1)以上では、JOB_QUEUE_PROCESSES初期化パラメータは基本パラメータから基本パラメータ以外に変更になりました。正常かつ効率的に稼働するために、多くのデータベースで基本的なパラメータのみが設定されている必要があります。デフォルト値も、0から1000に変更されます。

Oracle Databaseによって、ジョブ・キューの設定が上書きされ、アップグレード・モード中にスケジューラ・ジョブが無効化されます。したがって、Oracle Databaseのアップグレード時にこの設定を無視できます。データベースがUPGRADEモードでオープンされると、ジョブが実行できないようにdbms_jobまたはスケジューラ化で内部的に強制されます。UPGRADEモードでJOB_QUEUE_PROCESSESが何に設定されているかは問題ではありません。

関連項目:
このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

A.2.24 自動診断リポジトリ

アラート・ログおよびトレース・ファイルの場所は、初期化パラメータBACKGROUND_DUMP_DESTおよびUSER_DUMP_DESTによっては設定されなくなりました。これらは自動診断リポジトリ(ADR)に保持されるようになり、自動診断リポジトリの場所は初期化パラメータDIAGNOSTIC_DESTによって設定されます。

関連項目:
診断情報の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

A.3 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に対する新しい制限

A.3.1 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

A.3.2 Oracle Database 10gリリース2 (10.2)でサポート終了の初期化パラメータ

次の初期化パラメータは、Oracle Database 10gリリース2 (10.2)でサポートが終了しました。

注意:
サポートが終了した1つ以上の初期化パラメータを使用してデータベースを開始することはできますが、警告が返され、アラート・ログに記録されます。

ENQUEUE_RESOURCES

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

Oracle Database 10gリリース2(10.2)では、次の静的データ・ディクショナリ・ビューの列が削除されました。

静的データ・ディクショナリ・ビュー

削除された列

DBA_HIST_SQLBIND

CHILD_NUMBER

A.3.4 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開発者ガイド』を参照してください。

A.3.5 CONNECTロール

Oracle Database 10gリリース2(10.2)より前のリリースからアップグレードした後は、CONNECTロールに含まれる権限はCREATE SESSIONのみになり、前のリリースでCONNECTロールに付与されていた他の権限は、アップグレード時に取り消されます。

A.3.6 タイムゾーン・ファイル

Oracle Database 10gリリース2(10.2)に付属のタイムゾーン・ファイルはバージョン4からバージョン8に更新され、一部のタイムゾーン地域の変換ルールに対して行われた変更が反映されています。これらの変更は、TIMESTAMP WITH TIME ZONEデータ型の既存のデータに影響する場合があります。

A.3.7 FAILED_LOGIN_ATTEMPTSに対する新しい制限

Oracle Database 10gリリース2(10.2)では、DEFAULTプロファイルに対するFAILED_LOGIN_ATTEMPTSの制限は10です。Oracle Database 10gリリース2(10.2)より前のリリースでは、デフォルトはUNLIMITEDでした。

索引
A  B  C  D  E  F  G  H  I  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

A

アクセス制御リスト(ACL)

11gリリース1(11.1)における動作の変更, A.2.15

ネットワーク・ユーティリティ・パッケージへのアクセス権の付与, 2.5.2.1

ネットワーク・ユーティリティ・パッケージのアクセス制御, A.2.13.2 ネットワーク・ユーティリティ・パッケージのACLの追加, 2.5.2.2 ALTER DATABASE RECOVER TO LOGICAL STANDBY文, 2.2.8 アプリケーション・コード

アップグレード後に変更されない, 5.6.1

アプリケーション

互換性, 5.2

リンクされてアップグレード, 5.5.2

より新しいライブラリへのリンク, 5.5.2.1

古いサーバーでの実行, 5.5.1.2

アップグレード, 5

クライアント/サーバー構成, 5.4

互換性規則, 5.5

オプション, 5.6

再リンク規則, 5.5

apxrelod.sqlファイル

ダウングレード後の再ロード, 6.4

ASM_PREFERRED_READ_FAILURE_GROUPS, 4.8.4 属性

xdb:defaultTableSchema (非推奨), 8.7.2

xdb:maintainOrder (非推奨), 8.7.2

xdb:mapUnboundedStringToLob (非推奨), 8.7.2

xdb:maxOccurs (非推奨), 8.7.2

xdb:SQLCollSchema (非推奨), 8.7.2

xdb:SQLSchema (非推奨), 8.7.2

xdb:srclang (非推奨), 8.7.2

xdb:storeVarrayAsTable (非推奨), 8.7.2

xdb:translate (非推奨), 8.7.2

監査

統合監査移行

概要, 4.6.13

監査オプション, 4.6.13.1

非統合監査に関するドキュメント参照, 4.6.13.5

移行後の古い監査レコードの管理, 4.6.13.3

手順, 4.6.13.2

統合監査の削除, 4.6.13.4

自動診断リポジトリ(ADR), 1.1.3 自動メンテナンス・タスク管理

AutoTask, A.2.5

自動ストレージ管理(ASM)

アップグレード, 2.2.5

自動UNDO管理

移行, 4.6.10

UNDO_MANAGEMENT, A.2.20

AutoTask, A.2.5

B

データベースのバックアップ, 2.6

バックアップ

バックアップ・モード, ファイル, 2.5.2.9

バックアップ

アップグレード後, 4.6.1

ダウングレード前, 6.3

計画の準備, 2.1.6

ベンチマーク, 2.1.5.7 プリコンパイラおよびOracle Call Interface (OCI)アプリケーションのアップグレード用のオプションの利点, 5.6 バイナリのXML記憶域, A.2.12

C

データベースのワークロードの取得およびリプレイ, 2.1.5.6.1

大/小文字区別

パスワード用, 4.6.4

catcon.pl, 1.1.2, 3.4, 3.5, 6.5 catctl.pl, 1.1.2 catdwgrd.sql, 1.1.2 catdwgrd.sqlスクリプト, 6.5, 6.5, 6.5, 6.5, 6.5 catnoamd.sql, 1.1.2 catnoexf.sql, 1.1.2 CATRELOD.SQLスクリプト, 6.5, 6.6 CATUPGRD.SQLスクリプト

手動アップグレード。「CATCTL.PLスクリプト」を参照

手動アップグレード

catuppst.sql, 1.1.2 CDB, 3.2.1

アップグレード, 3.1

パスワードの変更

オラクル社が提供するアカウント, 4.11.1

新機能を使用するためのスクリプトの変更, 5.7 クライアントおよびサーバー

構成とアップグレード, 5.4.2

アップグレードのタイプ, 5.4.1

クライアント・ソフトウェア

アップグレード, 5.5.2

クライアント/サーバー構成, 1.6 クライアント側ダイナミック・ライブラリ, 5.5.2.3 CLUSTER_DATABASE初期化パラメータ, 2.7, 3.10.1 互換性

アプリケーション, 5.2

Oracleリリース間, 1.7

非互換性の調査, 6.2

COMPATIBLE初期化パラメータ, 1.7.1.1

ダウングレード, 1.7.1.4

Oracle Databaseの概要, 1.7.1

COMPATIBLE初期化パラメータ, 1.7.1.1, 4.8.3

レベルの確認, 1.7.1.6

ダウングレードの考慮点, 1.7.1.4

デフォルト, 1.7.1.1

推奨事項, 1.7.1.7

設定, 4.11.6.1

値, 1.7.1.2

コンポーネントのステータス, 3.10.13 圧縮

sqlnet.oraファイル・パラメータ, 2.8

圧縮方法, 2.8

SQLNET.COMPRESSION, 2.8

SQLNET.COMPRESSION_LEVELS, 2.8

SQLNET.COMPRESSION_THRESHOLD, 2.8

構成ファイル

コピー, 2.7

構成ファイルのコピー, 2.7 CREATE pfile FROM spfile, 2.7 CREATE TABLE AS, 1.1.1 crsuserユーザー, 2.2.6 CSSデーモン

Cluster Synchronization Servicesデーモン, 2.2.6

カーソル・キャッシュ, SMB, 2.1.5.6.3

D

データのコピー

エクスポート/インポートの使用, 7

データ・ディクショナリ

アプリケーションに影響する変更の概要, 5.2

データ・ファイル

アップグレードした環境の再配置, 2.2.1

データ・マイニング・モデル, A.2.9 データ・ポンプ・エクスポート/インポート

使用のメリット, 2.1.3.3

推奨事項, 7.1

オリジナルのエクスポート/インポートとの対比, 7.1

使用のタイミング, 7.1

本番データベースのサブセット, 2.9

データベース・リンク, 2.5.2.3 データベースのごみ箱

消去, 2.5.2.11

データベース・リプレイ

アップグレード前のデータベースのワークロード, 2.1.5.6.1

Database Upgrade Assistant(DBUA)

メリット, 2.1.3.1

listener.oraファイルへのデータベースの登録, 2.8

実行, 3.2

サイレント・モード, 3.2.6

起動, 3.2.2, 3.2.3

Database XE, 1.13 データベース

ダウングレード, 6.5

クライアント・ソフトウェアのアップグレード, 5.5.2

DBA_RECYCLEBIN文, 2.5.2.11 DBA_REGISTRYビュー, 3.10.13 DBMS_DSTパッケージ, 2.5.2.4 DBMS_DST PL/SQLパッケージ

ORA-01822 タイムゾーンのリージョンが見つからないエラー, 3.10.11

DBMS_LDAPパッケージ, 2.5.2.1 DBMS_LDAP.initパラメータ, 2.5.2.1 DBMS_NETWORK_ACL_ADMINパッケージ, 2.5.2.2 DBMS_STATSパッケージ

統計表のアップグレード, 4.3.7

DBMS_STATS.GATHER_DICTIONARY_STATSプロシージャ, 2.5.2.5 DBUA。「Database Upgrade Assistant」を参照 defaultTableSchema属性(非推奨), 8.7.2 非推奨となったパラメータとサポートが終了したパラメータの表示, 2.7 開発者アプリケーション

Formsのアップグレード, 5.8

診断ログ・ファイル

場所, 1.1.3

DIAGNOSTIC_DEST, 1.1.3 直接のアップグレード, 2.1.2, 2.1.2 ディスク・グループの互換性, 4.8.3 ディスク

優先読取りの障害グループの指定, 4.8.4

分散トランザクション

未処理の解決, 2.5.2.10

DMSYSスキーマ・オブジェクト, A.2.9 ダウングレード

データベースのバックアップ, 6.3

バイナリのXML記憶域, A.2.12

CATRELOD.SQL, 6.5, 6.6

非互換性の調査, 6.2

Oracle Enterprise Manager, 6.7.5

ORADIM, 6.5

パッチ・セット・リリース, 6.1

手順, 6.5

スクリプト, 6.5

再実行, 6.5

ダウンストリーム取得

Oracle Streams, 2.2.11

E

emca -restoreコマンド, 6.7.5

emdwgrd, 1.1.2

emdwgrdユーティリティ, 1.1.2, 2.2.3, 6.7.5

データベースのごみ箱を空にする, 2.5.2.11

emremove.sql, 1.1.2

パスワードの大/小文字区別の強制, 4.6.4

環境変数

アップグレードに必要, 3.4, 3.5

数値リテラルの評価, 5.7.1 エクスポート・ユーティリティ, 7.1

データのコピー, 7

エクスポート/インポート

メリットおよびデメリット, 2.1.3.3

メリット, 2.1.3.3.2

アップグレードされたデータベースへの影響, 2.1.3.3.1

推奨事項, 7.1

時間要件, 2.1.3.3.3

拡張遠距離クラスタの構成

優先読取りディスク, 4.8.4

エクステント

セカンダリからの読取り, 4.8.4

外部認証されたSSLユーザー, 4.3.8 extusrupgradeスクリプト, 4.3.8

F

FAILED_LOGIN_ATTEMPTS初期化パラメータ

DEFAULTの制限, A.3.7

高速リカバリ領域, 3.10.6 ファイルのアクセス制御

SYSASMロール, 2.2.6.6

バックアップ・モードのファイル, 2.5.2.9

リストの取得, 2.5.2.9

ファイングレイン・アクセス・コントロール

ネットワーク・ユーティリティ・パッケージ, 2.5.2.1

fn:matches XQuery関数, 8.7.2 fn:replace XQuery関数, 8.7.2 Forms

Oracle Formsアプリケーションのアップグレード, 5.8

フル・トランスポータブル・エクスポート/インポート, 3.9

G

統計の収集, 2.5.2.5

バックアップ・モードのファイルのリストの取得, 2.5.2.9

H

Hardware Assisted Resilient Data(HARD)

システムのアップグレード, 4.11.6.1

HttpUriTypeタイプ, 2.5.2.1

I

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

IFILE (インクルード・ファイル)

エントリの編集, 2.7

「テキスト初期化パラメータ・ファイル(PFILE)」も参照,

インポート・ユーティリティ, 7.1

データのコピー, 7

非互換性

調査, 6.2

初期化パラメータ

調整, 2.7

Oracle Database 10gでの調整, 4.11.6

ASM_PREFERRED_READ_FAILURE_GROUPS, 4.8.4

COMPATIBLE, 1.7.1.1, 4.8.3

「サーバー・パラメータ・ファイル(SPFILE)」も参照,

インストール・ログ, 3.10.13 インストール

Oracle Databaseソフトウェア, 2.3

インストール所有者, 2.2.6 インスタンス

ダウングレード後に起動, 6.5

INTEGER演算

数値リテラルの評価, 5.7.1

中間アップグレード, 2.1.2 中間リリース

中間アップグレード, 2.1.2

相互運用性, 1.7.2 SYS以外またはSYSTEM以外の無効なオブジェクト, 2.5.2.6 無効なオブジェクト

utlrp.sqlスクリプト, 3.4, 3.5, 3.10.13, 6.5

無効なオブジェクト, 識別, 2.5.2.6 INVALIDステータス, 3.10.13 無効なSYSまたはSYSTEMオブジェクト, 2.5.2.6

K

KEEP IDENTITY句, 2.2.8

ナレッジ・ベース, 1.2

L

listener.oraファイル, 2.8

変更, 2.8

リスナー

Oracle Net Configuration Assistantを使用した変更, 2.8

負荷

アップグレード時の同時要求のレベル, 2.1.5.7

ロード・テスト, 2.1.5.7 localconfigコマンド, 2.2.6 ロジカル・スタンバイ・データベース

ローリング・アップグレード, 1.10.1

ログイン

DEFAULTの新しい制限, A.3.7

lsinventoryコマンド, 4.2 lsnrctlコマンド

Oracle Grid Infrastructureホーム, 2.8

M

maintainOrder属性(非推奨), 8.7.2

メンテナンス・リリースのアップグレード, 5.4.1.2

メンテナンス・タスク

AutoTaskを使用したスケジュール, A.2.5

データベースのメジャー・リリースのアップグレード, 5.4.1.1 手動アップグレード, 1.1.1

メリット, 2.1.3.2

データベースのバックアップ, 2.6

OCR構成, 4.11.5

mapUnboundedStringToLob属性(非推奨), 8.7.2 matches XQuery関数, 8.7.2 マテリアライズド・ビューのリフレッシュ

問合せステータス, 2.5.2.7

xdb名前空間のmaxOccurs属性(非推奨), 8.7.2 メディア・リカバリ, 2.5.2.8 データの移行, 1.1

異なるオペレーティング・システム, 2.2.10

lsnrctlコマンドを使用したOracleホームからのリスナーの移行, 2.8 Data Pumpのエクスポート/インポートによるデータの移動, 7.1 マルチテナント・コンテナ・データベース, 3.1, 3.5 複数バージョン, 1.6 My Oracle Support

ナレッジ・ベース, 1.2

Upgrade Companionへのリンク, 1.2, 2.1.5.4

N

ネットワーク・タイム・プロトコル(NTP), 2.2.6.4

ネットワーク・ユーティリティ・パッケージ

アクセス制御, A.2.13.2

ネットワーク

ネットワーク・ユーティリティ・パッケージへのACLアクセス権の付与, 2.5.2.1

新機能

アップグレード後の追加, 4.6.7

使用するためのスクリプトの変更, 5.7

新機能, 概要, 2.1.1 NO SCRIPTステータス, 3.10.13 アップグレードしたアプリケーションを再リンクしない, 5.6.1 NTP。「ネットワーク・タイム・プロトコル」を参照 NUMBER演算

数値リテラルの評価, 5.7.1

数値計算

数値リテラルの評価, 5.7.1

数値リテラル

評価, 5.7.1

O

OCIアプリケーション

変更, 5.6.3.2

新機能を使用するための変更, 5.6.3.2

動的リンク, 5.5.2.3

静的リンク, 5.5.2.2

アップグレードおよびリンク, 5.5.2.1

アップグレード, 5.3

アップグレードのオプション, 5.6

OFA, 1.8 olspreupgrade.sql, 1.1.2 個別パッチ, 1.10 OPatch lsinventoryコマンド, 4.2 オペレーティング・システム

データの移行, 2.2.10

オペレーティング・システムの要件, 2.2.9 オプティマイザ統計, 収集, 2.5.2.5 OPTION OFFステータス, 3.10.13 プリコンパイラおよびOracle Call Interface (OCI)アプリケーションのアップグレード用のオプション, 5.6 ORA_TZFILE

ダウングレード後の設定解除, 6.4

ora:matches Oracle XQuery関数(非推奨), 8.7.2 ora:replace Oracle XQuery関数(非推奨), 8.7.2 ORA-00336 ログ・ファイルのサイズがxxxxブロックのエラー, 3.10.1 ORA-00401 パラメータ互換性の値のエラー 3.10.1 Ora-00704 ブートストラップ障害のエラー, 3.10.1 ORA-00904 「TZ_VERSION」無効な識別子のエラー, 3.10.3 ORA-00942

表またはビューが存在しない, 3.10.3

ORA-00942 表またはビューが存在しないエラー, 3.10.3 ORA-01408エラー・メッセージ, 3.10.8 ORA-01562 ロールバック・セグメント番号の拡張に失敗したエラー, 3.10.6 ORA-01722 無効な数値のエラー, 3.10.3 ORA-01822 タイムゾーンのリージョンが見つからないエラー, 3.10.11 ORA-04031 共有メモリーのnnnバイトを割当てできないエラー, 3.10.6 ORA-19815 警告db_recovery_file_dest_sizeのエラー, 3.10.6 ORA-24247

アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されましたのエラー, 2.5.2.1

ORA-39700 データベースは、UPGRADEオプションを使用してオープンしてくださいのエラー, 3.10.1 ORA-39701 データベースをEXCLUSIVEでマウントする必要がありますのエラー, 3.10.1 Oracle Application Express

apexrelod.sqlファイル, 6.4

更新, 4.3.12

Oracle Application Express構成, 4.3.12 Oracle ASM

データベースのアップグレード後, 4.5

ディスク・グループの互換性, A.2.7

アップグレード後のオプション作業, 4.5

Oracle ASM Cluster Assistant, 2.2.6 Oracle ASMコンフィギュレーション・アシスタント(ASMCA), 2.2.6.5 Oracle Automatic Storage Management, 1.10

ディスク・グループの互換性, 4.8.3

ファイルのアクセス制御, 2.2.6.6

優先読取りの障害グループ, 4.8.4

ローリング・アップグレード, 1.10, 1.10.1

アップグレード, 2.2.6

Oracle Call Interface (OCI)

アプリケーションのアップグレード, 2.9.1

Oracleチェンジ・データ・キャプチャ。「Oracle GoldenGate」を参照, 8.1.7, 8.2.2, 8.2.2, A.1.6, A.1.6 Oracle Cluster Registry(OCR)

手動アップグレード, 4.11.5

Oracleクラスタ時刻同期化サービス, 2.2.6.4 Oracle Clusterware

アップグレード, 2.2.6

Oracle Data Guard

ローリング・アップグレード, 1.10.1

Oracle Data Pump, 1.1.1 Oracle Database Enterprise Edition

Standard Editionへの変換, 1.12

Oracle Database Express Edition, 1.13

アップグレード後の推奨作業, 4.9

Oracle Databaseへのアップグレード, 1.13

Oracle Database Standard Edition

Enterprise Editionへの変換, 1.11

Oracle Database Vault, 2.2.13.1, 2.3 Oracle Database XE, 1.13

Oracle Databaseへのアップグレード, 1.13

Oracleホーム

構成ファイルのコピー, 2.7

複数, 1.6.1

WindowsでのORACLE_HOMEデータベース・ディレクトリ, 2.7

LinuxまたはUNIXでのORACLE_HOME dbsデータベース・ディレクトリ, 2.7

Oracle Label Security, 2.3 Oracle Namesのサポート, 8.6.2 Oracle Net Configuration Assistant, 2.8 Real Application Clusters

ローリング・アップグレード, 1.10

アップグレード, 2.2.6

Oracleのリリース番号, 1.5 Oracle RMAN

データベースのバックアップ, 2.6

実行, 2.6

Oracleソフトウェア・インストール所有者, 2.2.6 Oracle Streams

ダウンストリーム取得, 2.2.11

Oracle Textが提供するナレッジ・ベース

アップグレード, 4.3.10

Oracle Universal Installer, 1.1.1, 2.3 Oracleユーザー・アカウント, 2.2.6 Oracle Warehouse Builder (OWB)

アップグレード, 3.4, 3.5

Oracle XML Database

バイナリのXML記憶域, A.2.12

ORACLE_BASE

DIAGNOSTIC_DEST, 1.1.3

オラクル社が提供するアカウント

パスワードの変更, 4.11.1

ORADIM

ダウングレード, 6.5

アップグレード, 3.4, 3.5

orapwSIDパスワード・ファイル, 2.7 オリジナルのエクスポート/インポート

データ・ポンプ・エクスポート/インポートとの対比, 7.1

OSDBAグループ, 2.2.6.6

P

パラレル・アップグレード・ユーティリティ

catctl.pl, はじめに

パラメータ・ファイル

バックアップ, 2.7

パスワード

大/小文字区別, 4.6.4

パッチ・セット更新, 2.4 パッチ

個別, 1.10

パッチ・セット・リリース

ダウングレード, 6.1

PDB, はじめに, 3.2.1 フィジカル・スタンバイ・データベース

ローリング・アップグレードの実行, 2.2.8

ローリング・アップグレード, 1.10.1

PL/SQLネイティブ・コンパイル, A.2.13.1 PL/SQLパッケージ

デフォルトでインストールされないもののアップグレード, 2.2.2

プラガブル・データベース, はじめに

統合監査の移行, 4.6.13.2

postupgrade_fixups.sql, 1.1.2 プリコンパイラ・アプリケーション

新機能を使用するための変更, 5.6.3.1

プリコンパイラ・アプリケーション

アップグレード, 2.9.1

プリコンパイラ

アプリケーション

変更, 5.6.3.1

アップグレードのオプション, 5.6

アプリケーションのアップグレード, 5.3 優先読取りの障害グループ

設定, 4.8.4

事前処理スクリプト

OLSおよびDV, 1.1.2

アップグレード前ディレクトリ, 2.5.1 アップグレード前情報ツール

非推奨となったパラメータとサポートが終了したパラメータの表示, 2.7

実行, 2.5.1

警告および対処法, 2.5.2

作業, 2.5.2

preupgrd.sql, 1.1.2 PRKH-1014エラー, 2.3 Pro*C/C++アプリケーション, 2.1.5.5 オプティマイザ統計の収集手順, 2.5.2.5 PURGE DBA_RECYCLE_BINシステム権限, 2.5.2.11 PURGE文, 2.5.2.11 データベースのごみ箱の消去, 2.5.2.11

Q

マテリアライズド・ビューのステータスの問合せ, 2.5.2.7

R

RDBMS DSTパッチ, 2.5.2.4

読取り専用およびオフラインの表領域, 2.2.7

無効なオブジェクトの再コンパイル, 3.4, 3.5, 6.5

リカバリ・カタログ

アップグレード, 4.3.5

リフレッシュ

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

registry$nonsys_inv_objs表, 2.5.2.6 registry$sys_inv_objs表, 2.5.2.6 リリース番号, 1.5 リリース

定義, 1.5

複数, 1.6

アップグレード・パス, 2.1.2

記憶領域の解放, 2.5.2.11 REMOVEDステータス, 3.10.13 REPCAT$_AUDIT_COLUMN_IDX1索引, 3.10.8 replace XQuery関数, 8.7.2 予約語

追加および適用, 5.2

ロール割当て済ソフトウェア所有者, 4.5 ロールバック・セグメント

自動UNDO管理への移行, 4.6.10

Active Data Guardを使用したローリング・アップグレード, 2.2.8 ローリング・アップグレード

方法, 1.10

Oracle Clusterware, 1.10.1

フィジカル・スタンバイ・データベース, 1.10.1

メソッドの概要, 1.10.1

クラスタ化されたASMインスタンス, 2.2.5

ロジカル・スタンバイ・データベース, 2.2.8

フィジカル・スタンバイ・データベース, 2.2.8

SQL Applyおよびロジカル・スタンバイ・データベース, 1.10.1, 2.2.8

root.shスクリプト, 2.2.6.5 rootupgrade.shスクリプト, 2.3 リンクの-rpathオプション, 5.5.2.3 複数リリースのOracleの実行, 1.6 ランタイム・ライブラリ検索パス, 5.5.2.3

S

スケジュール

AutoTask, A.2.5

スクリプト

ダウングレード, 6.5

手動アップグレード, 3.4, 3.5

再実行, 6.5

アップグレード前情報ツールの実行, 2.5.1

セキュリティ

大/小文字を区別するパスワード, 4.6.4

サーバー

互換性規則, 5.5.1

サーバー・パラメータ・ファイル(SPFILE), 2.7

移行, 4.11.3

HARD互換のストレージを使用するシステムのアップグレード, 4.11.6.1

SP2-1540「Oracle Databaseはエディション・セッションでは起動できません。」エラー, 3.10.7 アップグレード結果をログ・ファイルにスプール, 2.5.1 SQLアクセス・アドバイザ, A.2.17 SQL Apply

ローリング・アップグレードの実行, 2.2.8

ローリング・アップグレード, 1.10.1

SQL実行計画, 2.1.5.6.3 SQL管理ベース(SMB), 2.1.5.6.3

カーソル・キャッシュ, 2.1.5.6.3

SQLパフォーマンス・アナライザ, 2.1.5.6.2 SQL計画ベースライン, A.2.11

解凍, 2.1.5.6.3

SQL計画の管理, 2.1.5.6.3, A.2.11

SQL管理ベース, 2.1.5.6.3

SQL問合せ

テスト, 2.1.5.6.3

SQLワークロード, 2.1.5.6.2 SQL*Plus

スクリプト

アップグレード, 5.7

SQLCollSchema属性(非推奨), 8.7.2 sqlnet.oraファイル

圧縮, 2.8

SQLSchema属性(非推奨), 8.7.2 srclang属性(非推奨), 8.7.2 SSL外部ユーザー変換, 4.3.8 ステージング表

作成, 2.1.5.6.3

Standard Edition, 1.12

エクスポート・ユーティリティ, 1.12

初期データベース, 3.10.14, A.2.18

スタンバイ・データベース, 2.2.8 STARTUP UPGRADEコマンド, 6.5 静的にリンクされたOracleクライアント側ライブラリ・コード, 5.5.2.2 統計

オプティマイザの収集, 2.5.2.5

統計表

アップグレード, 4.3.7

状態

INVALID, 3.10.13

マテリアライズド・ビューのリフレッシュ, 2.5.2.7

NO SCRIPT, 3.10.13

OPTION OFF, 3.10.13

REMOVED, 3.10.13

UPGRADED, 3.10.13

storeVarrayAsTable属性(非推奨), 8.7.2 サポート・ノート472937.1, Information On Installed Database Components, 2.5.2 サポート・ノート730365.1, Oracle Database Upgrade Path Reference List, 2.4 サポート・ノート753041.1, How to Diagnose Components with NON VALID Status, 2.5.2 サポート・ノート854428.1, Patch Set Updates for Oracle Products, 2.4 サポート・ノートID 412160.1, for RDBMS DST patches, 2.5.2.4 直接のアップグレードがサポートされているリリース, 1.3 シンボリック・リンク

Oracle Universal Installer, 5.5.2.3

スタンバイ・データベースの同期化, 2.5.2.12 構文チェック

アプリケーション・コード, 5.6.2

SYSASMロール, A.2.6

Oracle ASMファイル・アクセス制御, 2.2.6.6

SYS.LINK$表, 2.5.2.3 システムの考慮点および要件, 2.2

T

表領域

読取り専用およびオフライン, 2.2.7

テスト

アップグレードに対するアプリケーション, 2.10, 4.6.14

計画の作成, 2.1.5

アップグレードの機能, 2.1.5.3

アップグレードの高可用性, 2.1.5.4

アップグレードの統合, 2.1.5.5

アップグレードの最小機能, 2.1.5.2

アップグレードのパフォーマンス, 2.1.5.6

アップグレード済のテスト・データベース, 2.10

データベース・リプレイの使用, 2.1.5.6.1

アップグレードのボリューム/ロード・ストレス, 2.1.5.7

アップグレード処理のテスト, 2.9 テキスト初期化パラメータ・ファイル(PFILE), 2.7 Oracle RACでの時間の同期, 2.2.6.4 タイムゾーン・ファイル

不一致の解決方法, 2.5.2.4

ダウングレード後の設定解除, 6.4

バージョンの不一致, 3.10.11

TIMESTAMP WITH TIME ZONEデータ型, 2.5.2.4 TIMESTAMP WITH TIME ZONEデータ型, 2.5.2.4 トレーニング, 入手先, 2.1.1 トランザクション

分散

未処理の解決, 2.5.2.10

translate属性(非推奨), 8.7.2 トランスポータブル・エクスポート/インポート, 3.9 トラブルシューティング

EDITIONセッションのエラー, 3.10.7

フラッシュ・リカバリ領域, 3.10.6

ORA-00942 表またはビューが存在しません, 3.10.3

ORA-01408索引エラー, 3.10.8

ロールバック・セグメント/UNDO表領域, 3.10.6

リソースの不足, 3.10.6

共有メモリー, 3.10.6

アップグレード・モードでのデータベースの起動, 3.10.1

SYSTEM表領域およびSYSAUX表領域, 3.10.6

アップグレード中断

ORA_00904による, 3.10.3

ORA_01722による, 3.10.3

アップグレード, 3.10 アップグレードのトラブルシューティング

ORA_00942による終了, 3.10.3

ソフトウェアのアップグレード・タイプ, 5.4

U

UNDO_MANAGEMENT初期化パラメータ, 4.6.10

デフォルト, A.2.20

統合監査

スキーマおよびロールの削除, 2.2.15

「監査」を参照

Upgrade Companion

My Oracle Supportへのリンク, 1.2, 2.1.5.4

アップグレード方法

選択, 2.1.3

データ・ポンプ・エクスポート/インポート, 2.1.3.3

Database Upgrade Assistant, 1.1.1

Database Upgrade Assistant(DBUA), 2.1.3.1

手動, 2.1.3.2

サイレント・モード, 3.2.6

アップグレード・パス

決定, 2.1.2

表, 2.1.2

アップグレード手順

主な手順の概要, 1.4

ワークフロー, 1.4

アップグレード処理のテスト, 2.9 UPGRADEDステータス, 3.10.13 テスト・データベースのアップグレード, 2.10 アップグレード

アプリケーション, 5

互換性規則, 5.5

オプション, 5.6

再リンク, 5.5

バックアップ計画, 2.1.6 バイナリのXML記憶域, A.2.12 初期化パラメータ, 2.7 新しい管理手順, 4.6.8 Oracle Application Express, 4.3.12 Oracle Automatic Storage Management, 2.2.6 Oracle Clusterware, 2.2.6 Oracle Formsアプリケーション, 5.8 Oracle Real Application Clusters, 2.2.6 ORADIM, 3.4, 3.5 アップグレード後の処理, 4 準備, 2.1 リカバリ・カタログ, 4.3.5 ローリング・アップグレード, 1.10 スクリプトおよび手動アップグレード, 3.4, 3.5 SQL*Plusスクリプト, 5.7 統計表, 4.3.7 テスト, 2.1.5 トラブルシューティング, 3.10 Database Upgrade Assistantの使用, 3.2 情報の入手先, 1.2 クラスタ・データベースのアップグレード

CLUSTER_DATABASE初期化パラメータの設定, 2.7

アップグレードおよびCDBへの接続, 3.1.2 UTL_INADDRパッケージ, 2.5.2.1 UTL_MAILパッケージ, 2.5.2.1 UTL_SMTPパッケージ, 2.5.2.1 UTL_TCPパッケージ, 2.5.2.1 utlrp.sql, 1.1.2 utlrp.sqlスクリプト

無効なオブジェクトの再コンパイル, 3.4, 3.5, 6.5

utlu121s.sql, 1.1.2 utluiobj.sql, 1.1.2 utluiobj.sqlスクリプト, 2.5.2.6

V

V$OPTIONビュー, 3.10.13

ボリューム

アップグレードするデータ量, 2.1.5.7

W

ワード・サイズ

64ビット・ソフトウェア, 1.9

ワークロード

取得およびリプレイ, 2.1.5.6.1

X

xdb:defaultTableSchema属性(非推奨), 8.7.2

xdb:maintainOrder属性(非推奨), 8.7.2

xdb:mapUnboundedStringToLob属性(非推奨), 8.7.2

xdb:maxOccurs属性(非推奨), 8.7.2

xdb:SQLCollSchema属性(非推奨), 8.7.2

xdb:SQLSchema属性(非推奨), 8.7.2

xdb:srclang属性(非推奨), 8.7.2

xdb:storeVarrayAsTable属性(非推奨), 8.7.2

xdb:translate属性(非推奨), 8.7.2

XE, 1.13

XQuery言語

関数

fn:matches, 8.7.2

fn:replace, 8.7.2

ora:,matches (非推奨, Oracle), 8.7.2

ora:replace (非推奨, Oracle), 8.7.2

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

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 Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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)を参照してください。