Oracle：expdpとimpdpの使い方まとめ

Oracle10g以降のコマンドexpdp/impdpの使い方まとめ。
さらに細かく指定したい場合は、マニュアルをみる。

よく使うOracle SQL/コマンドまとめ

expdp/impdpの実行方法
手順１．DUMPファイルを出力するDIRECTORYオブジェクトの準備
手順２．コマンド実行時に指定するOracleユーザーへの権限付与
手順３．expdpまたはimpdpの実行

DIRECTORYオブジェクトの作成

CREATE DIRECTORY ディレクトリオブジェクト名 AS 'OSのディレクトリ（絶対パス）';

※DUMPファイルはコマンドを実行するOSユーザーがオーナーとなるため、それに合わせた権限をOSディレクトリに与えておくこと。

Oracleユーザーへの権限付与

CREATE  SESSION TO Oracleユーザー名;
CREATE TABLE TO Oracleユーザー名;
GRANT READ,WRITE ON DIRECTORY ディレクトリオブジェクト名
TO expdp/impdpを実行するOracleユーザー名;

※expdp/impdpを実行するOracleユーザーとは別スキーマのオブジェクトを対象とする場合、 更に別の権限が必要となる（そのような場合は、問題なければsystemユーザーまたはそれと同等の権限を持っているユーザーで実行してしまうのが楽）。

expdpの実行（OSコマンド）

expdp Oracleユーザ名/パスワード
directory=ディレクトリオブジェクト名
（dumpfile=ディレクトリオブジェクト名:絶対パス）
（logfile= ディレクトリオブジェクト名:絶対パス）
tables=テーブル名, テーブル名,…
または
schemas=Oracleスキーマ名, Oracleスキーマ名,…

※dumpfileを省略すると、expdat.dmpファイルがディレクトリオブジェクト指定されているOSディレクトリ上に作成される。
※logfileを省略すると、export.logファイルがディレクトリオブジェクト指定されているOSディレクトリ上に作成される。
※dumpファイルとlogファイルを別ディレクトリに出力したい場合は、それぞれディレクトリオブジェクトを用意し、コマンド内で指定する。

impdpの実行（OSコマンド）

impdp Oracleユーザ名/パスワード
directory=ディレクトリオブジェクト名
（dumpfile=ディレクトリオブジェクト名:絶対パス）
（logfile= ディレクトリオブジェクト名:絶対パス）
tables=テーブル名, テーブル名,…
または
schemas=Oracleスキーマ名, Oracleスキーマ名,…
＜オプション＞
content=all（デフォルト） または data_only または metadata_only

※export時の表領域やスキーマを、import時に変更することも可能。その場合は以下のように指定する。

remap_tablespace=変更元の表領域名:変更先の表領域名
remap_schema=変更元のスキーマ名:変更先のスキーマ名

※すでにテーブルオブジェクトが作成されている環境にデータのみを入れたい場合、

　オプションでcontent=data_onlyを指定する

　テーブル定義だけImportしたい場合は、content=metadata_onlyを指定する

　デフォルトでは、テーブルを作り、データを入れるように動くため、テーブルが存在するとエラーとなる

【よくあるエラーとその対応】

１．Tableあるいはschema単位でimpdpを行う際、ORA-39151（表が存在します）が発生する。

⇒TABLE_EXISTS_ACTIONを指定する。

　・SKIP　：　表に対して何もしない。ただし、CONTENT=DATA_ONLYを指定している場合は、このオプションは無効。これがデフォルトだが、明示的にSKIPを指定しないと、impdpコマンド自体はエラー終了する。

　・APPEND　：　表のデータはそのままにして、ソースからデータをロードする。

　・TRUNCATE　：　表からデータを削除して、ソースからデータをロードする。

　・REPLACE　：　表を削除し、ソースから表とデータをロードする。ただし、CONTENT=DATA_ONLYを指定している場合は、このオプションは無効。

impdp Oracleユーザ名/パスワード
directory=ディレクトリオブジェクト名
（dumpfile=ディレクトリオブジェクト名:絶対パス）
（logfile= ディレクトリオブジェクト名:絶対パス）
tables=テーブル名
table_exists_action=[skip | append | truncate | replace]

２．schema単位でimpdpを行う際、ORA-39684（オブジェクト型USER:"XXX"はすでに存在します）が発生する。

⇒EXCLUDE＝USERを指定する。

impdp Oracleユーザ名/パスワード
directory=ディレクトリオブジェクト名
（dumpfile=ディレクトリオブジェクト名:絶対パス）
（logfile= ディレクトリオブジェクト名:絶対パス）
schema=Oracleスキーマ名
exclude=user

よく使うOracle SQL/コマンドまとめ
 

Oracle:よく使うSQL/コマンドまとめ

主にOracle DBのDBA、環境構築担当、メンテナンス担当がよく使うSQLやコマンドのまとめ

表領域操作（CREATE/ALTER/DROP TABLESPACEなど）
表（テーブル）操作（CREATE/ALTER/DROP TABLEなど）
索引（インデックス）操作（CREATE/ALTER/DROP INDEXなど）
データ操作（INSERT/UPDATE/DELETE/TRUNCATEなど）
ユーザー操作（CREATE/ALTER/DROP USERなど）
REDOログの操作（REDOグループ/メンバーの作成、変更、削除など）
expdpとimpdpの使い方
統計情報操作（収集、移行など）

実行計画の固定方法（SPM：SQL Plan Managementの利用）

DBに定義されているDDLを取得する方法

Statspack操作（インストール、Snapshot取得、自動化、削除など）

自動メンテナンスタスク（autotask）の管理

接続1回でSQLを繰り返し実行するシェルスクリプト

実行されているSQLをリアルタイムで監視し、問題のあるSQLの実行計画を確認する

効率のよいINDEXを作成するために役立つSQL

SQLのパラレル実行

ヒント句の一覧出力SQL

Viewにヒント句を指定する方法

特定のSQLだけに特定のINDEXを使用させる方法 New!(2017/10/25)

Oracle：特定のSQLだけに特定のINDEXを使用させる方法

特定のSQLにだけ使ってほしいINDEXを作りたいが、

それを作ってしまうと他のSQLに影響をしてしまうことがわかっていて、

INDEXを作るのを躊躇しまうことがある。

それに対応する方法。

よく使うOracle SQL/コマンドまとめ

以下のように対応する。

１．INDEXを「INVISIBLE」で作成する

２．作成したINVISIBLE INDEXを使用するSQLに対して、「USE_INVISIBLE_INDEXES」ヒント句を追加する

１．INDEXを「INVISIBLE」で作成する

CREATE INDEX文の最後に「INVISIBLE」をつけて作成するか、作成後、INVISIBLE属性に変更する。
INVISIBLE属性のINDEXは、オプティマイザから見えなくなり、使用されなくなる（注）。
 

CREATE INDEX 索引名 on テーブル名
( 列名,  列名, …)
TABLESPACE 表領域名
INVISIBLE;

ALTER INDEX 索引名 INVISIBLE;

（注） パラメータ「OPTIMIZER_USE_INVISIBLE_INDEXES」がFALSEの場合（デフォルト）の動作。

※「ALTER INDEX 索引名 VISIBLE;」を実行することで、通常のINDEXと同様にオプティマイザから見えるようになる。

２．作成したINVISIBLE INDEXを使用するSQLに対して、「USE_INVISIBLE_INDEXES」ヒント句を追加する

このヒント句を追加することで、通常は使用されないINVISIBLE INDEXがオプティマイザから見えるようになり、必要に応じてINDEXを使用するようになる。

複数のINVISIBLE INDEXがあった場合、それらすべてがこのヒント句を入れたSQL実行時に使用されてしまう可能性があるため、そのうちのこれだけ使用させたいという場合は、さらにINDEXヒントやNO_INDEXヒントを併用する。

（例）テーブルTBLにINDEXがIND_A、IND_B、IND_C（内BとCはINVISIBLE）が作成されており、実行するSQLに対してIND_BのINDEXを確実に使用させたい場合

SELECT /*+ USE_INVISIBLE_INDEXES
                    INDEX(TBL IND_B)
                    NO_INDEX(TBL IND_A TBL IND_C) */
列名, 列名, ...
FROM ...
WHERE ...;

※USE_INVISIBLE_INDEXESのみで事足りることが大半とは思われるため、INDEXヒントやNO_INDEXヒントは、どうしても思い通りの実行計画にならないときにつければ良い。

よく使うOracle SQL/コマンドまとめ

長時間労働は罪--ドイツの事例

働き方改革についての記事を読みまくっていると、ドイツの事例にたくさんあたる。

とかく日本と比較されるドイツは、働き方に関して日本と正反対といっていいだろう。

ドイツの労働時間がなぜ短いのか、短くできるのか、という答えの１つに、

なんと長時間労働を「させる」と罰金が科せられるという話。

長時間労働で｢管理職に罰金刑｣ドイツの実際（2017/10/15）

規定の時間以内で仕事を終わらせるように努力するのは、労働者の義務。

管理者は、それを実現できるようにサポートするのが義務。

だから、労働者が長時間の労働をするような状況になってしまった場合、

その責任は管理者にあり、罰金が科せられる。しかも、管理職のポケットマネーで。

記事の中に「ドイツは性悪説、日本は性善説」というのが出てくる。

ドイツでは、契約で縛らないと、会社が労働者に対してどんどん要求が増えてくる。この歯止めをかけるのが労働契約書というもので、これが労働者を守る絶対的なものとなっている。

日本では労働契約書なるものを交わすことはほぼない。大前提として、日本は「ルールは守るもの」ということがあり、これにより、労働者にとって何より大事なのは上司との関係になる、ということだ。

労働契約書は、働き方を変えるには大きな力を発揮するだろう。

本気で労働時間を短くしたいと思うのならば、そのくらい日本でもやったほうがよいというのは賛成だ。

でも、ただ契約書を交わせばいいというものではない。

日本に根付いてしまった長時間労働の「癖」は、そう簡単には修正はされない。

ドイツを見本に近づいていくのであれば、Gapが何かを洗い出し、

それを１つずつ潰していく対策とスケジュールが必要だと思う。

壮大なプロジェクトですな。

ワーク・ライフ・バランス or ライフ・ワーク・バランス

働き方を考える際に必ずと言っていいほど出てくる単語「ワーク・ライフ・バランス」。

ワークとライフのバランスを取り、生活にメリハリをつけましょうということだが、

どちらに重きを置くかで、大きな違いが出てくるようだ。

日本とドイツの違いを紹介しているのが以下の記事。

「仕事を先延ばしするスキル」が人生に必要だ（2017/10/11）

日本は「ワーク・ライフ・バランス」で、ワークの方に重きが置かれていて、現状はみんなが経験している通り。

ドイツでは「ライフ・ワーク・バランス」で、ライフの方に重きが置かれていて、経済は世界4位、生産性は日本の1.5倍。

ポイントは時間の使い方と優先順位のつけ方にある。

ドイツでは、とにかく優先順位をしっかりとつけ、緊急で仕事が入った場合、優先順位が低いものを先送りし、その日の作業量を調整する（＝ほぼ一定に保つ）という。

日本は緊急で仕事が入ったらそれをとにかくやり、その日にやると決めたことをその日のうちにこなそうとして、遅くまで仕事をする。

遅くまで仕事しても疲れてしまって効率は上がらず、結局翌日もやるというような悪循環。

その日のやらなければいけないことは何か。

そして、その量はどのくらいでどの程度で完了できるのか。

このあたりを自分自身で管理できているのがドイツ人で、日本人は往々にしてチームリーダーやプロジェクトマネージャといったいわゆる「管理者」にゆだねられていることが多い。

個々人が自分を管理するスキルを身につけ、本当にやらなければいけない仕事は何かを考える癖をつけないといけないと思った。

そして、それは自分だけでなく、周りの人も同じように実践しないとうまく回らない。

その辺をコントロールできると、みんな残業せず、早く帰れるようになるのかもしれない。

目指せ！ライフ・ワーク・バランス！