Oracle Database 12c Release 2 (12.2.0.1.0) で、データベース・キャラクタ・セットの変更は不完全にしかできないので、DBインストール時の設定で決めてしまうのが大事らしい

久々にひどい風邪を患い、体力が限りなく落ち込んでいるわけですが、皆々様も風邪にはお気をつけください。(完全にうつされたっぽいですが...)

今回は、記念すべき300回目の記事ですよ~。

いつも拝見してくれている皆々様、ありがとうございます。

なんとかPV数も、2018年6月17日(日)21:15時点で、トータルで111000人を超えましたよ~。少なっ!(涙)みんな、もっと、オラにPV数を...

 

ということで、

かなりご無沙汰になってしまいましたが、Java側からOracle DatabaseにデータをINSERTした際に壮絶な文字化けが起こってしまっていました。

ts0818.hatenablog.com

⇧  文字化けの現象については、こちらの記事を参照していただければと。 

 

ちなみに、

データベースを作成した後でキャラクタ・セットを変更すると、一般的に、時間およびリソースの面で大きなコストがかかります。このような処理を行うには、データベース全体をエクスポートした後で再びインポートすることにより、すべての文字データの変換が必要な場合もあります。そのため、データベース・キャラクタ・セットは、インストールの時点で慎重に選択することが重要です。

インストール中のキャラクタ・セット選択について - Oracle® Databaseグローバリゼーション・サポート・ガイド リリース2 (12.2)

っていう重要なことは、インストール時のガイドとかで言ってくれてるようなんですが、ハッキリ言って目立ってない...もうちょっと気づきやすくして欲しい...。 

インストール時に参照した情報が正確でなかったということですかね(涙)。

 

MySQLとかだと結構、手軽にキャラクタ・セットの変更とかできた気がしたんですが、その感覚でいると危ないってことですかね。 

  

というわけで、今回は、文字化けに影響していたらしい、データベース・キャラクタ・セットの変更にトライ。

 

結論としては、データベース・キャラクタ・セットは変更はできないようです。

 

既存のデータベースのデータをエクスポートし、エクスポートしたデータを、自分の希望するデータベース・キャラクタ・セットで新しくデータベースを作成した、そのデータベースにインポートすることで、エクスポートしたデータの内容がインポート先のデータベースのデータベース・キャラクタ・セットに自動的に変換される(ただし、データなどが破損する場合がある)という素晴らしい仕様になっているようです。

Oracle Database、まったく駄目じゃん...

 

ちなみに、データベース作成後の変更ができないものとして、

データベース作成後に変更できないパラメータを変更するには、別のデータベースを新たに作成し、Data Pumpなどでデータを移行する必要があります。そのため、この種のパラメータはデータベース作成前によく検討しておく必要があります。変更できないパラメータには以下のものがあります。

  • 標準ブロック・サイズ
  • データベース・キャラクタセット

第2回: データベースを作成(CREATE DATABASE)するときに考慮しておくこと

「標準ブロック・サイズ」というものもあるようです。 

 

 

シングルバイト・キャラクタ・セットとマルチバイト・キャラクタ・セットと

いきなり、脱線ですが、

コンピューターの世界では、すべての情報は、「0」か「1」で表現していると言われています。(量子コンピューターとかの概念が入ってくると変わってくるようですが。)

1 bit = 0 か 1 (21で表現される、2進数の2桁目ってことですかね)

1 byte = 1 bit × 8

という関係になるわけです。

ferret-plus.com

⇧  上記サイト様が詳しいです。

で、バイト(byte)は、ビット(bit)を8個まとめたということですが、

みんな大好き「文字」をコンピューター上で表現する単位として、バイト(byte)を使っていると。

detail.chiebukuro.yahoo.co.jp

⇧  上記サイト様が詳しいですが、

プログラミングで「文字」を表現する場合、「文字コード」を利用していく感じになると思いますが、

文字コード(もじコード)とはコンピュータ上で文字キャラクタ (コンピュータ))を利用する目的で各文字に割り当てられるバイト表現。もしくは、バイト表現と文字の対応関係(文字コード体系)のことを指して「文字コード」と呼ぶことも多い。

文字コード - Wikipedia

となっており、

で、さらに「コードセット」とかいう概念も出てきてかなりややこしい(涙)。

「文字セット(文字集合)」としては、

  • シングルバイト文字セット(シングルバイト・キャラクタ・セット)
  • マルチバイト文字セット(マルチバイト・キャラクタ・セット)

などの分類があるようです。(他にもいろいろあるようです。)

「符号化方式」としては、

ISO-2022-JP (RFC1468符号化表現)、EUC-JPShift_JISUTF-8UTF-16UTF-32  などなど、一部抜粋でもこの量。

文字符号化方式 - Wikipedia

符号化文字集合 符号化形式
(CEF)
符号化スキーム
(CES)
Unicode文字集合 UTF-8 UTF-8
UTF-16 UTF-16BE
UTF-16LE
UTF-16
UTF-32 UTF-32BE
UTF-32LE
UTF-32

 

で、さらに、ややこしくしてるのが、

文字コードといえば符号化方式をさすこともあれば、文字集合と結合させた概念(キャラクタセット符号化表現あるいは文字マップ)として語られることもある。これには、ISO/IEC 8859 や Big5 のように、文字集合と符号化方式が事実上一体化している体系が少なからず存在することが影響している。

文字コード - Wikipedia

で、

「符号化文字集合」や「文字符号化方式」といった用語は標準化団体によっても定義が異なるため、「これは符号化文字集合だ、いや文字符号化方式だ」といった議論は意味をなさないことがある。

文字コード - Wikipedia

で、

元来、文字コードは文字の集合の各文字に一意なバイト表現を割り当てただけのシンプルなものだった。バイト値を計算によって変形した符号化表現が用いられるようになってきたため(例えば Shift_JIS や UTF-8)、「符号化文字集合」と「文字符号化方式」とを区別するようになったと考えられる。

文字コード - Wikipedia

で、

両者の区分は Unicode や IETF では用いられる。一方、ISO/IEC や JIS では「文字符号化方式」を「符号化文字集合の構造」あるいは「文字符号の構造及び拡張法」として規定している。

文字コード - Wikipedia

というように、みんな好き放題に策定した結果、「文字コード」の意味合いが一定しないため、「文字コード」を扱うときの認識が合わず、文字化けなどの問題が起こるようになりました、めでたし、めでたし(酷)

バベルの塔 みたいな現象ですかね(哀)。 

 

シングルバイト・キャラクタ・セットとマルチバイト・キャラクタ・セットと長さセマンティックと

だいぶ、脱線したんですが、Oracle Database のテーブルのカラム(列)のデータ型で、CHAR型やVARCHAR2型などの文字を扱うものに関して、「長さセマンティック」というものが影響してくるようです。

「長さセマンティック」自体が何なのかの説明が、Oracleのサイトで発見できなかったのですが、VARCHAR2型の場合の説明だと、

VARCHAR2データ型は、データベース・キャラクタ・セットの可変長の文字列を指定します。データベースの作成時には、データベース・キャラクタ・セットを指定します。

VARCHAR2の列を含む表の作成時には、sizeとして列長を指定し、その後にオプションで長さの修飾子を指定する必要があります。修飾子BYTEはバイト長セマンティクスを表し、修飾子CHARは文字長セマンティクスを表します。バイト長セマンティクスでは、sizeは列に格納できる最大バイト数です。文字長セマンティクスでは、sizeは列に格納できるデータベース・キャラクタ・セットの最大コード・ポイント数です。

データ型 - Oracle® Database SQL言語リファレンス リリース2 (12.2)

で、

修飾子を指定しない場合は、列を作成しているセッションのNLS_LENGTH_SEMANTICSパラメータの値によって長さセマンティクスが定義されますが、デフォルト・セマンティクスがBYTEであるスキーマSYSに表が属している場合を除きます。

データ型 - Oracle® Database SQL言語リファレンス リリース2 (12.2)

とあるように、必須のオプションである「長さセマンティック」には、

  • バイト長セマンティック
  • 文字列長セマンティック

の2種類があるらしく、 

シングルバイト・キャラクタ・セットの場合、文字列のバイト数と文字数は同じです。

マルチバイト・キャラクタ・セットの場合は、1文字または1つのコード・ポイントが1つ以上のバイトで構成されています。可変幅キャラクタ・セットの場合は、バイト長に基づく文字数の計算が困難な場合があります。列の長さをバイト数単位で計算することをバイト・セマンティクス、文字数単位で計算することをキャラクタ・セマンティクスと呼びます。

データ型 - Oracle® Database SQL言語リファレンス リリース2 (12.2)

というように、「シングルバイト・キャラクタ・セット」と「マルチバイト・キャラクタ・セット」で、『文字列のバイト数と文字数』の関係が変わってくるようです。

 

データベース・キャラクタ・セットの変更 == キャラクタ・セットの移行、結局DBの作り直しってこと?

紛らわしいのですが、 

既存のデータベース用のデータベース・キャラクタ・セットを変更することを、キャラクタ・セットの移行と呼びます。この場合でも、汎用性と互換性を維持するためにUnicodeに移行することをお薦めします。

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド リリース2 (12.2)

ということみたいです。

要するに、変更はできないってことを認めたくないので、「キャラクタ・セットの移行」と置き換えてる感が半端ない、かなり苦しい説明ですね...Oracle Databaseってかなり破綻してる気が。

新機能を追加する前に、まずは、「データベース・キャラクタ・セットを変更する」を手軽に実行できるようにして欲しいですね。

データベース・キャラクタ・セットの移行は、通常、データ・スキャニング、データ・クレンジング、およびデータ変換の3段階からなる複雑なプロセスになります。

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド リリース2 (12.2)

複雑なプロセスって...嫌になりますね。

 で、変更方法には、

の3種類があるらしいんですが、残念ながら、「Database Migration Assistant for Unicodeを使用した文字データの移行」に関しては、

このリリースのDatabase Migration Assistant for Unicodeには、変換できるデータベースについて、いくつかの制約があります。特に、データ・ディクショナリ内に特定のタイプの変換可能データがあるデータベースを変換しません。エクスポート/インポート移行方式を使用すれば、このような制限事項を解消できます。

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース2 (12.2)

ということみたいです。 

ちなみに、1つ前のバージョンだと、

このリリースのDatabase Migration Assistant for Unicodeには、変換できるデータベースについて、いくつかの制約があります。特に、Oracle Database 12cのプラガブル・データベース(PDB)の移行をサポートしません。

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース1 (12.1)

⇧  マルチコンテナ機能に対応してなかったみたいですね...Oracle Database 12c、まだまだ発展途上という感じですかね....。

 

Oracle Database 12c Release 2 (12.2.0.1.0)  からの変更点として、

PDBでの異なるキャラクタ・セットの使用

CDBルートのキャラクタ・セットがAL32UTF8である場合、CDB内の任意のコンテナは、CDBルートおよびCDB内の他のコンテナとは異なるキャラクタ・セットを使用できます。

このリリースでの『Oracle Database管理者ガイド』の変更点 - Oracle® Database管理者ガイド 12c リリース2 (12.2)

⇧  データベース・キャラクタ・セットをAL32UTF8にしておかないと、PDBなどで他のキャラクタ・セット使えないってなってますね。

 

全体エクスポートと全体インポートは、データベースを新しいキャラクタ・セットに変換する際にも使用できます。別々のターゲット・インスタンスを設定する必要があるため、時間も長くかかり、リソースも大量に必要になる場合があります。

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース2 (12.2)

⇧  「データベースを新しいキャラクタ・セットに変換する際にも」...にも、って、データベース・キャラクタ・セットの変更については、何も考慮されてなかった感が半端ないですね。

 

いろいろ脱線してしまいましたが、データベース・キャラクタ・セットの変更に関しては、「全体エクスポートおよび全体インポートを使用した文字データの移行」 の一択になりそうです。

で、よく分からんのだけども、いまのDBからデータベース・キャラクタ・セットだけ変えた情報をエクスポートして、その情報をいまのDBにインポートってことができるのであれば、まぁ良いのだけど、そんなことができるんですかね?(⇐ 無理っぽいようですね。)

qiita.com

⇧  上記サイト様によりますと、どうやら、インポート時に、インポート先のデータベース・キャラクタ・セットに自動変換されるらしいですね。

つまり、自分の利用したいデータベース・キャラクタ・セットのデータベースを新規に作成して用意しておく必要があるみたいですね。

 

全体エクスポートおよび全体インポートを使用した文字データの移行とは

エクスポート・ユーティリティとインポート・ユーティリティの詳細は、Oracle Databaseユーティリティ』 を参照してください

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース2 (12.2)

⇧  たらい回し感が半端ないですが、

 『Oracle Databaseユーティリティ』のページに行くと、

Oracle Data Pumpテクノロジを使用すると、データおよびメタデータをデータベース間で非常に高速に移動できます。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

となっていて、全体エクスポート、全体インポートってのは、 『Oracle Data Pumpテクノロ』ってものを利用していく感じですかね?

Oracle Data Pump』の説明は、

Oracle Data Pumpは、次の3つの要素で構成されています。

データ・ポンプ・クライアントであるexpdpおよびimpdpは、それぞれデータ・ポンプ・エクスポート・ユーティリティおよびデータ・ポンプ・インポート・ユーティリティを起動します。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

ってなってますね。 

expdb』『impdb』 のコマンド(データ・ポンプ・クライアントである)を使っていく感じですかね。

と思ったら、

expdpクライアントおよびimpdpクライアントでは、コマンドラインで入力されたパラメータを使用してエクスポートおよびインポートを実行するために、PL/SQLパッケージDBMS_DATAPUMPで提供されているプロシージャを使用します。これらのパラメータは、完全なデータベースまたはデータベースのサブセットに対するデータおよびメタデータをエクスポートおよびインポート可能にします。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

PL/SQLパッケージDBMS_DATAPUMP(データ・ポンプAPIとも呼ばれます)』 も必要になってくるみたいですね...。

Oracle Databaseユーティリティの今回のリリースでの変更点 12c リリース2 (12.2)

によると、「Oracle Data Pump」に関する変更点がかなりの量あるっぽいです。

で、

Oracle Data Pumpを使用している場合に、キャラクタ・セットをシングルバイトからマルチバイトへの移行するときは、データ・ポンプのPL/SQLパッケージを再ロードする必要があります。

キャラクタ・セットの移行 - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース2 (12.2)

⇧  となっています...要点をまとめて欲しい、そして、「データ・ポンプのPL/SQLパッケージを再ロードする必要があります。」って具体的に何をしろと?

さすがOracleさん、安定の不親切さ。

 

ちなみに、自分の環境では、Oracle Databaseのデータベース・キャラクタ・セットが、「US7ASCII (AMERICAN_AMERICA.US7ASCII)」ってなってしまっていて、

たとえば、Oracle InstallerでNLS_LANGが移入されない場合、その値はデフォルトでAMERICAN_AMERICA.US7ASCIIとなります。

NLS_LANG のデフォルト値は AMERICAN_AMERICA.US7ASCII - ablog

d.hatena.ne.jp

⇧ 上記サイト様によりますと、Oracle Database インストール時の設定が曖昧だったのがマズかったようです。

また、JDBC接続を利用してデータベースに接続する場合、JVMJava VM)のロケールの設定も文字データに絡んでくるようです。

Oracle JDBCを使用してOracle Databasesに接続するJavaアプリケーションは、NLS_LANGを使用しません。かわりに、アプリケーションが実行されるJava VMのデフォルト・ロケールが、Oracle JDBCによってOracle Databaseの言語とテリトリ設定にマップされます。Oracle JDBCは、これらの設定を使用して、接続されたデータベース・セッションを構成します。Javaは内部的にUnicodeで動作するため、クライアント・キャラクタ・セットは常にUnicodeに設定されます。アプリケーションで明示的に変更した場合を除き、Java VMのデフォルト・ロケールは、Java VMが実行されるユーザーのオペレーティング・システムに基づいて設定されます。Java VMのデフォルト・ロケールの設定の詳細は、Java VMのドキュメントを確認してください。

クライアント接続の言語およびロケール・プリファレンスの設定 - Oracle® Databaseインストレーション・ガイド 12c リリース2 (12.2)

⇧  このへんも後で、EclipseJVMの設定を見直してみなければですね。

 

で、「US7ASCII (AMERICAN_AMERICA.US7ASCII)」は、 「シングルバイト・キャラクタ・セット」と「マルチバイト・キャラクタ・セット」のどっちなのよ?

SB(シングルバイト)でした。

表A-6 その他のASCIIベース・データベース・キャラクタ・セット

キャラクタ・セット - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース2 (12.2)

f:id:ts0818:20180513170737p:plain

で、「AL32UTF8」 は、MB(マルチバイト)ですやん。

f:id:ts0818:20180513171623p:plain

Oracle Data Pumpを使用している場合に、キャラクタ・セットをシングルバイトからマルチバイトへの移行するときは、データ・ポンプのPL/SQLパッケージを再ロードする必要があります。」 に当てはまるんじゃないの、これ~。

だ~か~ら、Oracleさん、「データ・ポンプのPL/SQLパッケージを再ロードする」って具体的にどうすれば良いの?

 

データ・ポンプでデータ移動しないといけないらしい?権限は?

データ・ポンプを使用してデータベースの中からまたはデータベースの中へデータを移動する方法、およびそれぞれの方法を使用する場合の詳細は、次の項目を参照してください。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

と、どれを使ったら?ってなりますね...というか文字コード変えたいだけなのに、むちゃくちゃ面倒くさいんですけど...。

 

その前に、データ・ポンプを実行できる権限ですが、

データ・ポンプの多くのエクスポートおよびインポート操作では、DATAPUMP_EXP_FULL_DATABASEロールまたはDATAPUMP_IMP_FULL_DATABASEロール(あるいはその両方)をユーザーが持っている必要があります。   これらのロールは、データベース作成の一環として標準スクリプトを実行すると、自動的にOracle Database用に定義されます。(これらのロールの名前にはFULLという語が含まれますが、これらのロールは、実際には全体モードのみではなく、任意のエクスポートまたはインポート・モードのすべての特権操作に適用されることに注意してください。)

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

となっていて、

DATAPUMP_EXP_FULL_DATABASEロールはエクスポート操作にのみ影響しますDATAPUMP_IMP_FULL_DATABASEロール は、インポート操作と、SQLFILEインポート・パラメータを使用する操作に影響します。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

で、

SYSスキーマには、これらのいずれのロールも割り当てられていません。ただし、データ・ポンプが実行するセキュリティ・チェックの中でこれらのロールを必要とするものについては、SYSスキーマにアクセス権が付与されます。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

と。結局、SYSユーザーで実行できるのかどうかが分からんのだけども...。

データ・ポンプ実行時に、必要なロールのアクセス権がSYSユーザーに付与されるってなってるんで、きっと大丈夫でしょう、いや~、分かりにくいな~。

 

DBMS_DATAPUMPパッケージとDATA_PUMP_DIR

んで、「DBMS_DATAPUMPパッケージ」 っていうのは、

DBMS_DATAPUMPパッケージは、データおよびメタデータの両方を含むデータベースの一部または全体をデータベース間で移動するために使用します。

DBMS_DATAPUMP - Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース2 (12.2)

docs.oracle.com

となっていますね。こいつを使ってとデータベースのデータを移動することをOracleさんは推奨していると。 

 

で、DBMS_DATAPUMPパッケージを使ってインポートする場合、

前提として、インポートするダンプファイルdumpfile.dmpディレクトリオブジェクトDATA_PUMP_DIRにあることが必要です。

[AWS] RDS for Oracle へ Data Pump インポートするときの DBMS_DATAPUMP パッケージオプション | Developers.IO

dev.classmethod.jp

⇧  上記サイト様によりますと、『DATA_PUMP_DIR』というディレクトリを作って、そのディレクトリにダンプファイル(データベースからエクスポートしたファイルなど)を配置しておく必要があるようです。

 

UNIXおよびWindowsオペレーティング・システムの場合、デフォルトのディレクトリ・オブジェクトDATA_PUMP_DIRは、データベースが作成されるとき、またはデータベース・ディレクトリがアップグレードされるたびに作成されます。デフォルトでは、特権ユーザーのみが使用できます。(ユーザーSYSTEMは、デフォルトでDATA_PUMP_DIRディレクトリへの読取りおよび書込みアクセス権を持っています。)DATA_PUMP_DIRディレクトリの定義は、アップグレード時またはパッチの適用時にOracleによって変更されることがあります。

Oracle Data Pumpの概要 - Oracle® Databaseユーティリティ 12c リリース2 (12.2)

と。

んじゃ、『DATA_PUMP_DIR』というディレクトリがあるか確認するには?

oracclle.seesaa.net

⇧  上記サイト様によりますと、sqlplusで『dba_directories』っていうテーブルの情報から調べられるらしい。

ということで、仮想マシンを起動し、sshログインし、

f:id:ts0818:20180506182506p:plain

Oracle Databaseにログインし、

f:id:ts0818:20180506182701p:plain

ORACLEインスタンスの起動とDBのマウント。

f:id:ts0818:20180506182852p:plain

 

DATA_PUMP_DIR』というディレクトリがあるか確認。

SELECT directory_name, directory_path FROM dba_directories WHERE directory_name='DATA_PUMP_DIR';

f:id:ts0818:20180506183021p:plain

⇧  デフォルトだと、『$ORACLE_HOME/rdbms/log/』 にあるらしいですが。

う~ん、分からん...。

f:id:ts0818:20180506183553p:plain

『$ORACLE_HOME/rdbms/log/』 にはディレクトリが、

『68025FF4B53529E8E0530F02000A3D94』
『69CC60E7DE4307CFE055000000000001』

の2つしかいないんだが...。

f:id:ts0818:20180506183824p:plain

 db.logファイルがあるほうが、『DATA_PUMP_DIR』ということで良いのかしら?

f:id:ts0818:20180506191622p:plain

 

sakochin3.blog.so-net.ne.jp

 

datapumpを使用するための準備手順 | Oracle使いのネタ帳

 ⇧  上記サイト様によりますと、新しく『DATA_PUMP_DIR』を作らないとマズそうですかね。

 

qiita.com

⇧  上記サイト様によりますと、『ディレクトリ・オブジェクト』は『DATA_PUMP_DIR』でなくても、適当なディレクトリを作成して、そのディレクトリを『backup_dir』という『ディレクトリ・オブジェクト』とするような感じで、『ディレクトリ・オブジェクト』は自由に作れるみたいです。

つまり、適当なディレクトリを作っておいて、そのディレクトリを『ディレクトリ・オブジェクト』としてしまえばOKっぽいですね。 

 

実際にエクスポート、インポートしてみるための手順を整理

実際に、どういった手順を踏めば良いのか?

d.hatena.ne.jp

⇧  上記サイト様が詳しく説明てくれています。

それでは、データベース・キャラクタ・セットを変更するための手順を一旦、整理してみます。

  • エクスポート(移行元)
    1. 適当なディレクトリを作成。
    2. 作成したディレクトリに『ディレクトリ・オブジェクト』を割当て。
    3. エクスポートするスキーマのユーザに、『ディレクトリ・オブジェクト』への読み取りと書き込みの権限を付与。
    4. Oracleデータ・ディクショナリのUSER_SEGMENTSビューで表領域のサイズを確認。(空き容量が十分でないと、エクスポートが失敗するため)
    5. 「expdp」コマンドを実行して『ディレクトリ・オブジェクト』にダンプファイルを配置。
  • インポート(移行先)
    1. 適当なディレクトリを作成。
    2. 作成したディレクトリに『ディレクトリ・オブジェクト』を割当て。
    3. インポートするスキーマのユーザに、『ディレクトリ・オブジェクト』への読み取りと書き込みの権限を付与。
    4. インポートに必要な権限の付与。
    5. 7.で作成したディレクトリにエクスポートファイルを配置。
    6. 「impdp」コマンドを実行。

 というような感じでしょうか?

ですが、これは、データベースが2つある想定の話ですね。 

といった機能を使っている場合や、別サーバーにデータベースが用意されている場合は上記の方法でいけますが、今回は、1つしかデータベース用意してないので、どうしましょう?

データベース・キャラクタ・セット・メタデータの修復

Database Migration Assistant for Unicodeリリース1.2では、CSREPAIRスクリプトを使用してデータベース・キャラクタ・セット・メタデータを修復できます。CSREPAIRスクリプトはDMUクライアントと連携して動作し、DMUリポジトリにアクセスします。DMUで想定データベース・キャラクタ・セット・プロパティをターゲット・キャラクタ・セットに設定して全体データベース・スキャンを実行し、無効な表現の問題が報告されなくなると、データベース内のすべての既存データが想定データベース・キャラクタ・セットに従って定義されていることが確認されるため、その後でこれを使用してデータベース・キャラクタ・セット宣言をデータの実際のキャラクタ・セットに変更してください。CSREPAIRにより変更されるのはデータ・ディクショナリ・メタデータ内のデータベース・キャラクタ・セット宣言のみであり、データベース・データは変換されないことに注意してください。

データベース・キャラクタ・セット・メタデータの修復 - Oracle® Databaseグローバリゼーション・サポート・ガイド 12c リリース2 (12.2)

と、まさかのDMU(Database Migration Assistant for Unicode)のCSREPAIRで、データベース・キャラクタ・セットの変更ができるらしい、ただし、既に登録されてるデータとかの文字コードの面倒は見ないよ、ってことみたいです。

 

だが、しかし、いまのところGUI環境でしか利用することができないようです....というわけで、「データベース・キャラクタ・セット・メタデータの修復」は断念。

ということで、

  • エクスポート
  • 旧データベース削除
  • 新データベース作成(新しいデータベース・キャラクタ・セットで)
    • Oracle Database Configuration Assistant (DBCA)を使用する場合
      • GUIで(レスポンスファイルの使用しない場合)
      • CUIで(レスポンスファイルの使用する場合)
    • CREATE DATABASE文を使用する場合
      • Oracle Managed Filesを使用しない場合(TABLESPACE句にDATAFILE句またはTEMPFILE句を指定する必要あり)
      • Oracle Managed Filesを使用する場合(初期化パラメータDB_CREATE_FILE_DESTを設定)
    ※ CREATE DATABASE文を失敗後に再発行するには、最初にインスタンスを停止してから、前のCREATE DATABASE文で作成されたファイルを削除する必要があります。
  • インポート

とするしかなさそうです。

データベース作成の選択肢が多すぎてどれを使うのが良いのかサッパリ分からんですが、今回は、CREATE DATABASE文で、かつ、Oracle Managed Filesを使わない方法で試してみようかと。

 

 

実際にデータベース・キャラクタ・セットを変えてみる

まずは、エクスポートの手順を実施していきますか。

とりあえず、仮想マシンを起動し、仮想マシンにログインですかね。仮想マシンの一覧を表示して、どの仮想マシンを起動するか選択して、仮想マシンを起動(コンソールウィンドウを表示させないモードで)。

f:id:ts0818:20180603145655p:plain

下記コマンドで、仮想マシンのIPを確認できるようです。

unix.stackexchange.com

VBoxManage guestproperty get [仮想マシン名] "/VirtualBox/GuestInfo/Net/0/V4/IP"
VBoxManage guestproperty get [仮想マシン名] "/VirtualBox/GuestInfo/Net/1/V4/IP"

f:id:ts0818:20180603152455p:plain

VirtualBoxの「ネットワーク」と、IP確認のディレクトリの対応は、

VirtualBoxの「ネットワーク」 IP確認のディレクト
アダプター1 /VirtualBox/GuestInfo/Net/0/V4/IP
アダプター2 /VirtualBox/GuestInfo/Net/1/V4/IP

みたいな感じですかね? 

f:id:ts0818:20180603153809p:plain

 

というわけで、ホストオンリーアダプターのほうに、oracleユーザーでsshログイン。 

ssh oracle@192.168.33.10

f:id:ts0818:20180603153209p:plain

エクスポートしたダンプファイルを配置する用のディレクトリを、「/home/oracle」に作ってしまいます。

f:id:ts0818:20180603155208p:plain

ディレクトリオブジェクト」を作成するために、DBにログインします。一応、SYSユーザー(sysdba権限として)でログイン。ORACLEインスタンスとDBのマウントも行ってます。

f:id:ts0818:20180603160356p:plain

「expdp_dir」というディレクトリオブジェクトを作成し、先ほど作成した「/home/oracle/expdir」に紐づけます。 

CREATE DIRECTORY expdp_dir as '/home/oracle/expdir'

f:id:ts0818:20180603161348p:plain

エクスポートします。

expdp [ユーザー名]/[パスワード] directory=[ディレクトリオブジェクト名] dumpfile=[ダンプファイル名];

f:id:ts0818:20180603162039p:plain

 はい、怒られた~。

どうやら、DBからログアウトした状態で実行しないといけないらしい。一応、ディレクトリも、「ディレクトリオブジェクト」に指定した場所に移動しておいたほうが良さそうですね。

もうひとつ、コマンドプロンプトを起ち上げて、仮想マシンoracleユーザーでsshログインし、「/home/oracle/[ディレクトリオブジェクトとした場所]」に移動。

f:id:ts0818:20180603162707p:plain

今度こそ、エクスポート。

f:id:ts0818:20180603163009p:plain

 はい、エラー。そもそも、adminなんてユーザーが存在しないと。ディレクトリ名も間違えてたし(涙)。

qiita.com⇧  上記サイト様の情報で、adminユーザーはデフォルトで存在するもんだと思い込んでました、残念。

SYSTEMユーザーだと、expdpコマンド自体は実行できるようだけど、エラー。

ORA-39002: invalid operation
ORA-39070: Unable to open the log file.
ORA-39087: directory name HOGE is invalid

usernameにwrite directory権限がなければ、書き込みができない。ただし、上記のようなエラーメッセージとなるため、わかりづらい。

ディレクトリがあるのにexpdpができない – あんじーのテクニカルブログ

というわけで、DBにログインして、ユーザーに権限を付与してあげる必要があるようです。というか、SYSTEMユーザーってあんまり権限ないんですかね...。

GRANT READ, WRITE ON DIRECTORY [ディレクトリオブジェクト名] TO [DBに存在するユーザー名];

f:id:ts0818:20180603171028p:plain

全体エクスポート・モードを使えるように、さらに権限を付与。(SYSTEMユーザーの場合は、「EXP_FULL_DATABASE」権限を付与しなくても良かったようです。)

GRANT EXP_FULL_DATABASE TO [DBに存在するユーザー名];

f:id:ts0818:20180603171357p:plain

もうひとつのコマンドプロンプトに戻って、 再度expdpを実行するも同じエラー。

totto2015.com

⇧  上記サイト様によると、「ディレクトリが定義されていないのが原因」らしい。

ディレクトリを確認。 

select directory_path from ALL_DIRECTORIES;

f:id:ts0818:20180603172312p:plain

定義されてるんだけど。

すみません、タイポ(タイピングミス)でした。expdb_dirじゃなくて、expdp_dirでしたね....うっかり八兵衛的なミスをしてしまった。

f:id:ts0818:20180603175015j:plain

コマンドプロンプトが壮絶な文字化けをしてるせいで分かりづらいですが、エラーは出てないっぽいです。

f:id:ts0818:20180603175155p:plain

一応、ダンプファイル(test.dmp)も配置されました。 

f:id:ts0818:20180603175322p:plain

 

次はデータベースを削除します。(Oracle Database全体をアンインストールするんではなく、あくまで、Oracle Databaseの中のデータベースの削除のこと)

dba.stackexchange.com

⇧  上記サイト様を参考にします。

気になるのは、どのサイト見ても、Oracleの説明にある、

このコマンドは、RMANプロンプトでのみ実行してください。ターゲット・データベースに接続している必要があります。ターゲット・データベースは、排他的にマウントされ、オープンされていない状態で、RESTRICTモードで起動されている必要があります。

DROP DATABASE - Oracle® Databaseバックアップおよびリカバリ・リファレンス 12リリース1 (12.1)

⇧  RMANプロンプトってので実施してない... RMANプロンプトは特に必要ないのかしら?必要ないという方向で進めますが。

一旦、データベースをシャットダウンし、

shutdown

f:id:ts0818:20180603183259p:plain

RESTRICTモードで再起動。 

startup force mount exclusive restrict    

f:id:ts0818:20180603183506p:plain

 いざ、データベースの削除。

drop database;   

f:id:ts0818:20180603184632p:plain

⇧  あっさり削除されてしまった。 (ちゃんと綺麗な状態ですべての情報が消えていてくれるのを願うばかりです。)

 

では、いよいよ新たなデータベース・キャラクタ・セットでデータベースを作成してまいります。

今回は、sqlplusから、CREATE DATABASE文で、かつ、Oracle Managed Filesを使用しないCDBの作成(PDBの雛型となるもの、PDB$SEEDも同時に作成)を行っていきたいと思います。

docs.oracle.com

イメージ的には、

f:id:ts0818:20180610153625p:plain

⇧  というようなCDBの構成があるとすると、

f:id:ts0818:20180610153708p:plain

⇧  上図の部分のみをまずは作成するようなイメージですかね?

で、データベース作成に、初期化パラメーターファイルが影響してくるようです。

 

sql-oracle.com

初期化パラメータファイルには、 

  • PFILE(パラメーターファイル)
    • テキスト形式
  • SPFILE(サーバーパラメーターファイル)
    • バイナリ形式(PFILEを基に作成する必要あり)

2種類あるのですが、SPFILEを利用したい場合は、あらかじめPFILEを作成しておいてから、

CREATE SPFILE='作成するspfileのフルパス' FROM PFILE='作成する元のpfileのフルパス'

とするようです。

ORACLEの説明では、

このSQL*Plusコマンドでは、テキスト形式の初期化パラメータ・ファイル(PFILE)がデフォルトの場所のデフォルトのファイル名で読み込まれ、テキスト形式の初期化パラメータ・ファイルからサーバー・パラメータ・ファイル(SPFILE)が作成されて、SPFILEがデフォルトのSPFILE名でデフォルトの場所に書き込まれます。

Oracle Databaseの作成および構成

とあるように、デフォルトの場所にPFILEを作成していて、SPFILEをデフォルトの場所に配置するので構わない場合は、 

CREATE SPFILE FROM PFILE;

で良いようです。

デフォルトの場所って?

docs.oracle.com

PFILE(パラメーターファイル)のデフォルトのパス

プラットフォーム デフォルト名 デフォルトの場所
UNIXおよびLinux init[ORACLE_SID名].ora
たとえば、[ORACLE_SID名]がmynewdbデータベースの初期化パラメータ・ファイル名は次のようになります。
initmynewdb.ora
$ORACLE_HOME/dbs
Windows init[ORACLE_SID].ora
たとえば、[ORACLE_SID名]がmynewdbデータベースの初期化パラメータ・ファイル名は次のようになります。
initmynewdb.ora
ORACLE_HOME\database

SPFILE(サーバーパラメーターファイル)のデフォルトのパス

プラットフォーム PFILEのデフォルト名 PFILEのデフォルトの場所
SPFILEのデフォルト名 SPFILEのデフォルトの場所
UNIXおよびLinux init[ORACLE_SID名].ora
たとえば、[ORACLE_SID名]がmynewdbデータベースの初期化パラメータ・ファイル名は次のようになります。
initmynewdb.ora
$ORACLE_HOME/dbs
spfile[ORACLE_SID].ora Oracle ASMを使用しない場合:
Oracle_Home/dbsまたはデータファイルと同じ場所
Oracle ASMを使用する場合:
データファイルと同じディスク・グループ(データベースがDBCAによって作成されたことを想定)
Windows init[ORACLE_SID].ora
たとえば、[ORACLE_SID名]がmynewdbデータベースの初期化パラメータ・ファイル名は次のようになります。
initmynewdb.ora
ORACLE_HOME\database
spfile[ORACLE_SID].ora Oracle ASMを使用しない場合:
OH\database
Oracle ASMを使用する場合:
データファイルと同じディスク・グループ(データベースがDBCAによって作成されたことを想定)

となっていますね。

自分の場合ですと、PFILEは、『initORCL.ora』ファイルになりそうです。

f:id:ts0818:20180610170451p:plain

ORACLEインスタンス起動時(データベースが無い状態なので、nomountでORACLEインスタンスを起動)に、PFILEかSPFILEのどちらかが使われたかは、

f:id:ts0818:20180610171319p:plain

下記コマンドで確認できるようです。

SELECT VALUE FROM V$PARAMETER WHERE NAME = 'spfile';

f:id:ts0818:20180610171452p:plain

⇧  VALUE が空なので、PFILEのほうが使われたってことらしい。

でも、これって、SPFILE自体があるのか無いかの確認にはならない気が...。SPFILE自体はあるけど使ってないだけだったりする可能性もあるし。

まぁ、PFILEにいたっては、ファイルの場所を確認する術がないらしい...大丈夫か?、Oracleさん....。

d.hatena.ne.jp

 

脱線してしまいましたが、 

blog.wackwack.net

⇧  上記サイト様を参考に、create database文でデータベースを作成する流れを整理。

  • PFILE(init[ORALCE_SID].ora)の作成と編集
    • PFILEが無い場合は、$ORACLE_HOME/dbs/init.oraをコピーして、$ORACLE_HOME/dbs/init[ORALCE_SID].oraを作成
  • ログファイル、DBファイルを格納するためのディレクトリの作成
  • PFILEからSPFILEを作成(OSDBAユーザにて、SYSDBA権限でログインした状態で)
  • ORACLEインスタンス起動(NOMOUNTオプションで)
  • CREATE DATABASE文の発行

 

まずは、ORACLE_SIDを確認する必要があるわけですが、

sql-oracle.com

⇧  上記サイト様によりますと、ORACLEインスタンスに接続してる状態(ORACLEインスタンスが生成済みであるという前提で)で、

SELECT INSTANCE_NAME FROM V$INSTANCE;

でいけるそうです。インスタンスが複数ある場合は、接続前に、どのインスタンスに接続するか決めておく必要があるようです。

f:id:ts0818:20180616141139p:plain

自分の場合は、ORACLE_SID は、「ORCL」であるので、$ORACLE_HOME/dbs/initORCL.oraというPFILEがあれば良いということになります。

もうひとつ、コマンドプロンプトを起ち上げ、oracleユーザーでsshログインし、PFILEがあるか確認。

f:id:ts0818:20180616142707p:plain

⇧  initORCL.ora というPFILEファイルがあります。無い場合は、$ORACLE_HOME/dbs/init.oraを基に、$ORACLE_HOME/dbs/init[ORALCE_SID].oraを作成します。

PFILEを編集します。[$ORACLE_HOME]、[ORACLE_SID]はご自分の環境に合わせてください。

vi [$ORACLE_HOME]/dbs/init[ORACLE_SID].ora;

f:id:ts0818:20180616143749p:plain

とりあえず、こんな感じで。

db_name='ORCL'
memory_target=1G
processes = 150
audit_file_dest='/opt/app/oracle/admin/orcl/adump'
audit_trail ='db'
db_block_size=8192
db_domain=''
db_recovery_file_dest='/opt/app/oracle/fast_recovery_area'
db_recovery_file_dest_size=2G
diagnostic_dest='/opt/app/oracle'
dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLXDB)'
open_cursors=300
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='UNDOTBS1'
# You may want to ensure that control files are created on separate physical
# devices
control_files = (/opt/app/oracle/product/12.2.0.1/dbhome_1/dbs/ora_control1.ctl, /opt/app/oracle/product/12.2.0.1/dbhome_1/dbs/ora_control2.ctl)
compatible ='12.2.0.1.0'
# cdb
enable_pluggable_database=true
# Oracle Managed Files
# db_create_file_dest='/opt/app/oracle/oradata'
  

f:id:ts0818:20180616144631p:plain

編集が終わったら、「Esc」キーを押して、「:wq」で保存して、viエディターを終了します。

続いて、ログファイル、DBファイルを格納するためのディレクトリを作成。

Oracleの「例1: Oracle Managed Filesを使用しないCDBの作成」の説明では、

docs.oracle.com

の4つを作成する感じですかね?

logファイルを格納する場所は、Oracle Databaseが破損した場合を考えて、$ORACLE_HOMEを含むパスは避けた方が良さそうってことですかね。 

では、ディレクトリを作成。

eng-entrance.com

⇧  上記サイト様によりますと、mkdirの-p オプションで、作成しようとたディレクトリが存在する場合もエラーが出ないようにできるようです。

CDBのデータ格納用のディレクトリを作成

mkdir -p [$ORACLE_HOME]/oradata/[PFILEのdb_name]

f:id:ts0818:20180616160958p:plain

PDBのデータ格納用のディレクトリを作成

mkdir -p [$ORACLE_HOME]/oradata/[PDB$SEED用の適当なディレクトリ]

f:id:ts0818:20180616161033p:plain

続いて、log用のディレクトリですが、今回、/opt 直下に作成しようと思うので、rootユーザー(スーパーユーザー)に切り替える必要があります。(そもそも、ログを格納するディレクトリをどこに作成すれば良いか分からんです。)

で、Vagrant仮想マシンを作成している場合、root(スーパーユーザー)のパスワードは、デフォルトでは、vagrant でいけるかと。(vagrantで作成したのを忘れてて2回ログインに失敗してますが...)

f:id:ts0818:20180616161720p:plain

 

log1のデータ格納用のディレクトリを作成

mkdir -p [log1用の適当なディレクトリ]

f:id:ts0818:20180616162039p:plain

log2のデータ格納用のディレクトリを作成

mkdir -p [log2用の適当なディレクトリ]

f:id:ts0818:20180616162101p:plain

ただ、これだと、Oracle Databaseが、作成したログのディレクトリに、権限の問題でアクセス できないと思われるので、ディレクトリの権限を変更する必要があるかと。

f:id:ts0818:20180616162403p:plain

⇧  いまだと、「所有者」「グループ」がともに、rootユーザーになってるっぽい。

よく分からんけど、

f:id:ts0818:20180616163042p:plain

⇧  /opt/app/oracle みたいな権限にすれば良いのではないかと。

まずは、「所有者」「グループ」を、

webkaru.net

⇧  上記サイト様を参考に変更。変更したいディレクトリを直下に含むディレクトリまで移動しておいて、下記コマンドを実行。

chown [ユーザー]:[グループ] [ディレクトリ名、またはファイル名]

f:id:ts0818:20180616164800p:plain

ディレクトリのパーミッション(権限)を修正します。

「 /opt/app/oracle」は「drwxrwrr-x.」 となっているので、新しく作成したログのディレクトリ(「/opt/oracle12.2r2_log01」や「/opt/oracle12.2r2_log02」)は「drwxr-xr-x.」となっているので、「グループ」の書き込み権限が足りていないことになります。

 

ディレクトリやファイルのパーミッション(権限)については、

qiita.com

⇧  上記サイト様が詳しいです。

chmod 775 oracle12.2r2_log01
chmod 775 oracle12.2r2_log02

f:id:ts0818:20180616165533p:plain

⇧  パーミッション(権限)が設定できました。

CREATE DATABASE文で必要になるディレクトリの準備が整ったので、 oracleユーザーに戻っておきます。

f:id:ts0818:20180616165956p:plain

 

続いて、PFILEを基に、SPFILE(サーバー・パラメータ・ファイル)を作成します。

docs.oracle.com

ORACLEインスタンスが止まっている必要があるようなので、起動してる場合は一度シャットダウンします。

nomountオプションでORACLEインスタンスを起動していた場合、「ORA-01507: database not mounted」は想定通りの挙動らしく、エラーは無視して良いようです。

f:id:ts0818:20180616171232p:plain

あらためて、ORACLEインスタンス(起動前)に接続します。 

f:id:ts0818:20180616171837p:plain

デフォルトの場所に、SPFILEを作成します。 

docs.oracle.com

 

CREATE SPFILE FROM PFILE;

f:id:ts0818:20180616173001p:plain

もう一つのほうのコマンドプロンプトで確認すると、$ORACLE_HOME/dbs/spfile[ORACLE_SID].ora というファイルが作成されています。

f:id:ts0818:20180616173318p:plain

 

続いて、データベースをマウントせずにORACLEインスタンスを起動します。

通常、この方法で起動するのはデータベースの作成時またはメンテナンス時のみです。この例では、初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルがデフォルトの場所に配置されているため、PFILE句の指定は不要です。

CDBの作成および構成 - Oracle® Database管理者ガイド 12c リリース2 (12.2)

デフォルト以外の場所にSPFILEを作成した場合は、SQL文で、PFILE句を指定する必要があるようです。

STARTUP NOMOUNT;

f:id:ts0818:20180616174404p:plain

では、

CREATE DATABASE文を実行します。Oracleの見本では、

CREATE DATABASE [PFILEのdb_name]
  USER SYS IDENTIFIED BY [SYSユーザーのpassword]
  USER SYSTEM IDENTIFIED BY [SYSTEMユーザーのpassword]
  LOGFILE GROUP 1 ('[log1格納用ディレクトリ]/redo01a.log','[log2格納用ディレクトリ]/redo01b.log') 
             SIZE 100M BLOCKSIZE 512,
          GROUP 2 ('[log1格納用ディレクトリ]/redo02a.log','[log2格納用ディレクトリ]/redo02b.log') 
             SIZE 100M BLOCKSIZE 512,
          GROUP 3 ('[log1格納用ディレクトリ]/redo03a.log','[log2格納用ディレクトリ]/redo03b.log') 
             SIZE 100M BLOCKSIZE 512
  MAXLOGHISTORY 1
  MAXLOGFILES 16
  MAXLOGMEMBERS 3
  MAXDATAFILES 1024
  CHARACTER SET AL32UTF8
  NATIONAL CHARACTER SET AL16UTF16
  EXTENT MANAGEMENT LOCAL
  DATAFILE '[$ORACLE_HOME]/oradata/[CDBのデータ格納用ディレクトリ]/system01.dbf'
    SIZE 700M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
  SYSAUX DATAFILE '[$ORACLE_HOME]/oradata/[CDBのデータ格納用ディレクトリ]/sysaux01.dbf'
    SIZE 550M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
  DEFAULT TABLESPACE deftbs
     DATAFILE '[$ORACLE_HOME]/oradata/[CDBのデータ格納用ディレクトリ]/deftbs01.dbf'
     SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
  DEFAULT TEMPORARY TABLESPACE tempts1
     TEMPFILE '[$ORACLE_HOME]/oradata/[CDBのデータ格納用ディレクトリ]/temp01.dbf'
     SIZE 20M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED
  UNDO TABLESPACE undotbs1
     DATAFILE '[$ORACLE_HOME]/oradata/[CDBのデータ格納用ディレクトリ]/undotbs01.dbf'
     SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
  ENABLE PLUGGABLE DATABASE
    SEED
      FILE_NAME_CONVERT = ('[$ORACLE_HOME]/oradata/[CDBのデータ格納用ディレクトリ]/', 
                         '[$ORACLE_HOME]/oradata/[PDBのデータ格納用ディレクトリ]/')
    LOCAL UNDO ON;    

というような構造になってますかね。

実際には、下記のようなコマンドを実行しました。(このへんの情報は、ご自身の環境に合わせてください。)

CREATE DATABASE ORCL
 USER SYS IDENTIFIED BY sys_ts0818
USER SYSTEM IDENTIFIED BY system_ts0818
LOGFILE GROUP 1 ('/opt/oracle12.2r2_log01/redo01a.log','/opt/oracle12.2r2_log02/redo01b.log') SIZE 100M BLOCKSIZE 512, GROUP 2 ('/opt/oracle12.2r2_log01/redo02a.log','/opt/oracle12.2r2_log02/redo02b.log') SIZE 100M BLOCKSIZE 512, GROUP 3 ('/opt/oracle12.2r2_log01/redo03a.log','/opt/oracle12.2r2_log02/redo03b.log') SIZE 100M BLOCKSIZE 512 MAXLOGHISTORY 1 MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 1024 CHARACTER SET AL32UTF8 NATIONAL CHARACTER SET AL16UTF16 EXTENT MANAGEMENT LOCAL DATAFILE '/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/ORCL/system01.dbf' SIZE 700M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED SYSAUX DATAFILE '/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/ORCL/sysaux01.dbf' SIZE 550M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED DEFAULT TABLESPACE deftbs DATAFILE '/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/ORCL/deftbs01.dbf' SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED DEFAULT TEMPORARY TABLESPACE tempts1 TEMPFILE '/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/ORCL/temp01.dbf' SIZE 20M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED UNDO TABLESPACE undotbs1 DATAFILE '/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/ORCL/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED ENABLE PLUGGABLE DATABASE SEED FILE_NAME_CONVERT = ('/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/ORCL/', '/opt/app/oracle/product/12.2.0.1/dbhome_1/oradata/pdbseed/') LOCAL UNDO ON;

 

f:id:ts0818:20180616175827p:plain

かなり時間がかかりますが、データベースが無事作成されたようです。

f:id:ts0818:20180616180139p:plain

 

続いて、マルチテナント機能を利用している場合(つまり、CDBでデータベースを構成している場合)は、 データベース作成後に、

catcdb.sqlのSQLスクリプトを実行します。このスクリプトによって、CDBで必要なコンポーネントがすべてインストールされます。

CDBの作成および構成 - Oracle® Database管理者ガイド 12c リリース2 (12.2)

⇧  $ORACLE_HOME/rdbms/admin/catcdb.sql を実行する必要があるようです。sqlplusから、

@?/rdbms/admin/catcdb.sql

を実行すれば良いようです。

実行すると入力を求められますが、

⇧  Oracle Database 12c Release 2(1.2.2.0.10) のcatcdb.sql 自体にバグがあったのを忘れっとった...。

このへんのハマりポイントについては、 

ts0818.hatenablog.com

⇧  自分の記事で恐縮ですが、こちらで。

 で、入力内容については、

f:id:ts0818:20180616181743p:plain

 「$ORACLE_HOME/rdbms/admin」「$ORACLE_HOME/rdbms/admin/catcdb.pl」を順番に入力すればOKっぽいです。(Oracleの説明が一切ない部分なので、よく分かりませんが)

はい、エラ~。

「Can't locate Util.pm  in @INC (you may need to install the Util module)(@INC contains: ~)」

f:id:ts0818:20180616183021p:plain

バグの修正してなかったかと思ったけど、$ORACLE_HOME/rdbms/admin/catcdb.sqlの内容は、修正済みだったんだけど~。

f:id:ts0818:20180616185443p:plain

どうやら、perlのモジュールが読み込めない状態で、つまり、Perl系のモジュールまでのパスが通って無さそうな気がしますね。

古い情報しかないんですが、Oracle 10g のSolaris向けの説明で、

4.2.2 osso1013スクリプトの実行に失敗する

osso1013スクリプトを実行してインフラストラクチャに10.1.3中間層を登録すると、Can't locate File/Compare.pm in @INCというエラーによって操作が失敗します。

この問題を回避するには、osso1013スクリプトを実行する前に、PERL5LIB環境変数を次のように設定します。

PERL5LIB=$ORACLE_HOME/perl/lib/5.8.3/sun4-solaris-thread-multi:$ORACLE_HOME/perl/lib/5.8.3:$ORACLE_HOME/perl/5.8.3/lib
export PERL5LIB
./osso1013

Oracle HTTP Server - Oracle Application Serverリリース・ノート 10g リリース3(10.1.3)for Solaris Operating System (SPARC 64-bit)

PERL5LIB環境変数の話が出てきてますね。 

前の時に参考にしたサイモンさんも、

Oracle 12c: ORA-00942 on CREATE PLUGGABLE DATABASE – Simon Krenger

Cause and Resolution

These errors appear when the CATALOG.SQL, CATPROC.SQL and PUPBLD.SQL scripts were not executed using the catcon.pl script provided by Oracle. This means views for the data dictonary were only created in your root database (the CDB) but not in the seed database. This leads to the errors above.

って言っていて、

Run the scripts to create the catalog as follows:

$ PERL5LIB=$ORACLE_HOME/rdbms/admin:$PERL5LIB; export PERL5LIB
$ perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -l /home/oracle -b catalog $ORACLE_HOME/rdbms/admin/catalog.sql;
$ perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -l /home/oracle -b catproc $ORACLE_HOME/rdbms/admin/catproc.sql;
$ perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -l /home/oracle -b pupbld -u SYSTEM/oracle $ORACLE_HOME/sqlplus/admin/pupbld.sql;

⇧  PERL5LIBって環境変数を当たり前のように使ってたんだけど、よく見ると、catcdb.sql は実行してないっぽいですね、駄目じゃん...。

 っていうか情報が全然なさ過ぎてびっくりなんですが。

そしたら、Perl の解説ブログで情報が。

perl-users.jp

⇧  上記サイト様によりますと、

皆さんご存知の通り、このエラーは "@INC" で指定されたディレクトリの中にモジュールが見つからなかった場合に発生するエラーです。つまり、モジュールをインストールし忘れているか、モジュールがどこに置いてあるのかを適切に設定していないか、の (およそ) どちらかですね。

@INC にみる Perl のやりかたがいっぱい - JPerl Advent Calendar 2010 Casual Track

ということらしい...いやいや、ご存じでないですが。 

qiita.com

⇧  上記サイト様によると、モジュール読み込みに失敗するパターンがいろいろ存在するらしい... Perlも闇が深そうですね。

 

で、Oracle Database 12c でマルチコンテナ機能(CDBのこと)でデータベースの構築をする際、sqlplusからCREATE DATABASE文でデータベースを作成までは問題なくとも、CDBに必要な情報を取得しようと、「@?/rdbms/admin/catcdb.sql」を実行する前に、Perlのbinまでのパスを環境変数に設定していないと、エラーになるらしい。

Here there is a very important thing that you have to remember. The next step is to execute the script catcdb.sql. As per Oracle Documentation this script installs all of the components required by a CDB. The important thing you have to remember is to put in your PATH environment variable your Perl binaries directory, as I show you below:

export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin/:$PATH

How to create a CDB with sqlplus and 12c Documentation - Oracle Blog - Oracle - Toad World

 

というか、Oracle Database 12c Release 2 (12.2.0.1.0) 以前のバージョンでも問題が起こってるのに、何故Oracleのガイドに 載せてくれてないんですかね?流石、Oracle、安定の不親切さ。

 

何か王者の風格と言った感じの方のブログでも、とりあえず、sqlplusから「@?/rdbms/admin/catcdb.sql」を実行してなさそうですね。

www.dba-oracle.com

⇧  上記サイト様によりますと、スクリプト(ここでは、catcon.pl)の影響を与えたくないディレクトリがある場合は、「cd $ORACLE_HOME/rdbms/admin/」を行わずに、「export PERL5LIB=$ORACLE_HOME/rdbms/admin:$PERL5LIB」でパスを通してからスクリプトを実行って感じですかね?

 

なんか、Windowsの環境では、

あんまり深追いしてませんが、Oracle Server をインストールすると

  • 10g: PERL5LIB に Oracle 用の設定がワラワラ入る
  • 11g: PERL5LIB が定義されるが値は空

となるので、10g Server 使ってたときは Strawberry Perl の起動バッチファイルを改造して PERL5LIB をリセットしてました。11g Server からは必要なくなりましたね、とそういう話です。

Oracle 10g Server / 11g Server で環境変数 PERL5LIB の使われ方が微妙に変わった? - echo y-

ということを、 

d.hatena.ne.jp

⇧  上記サイト様が説明してくれていました。

なんとなく、PERL5LIB に常に値が設定されているのは宜しくないような感じですかね?

いままで見てきた参考サイトの皆々様も、

qiita.com

⇧  上記サイト様の説明あるように、一時的にパスを通してる感じですね。

 

ちなみに、自分の環境では、

f:id:ts0818:20180617132701p:plain

環境変数 PERL5LIB はあるけど、値は空ってことで良いのかな?

とりあえず、環境変数 PERL5LIB の設定がこれで良いのかは分からんですが、設定。

PERL5LIB=$ORACLE_HOME/rdbms/admin:$PERL5LIB; export PERL5LIB

f:id:ts0818:20180617134534p:plain

⇧  っていうか、これで、Perl環境変数、通ってるのかな?

 

続いて、もう一つのコマンドプロンプトのほうで、 

ORACLEインスタンスの接続をSHUTDOWNして、STARTUPでORACLEインスタンスを起動し直して、データベースとマウントしておきます。

f:id:ts0818:20180616184315p:plain

で、エラー。普通にコマンドをミスりました。$ORACLE_HOMEを自分の環境のものに置き換えてなかった...。

Can't locate Util.pm in @INC (you may need to install the Util module) 
(@INC contains: 
/opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin 
/opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/site_perl/5.22.0/x86_64-linux-thread-multi 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/site_perl/5.22.0 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0 .) 
  at /opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/catcdb.pl line 35.

BEGIN failed--compilation aborted 
  at /opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/catcdb.pl line 35.
Can't locate Util.pm in @INC (you may need to install the Util module) 
(@INC contains: 
/opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin 
/opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/site_perl/5.22.0/x86_64-linux-thread-multi 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/site_perl/5.22.0 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi 
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0 .) 
  at /opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/catcdb.pl line 35.

BEGIN failed--compilation aborted 
  at /opt/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/catcdb.pl line 35.
catcon.pl: completed successfully

f:id:ts0818:20180617140419p:plain

う~ん、エラー起きまくってますが、「catcon.pl:completed successufully」とか意味不明なんで。

 

相変わらず、PerlのモジュールのUtil.pmが認識されてないっぽい。

tweeeety.hateblo.jp

⇧  上記サイト様を参考に、

perlのサーチパスを確認(@INC)

perl -e 'use Data::Dumper;print Dumper @INC'

f:id:ts0818:20180617141921p:plain

perlの読み込まれているモジュールの確認(%INC)

perl -e 'use Data::Dumper;print Dumper %INC'

f:id:ts0818:20180617142042p:plain

インストールされているCPANモジュールの確認(grepで検索対象を絞ってないから数が膨大です...)

find `perl -e 'print "@INC"'` -name '*.pm' -print

f:id:ts0818:20180617142405p:plain

で、Util.pmでしたっけ?

/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/site_perl/5.22.0/HTTP/Headers/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/Hash/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/List/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/Scalar/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/Sub/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/autodie/ScopeUtil.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/Hash/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/List/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/Scalar/Util.pm
/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi/Sub/Util.pm

なんか同じモジュールが二回出てきてるのが結構あるけど...。

とりあえず、モジュール自体はインストールされてるらしい。おそらく、モジュールまでのパスが通ってないんだと思われます。

qiita.com

⇧  上記サイト様でも、「環境変数 PERL5LIB を使う」方法が説明されてるので、「PERL5LIB」はPerlのモジュールのための環境変数みたいですね。

 

@INCで、検索パスが、

$VAR2 = '/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/site_perl/5.22.0';
$VAR3 = '/opt/app/oracle/product/12.2.0.1/dbhome_1/perl/lib/5.22.0/x86_64-linux-thread-multi';

ってなってるから、モジュールを探してるんだと思うんだけど、まさか、検索パスとUtil.pmの間にフォルダが1つ、2つ余分にあるのがダメってことはないですよね?

Perlの仕様が分からないので、何とも言えないですが。

 

それと、結局、「@?/rdbms/admin/catcdb.sql」の代わりが、

perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -l /home/oracle -b catalog $ORACLE_HOME/rdbms/admin/catalog.sql;
perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -l /home/oracle -b catproc $ORACLE_HOME/rdbms/admin/catproc.sql;
perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -l /home/oracle -b pupbld -u [SYSTEMユーザー]/[SYSTEMユーザーのパスワード] $ORACLE_HOME/sqlplus/admin/pupbld.sql;

の3つのスクリプトの実行でまかなえているのかが謎ですが、ちょっと、2018年6月17日(日)現在においても、他に方法が見当たらない。

Oracle 12c: Create a Container Database (CDB) manually with CREATE DATABASE scriptmarvinprudente.wordpress.com

⇧  上記サイト様によると、

We need to run the Oracle supplied dictionary scripts like catalog.sql, catproc.sql, pupbld.sql to populate the necessary dictionary views when we create a Oracle database manually using CREATE DATABASE statement.

But it’s different for a container database, because we have multiple container databases such as CDB$ROOT and PDB$SEED, we need to run these scripts against each of these containers. To simplify the creation of dictionary views in a CDB, Oracle provides a script called catcdb.sql located under $ORACLE_HOME/rdbms/admin directory.

However, when we run the catcdb.sql script, it creates all the database components like the way DBCA does, it will create database components like Spatial, Oracle Text, XDK, etc, even if we wouldn’t use them. So we would use the catcon.pl located under $ORACLE_HOME/rdbms/admin to run the Oracle supplied scripts (catalog.sql, catproc.sql, etc) against our container databases.

Oracle 12c: Create a Container Database (CDB) manually with CREATE DATABASE script – Marvin's Database Blog

⇧  上記の内容を、Google翻訳したところ、

「CREATE DATABASE文を使用してOracleデータベースを手動で作成する場合は、catalog.sql、catproc.sql、pupbld.sqlなどのOracle提供の辞書スクリプトを実行して必要な辞書ビューを作成する必要があります。」ってことらしいです。

「CDBでのディクショナリ・ビューの作成を簡素化するために、$ ORACLE_HOME / rdbms / adminディレクトリにcatcdb.sqlというスクリプトがあります。 」とも言ってますね。

まぁ、でも、結論として、
「したがって、$ ORACLE_HOME / rdbms / adminにあるcatcon.plを使用して、コンテナ・データベースに対してOracle提供のスクリプト(catalog.sql、catproc.sqlなど)を実行します。」って言ってますね。

 

つまり、「@?/rdbms/admin/catcdb.sql」ではなく、catcon.plで、「catalog.sql」「catproc.sql」「pupbld.sql」の3つのスクリプトを実行しろってことですかね?(「pupbld.sql」に関してだけは、catcon.plだと権限の問題でエラーになったので、自分はsqlplusから「@?/sqlplus/admin/pupbld.sql」を実行しました。)

 

で、上記のsqlに関しては、Oracleさんはcatcon.plで実施すれば良いのでは?的なことを、何故か

CDBでは、SQLスクリプトおよびSQL文を実行する場合、catcon.plスクリプトが最良の方法となります。

Oracle Databaseインストールには、複数のSQLスクリプトが含まれています。これらのスクリプトにより、データ・ディクショナリ・ビューの作成やオプションのインストールなどの操作が実行されます。

catcon.plスクリプトPerlスクリプトであり、オペレーティング・システムのプロンプトで実行される必要があります。

SQL*Plusを使用したCDBの管理 - Oracle® Database管理者ガイド 12c リリース2 (12.2) 

docs.oracle.com

⇧  「SQL*Plusを使用したCDBの管理」の中で説明しているという...catcon.plは、sqlplusに接続して使っているわけではなさそうなんですが....。

 

ちなみに、スクリプトが実行し終わるまでにかなり時間かかります。(特に、catproc.sqlの実行がめちゃくちゃ時間かかります。)

スクリプトの実行は、ORACLEインスタンスをデータベースをマウントした状態で起動しておく必要があります。(「startup nomount」じゃなくて、「startup」で起動しておくこと。)

catlog.sql

f:id:ts0818:20180617154438p:plain

catproc.sql

f:id:ts0818:20180617162343p:plain

pupbld.sql

f:id:ts0818:20180617162629p:plain

f:id:ts0818:20180617162757p:plain

f:id:ts0818:20180617162852p:plain

f:id:ts0818:20180617162922p:plain

f:id:ts0818:20180617163013p:plain

f:id:ts0818:20180617163055p:plain

f:id:ts0818:20180617163123p:plain

むちゃくちゃ、エラーが出まくっているんだが... 

権限が不足してるそうな...前回は、pubbld.sqlに関しては、sqlplusから直接実行しましたな。 

一応、データベースに再接続して、

f:id:ts0818:20180617171558p:plain

今回も、sqlplusから直接実行しました。(SYSTEMユーザーでなくて、SYSユーザーで実行してしまってるっぽいですが...)

f:id:ts0818:20180617173734p:plain

f:id:ts0818:20180617173910p:plain

f:id:ts0818:20180617173937p:plain

f:id:ts0818:20180617174008p:plain

f:id:ts0818:20180617174048p:plain

f:id:ts0818:20180617174115p:plain

f:id:ts0818:20180617174135p:plain

f:id:ts0818:20180617174202p:plain

f:id:ts0818:20180617174227p:plain

f:id:ts0818:20180617174252p:plain

f:id:ts0818:20180617174316p:plain

f:id:ts0818:20180617174345p:plain

f:id:ts0818:20180617174438p:plain

下記のエラーが出ていますが、

「ORA-00942: 表またはビューが存在しません。」
「ORA-01434: 削除するプライベート・シノニムが存在しません。」

ORA-01432: 削除するパブリック・シノニムが存在しません。
ORA-00942: 表またはビューが存在しません。
ORA-01918: ユーザー' string' は存在しません
ORA-01919: ロール' string' は存在しません
ORA-04043: オブジェクトstring は存在しません。 
ORA-02289: 順序が存在しません。 
ORA-01434: 削除するプライベート・シノニムが存在しません 
のようなエラーはcatproc.sqlなどDB作成完了後に ディクショナリ作成したり,基本のプロシーじゃなどを作るスクリプトで普通に出ます。

作る前にまず削除してから作ろうとするからです。

ですからこれらがcatproc.sqlなどでこれらが出ているのならば問題ありません。

Oracle Technology Network (OTN) Japan - 掲示板 : ORA-01034: ORACLE not availableについて。 ...

⇧  上記サイト様によると、pupbld.sqlSQLスクリプトの実行で、これらのエラーは出ても問題ないようです。 

ようやく、データベース作成はできたということで、データベース・キャラクタ・セットの確認。

SELECT
        PARAMETER,
        VALUE
FROM
        NLS_DATABASE_PARAMETERS
WHERE
        PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');
        

f:id:ts0818:20180617175005p:plain

期待通りのデータベース・キャラクタ・セットになっていそうです。

では、エクスポートしておいたデータをインポートしますか。

ちなみに、インポートにもいろいろ方法があるようですが、今回は、データベース・キャラクタ・セットの変更(実際に完全な変更は無理)がしたいので、全体インポートを行います。

データベースを削除したので、ディレクトリオブジェクトも初期化されてるようです。

ディレクトリオブジェクトの一覧を確認するコマンドとしては、

SELECT * FROM ALL_DIRECTORIES;
SELECT * FROM DBA_DIRECTORIES;

の2つが存在するようですが、

データディクショナリビュー

⇧  上記サイト様によると、

  • ALL_DIRECTORIES
  • DBA_DIRECTORIES

と、かなり意味合いが異なるようなので、注意が必要かと。

で、エクスポートした際に、「/home/oracle/expdir」をディレクトリオブジェクトとして登録していましたが、データベースを削除した時点で、ディレクトリオブジェクトとしての登録は消えますが、物理的なディレクトリとしては残っています。

f:id:ts0818:20180617201853p:plain

なので、ダンプしたファイルも残っています。 

f:id:ts0818:20180617202225p:plain

ただ、ディレクトリオブジェクトとして登録しないと、OracleのDataPumpユーティリティ が、読み込むべきダンプファイルを探しに行けないんだと思われます。

ということで、ダンプファイルを格納しているディレクトリを、今度はインポートのためのディレクトリオブジェクトとして登録すれば良いかと思われます。

 

2018年6月30日(土)追記:↓ ここから

どうやら、

qiita.com

⇧  上記サイト様によりますと、

importする場合には、directory objectをpdb内に作る必要あり。

備忘録 12cのpdbをデータポンプでexport

 CDBの中のPDBの情報をインポートするには、新規データベースにあらかじめPDBを作成しておいて、そのフォルダ内にディレクトリオブジェクトを作成する必要があるようです。

docs.oracle.com

ちなみに、Oracleさん、都合が悪くなるとガイド自体を消すみたいですね、いままで当たり前のように掲載してたのに...掲載してた情報に誤りがあるなら、not foundにするのでなく、一言理由を記載して欲しいです。

本当、学習意欲が下がりますね。

 

2018年6月30日(土)追記:↑ ここまで 

 

⇩  インポート用のディレクトリオブジェクトはPDB内に作る必要があるので、インポート用のディレクトリオブジェクトの作成に関しては、2018年6月30日(土)追記を参照してください。

impdirという物理的なディレクトリを作成して、ダンプファイルを移動しておきます。

stackoverflow.com

⇧  上記サイト様によると、ワンライナーで、「ディレクトリを作成後、作成したディレクトリに既存のファイルを移動」が行えるようです。

mkdir [directorie name] && mv [filename] $_

f:id:ts0818:20180617204538p:plain

⇧  上手く、「/home/oracle/impdir/test.dmp」と配置しできました。

 

では、sqlplusで接続しているコマンドプロンプトのほうで、 

CREATE DIRECTORY [ディレクトリオブジェクト名] as [ディレクトリオブジェクトしたい物理的なディレクトリのパス]; 

f:id:ts0818:20180617205337p:plain

で、今度は、sqlplusで接続していない方のコマンドプロンプトで、全体インポートを実行します。

impdp [データベースに存在するユーザー]/[データベースに存在するユーザーのパスワード] DIRECTORY=[ディレクトリオブジェクト名] DUMPFILE=[ダンプファイル名] FULL=y LOG=[出力するログファイル名]

f:id:ts0818:20180617205954p:plain

無事、インポートの実行ができたようです。

ログファイルも配置されています。

f:id:ts0818:20180617210509p:plain

 

PDBなどのリスナーなどが、まだ作成できていないので、Eclipseとの接続テストは後日とさせていただきたいと思います。

いや~、体調が悪くて、Oracleの安定の不親切さも相まって、いつも以上に疲れ切りました。他のサイトの人(特に外国の人)、Oracleのガイドに載ってないような情報にすぐ対応するとかレベルが高いっすな。

ということで、今回はこのへんで。