11gで大きく変わったセキュリティ関連の設定は3つ 1)Auditの監査設定が標準設定されている 2)プロファイルのDEFALUTの設定が強固に 3)パスワードの大文字小文字を区別するようになった 今回はそれぞれの対処方法について記載します。 1)Auditの監査設定が標準設定されている 以下のSQLを実行します。 ========================================================================= SQL> @?\rdbms\admin\undoaud.sql 監査取消しが成功しました。 監査取消しが成功しました。 監査取消しが成功しました。 SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE 2 from DBA_STMT_AUDIT_OPTS; レコードが選択されませんでした。 SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from DBA_PRIV_AUDIT_OPTS; レコードが選択されませんでした。 SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ----------------------- audit_trail string DB ↑audit_trailはDBから変更されません。必要に応じてユーザにて変更。 ========================================================================= 2)プロファイルのDEFALUTの設定が強固に 以下のSQLを実行します。 ========================================================================= SQL> @?\rdbms\admin\undopwd プロファイルが変更されました。 SQL> select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from DBA_PROFILES 2 where RESOURCE_TYPE='PASSWORD' order by RESOURCE_NAME; PROFILE RESOURCE_NAME RESOURCE LIMIT ------- ------------------------- -------- ------------- DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10 DEFAULT PASSWORD_GRACE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_LIFE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_LOCK_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL 7行が選択されました。 ========================================================================= 3)パスワードの大文字小文字を区別するようになった 以下のSQLを実行します。 ========================================================================= SQL> alter system set sec_case_sensitive_logon=FALSE scope=both; システムが変更されました。 SQL> show parameter sec_case_sensitive_logon NAME TYPE VALUE ------------------------ ----------- ------------------------- sec_case_sensitive_logon boolean FALSE ========================================================================= ■まとめ 11gではデフォルトのセキュリティレベルが高くなった。 でも知ってりゃ騒ぐほどのことはない。 なお、やっぱり元の11gのセキュリティレベルに戻したい場合は以下を実行します 1)と2)両方の設定を元に戻します。 SQL> @?\rdbms\admin\secconf.sql ■参考資料 Oracle Databaseセキュリティ・ガイド11g リリース2(11.2) 認証部分 Oracle Databaseセキュリティ・ガイド11g リリース2(11.2) 監査部分 Oracle Databaseアップグレード・ガイド11g リリース2(11.2)
2012年2月11日土曜日
Oracle Database 11g の標準セキュリティ設定について#4
前回はこちら
Oracle Database 11g の標準セキュリティ設定について#3
前回はこちら
11gで大きく変わったセキュリティ関連の設定は3つ 1)Auditの監査設定が標準設定されている 2)プロファイルのDEFALUTの設定が強固に 3)パスワードの大文字小文字を区別するようになった 今回は3)パスワードの大文字小文字を区別するようになった 11gからパスワードの大文字小文字を区別するようになりました。 それにより何が起きるかというと、、 ======================================================= DBのアップグレードは完了したし、 アプリケーションから接続してみるか。 まぁ、アプリケーションは現行のままだから 問題ないだろうけどなっと♪ ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。 って、、ありりりり？ ======================================================= の原因がパスワードの大文字小文字の仕様変更。 ・・・ 11ｇ以前のリリースでは、パスワードは「原則」大文字小文字の区別はされませんでした。 "で囲ってユーザを作ってしまい、小文字として認識されている環境もありましたが、 Oracleはやっちゃ駄目だと言ってきました。(基本は駄目。) でも、このご時世、パスワードは大文字小文字を組み合わせた、 複雑なものがいいよねってことで、 11ｇからパスワードの大文字小文字が区別されるようになりました。 そんなこんなで、既存のプログラムのコネクション時のパスワードが小文字、 ユーザ作成時はパスワードに大文字をしていたとか、またその逆とかだと、 上記のような問題が発生したります。 じゃ、いちからプログラムを見直せってのかよ？！ ってこともあるわけもなくて、 以前のように大文字小文字区別しないようにするには、 以下のパラメータの設定を変更します。 初期化パラメータ:sec_case_sensitive_logon このパラメータは11ｇからの初期化パラメータになります。 デフォルトだと以下のようにTRUEになっているので、 FALSEに変更すれば、大文字小文字区別しないようになります。 動的変更が可能なパラメータなので楽ちんです。 ============================================================== SQL> show parameter sec_case_sensitive_logon NAME TYPE VALUE ------------------------ ----------- ------------------------- sec_case_sensitive_logon boolean TRUE SQL> conn scott/TIGER ERROR: ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。 警告: Oracleにはもう接続されていません。 SQL> conn system/XXXX 接続されました。 SQL> alter system set sec_case_sensitive_logon=FALSE scope=both; システムが変更されました。 SQL> show parameter sec_case_sensitive_logon NAME TYPE VALUE ------------------------ ----------- ------------------------- sec_case_sensitive_logon boolean FALSE SQL> conn scott/TIGER 接続されました。 ============================================================== まとめです、 11gではデフォルト設定のままだと、パスワードの大文字小文字が区別されます。 簡単に戻せるし、特に言うことないですね。 大切なのは、このようなアップグレード時の仕様変更を把握して、 自分のシステムではどのように対処するかということ。 折角、パスワードの大文字小文字を指定出来るようになったのだから、 アップグレードを機にパスワードを強化してみるのもいいですよね。 つづきはこちら
Oracle Database 11g の標準セキュリティ設定について#2
前回はこちら
11gで大きく変わったセキュリティ関連の設定は3つ 1)Auditの監査設定が標準設定されている 2)プロファイルのDEFALUTの設定が強固に 3)パスワードの大文字小文字を区別するようになった 今回は 2)DEFALUTプロファイルのパスワード関連の設定が強固に 11gからDEFALUTプロファイルのパスワード関連のセキュリティ設定が 強固になりました。 それにより何が起きるかというと、、 ======================================================= 本番環境のDBを作成してテストを半年間近くやってきたが、 明日はとうとうリリースだ！ ・・・あれっ！？ アプリケーションにエラーが！！ DBに接続できてない？！ ORA-28000: アカウントがロックされています。 って、、 ======================================================= という話が、実際にあったとかなかったとか。 (場合によってはもっと悲惨。) の原因がDEFALUTプロファイルの仕様変更。 ・・・ プロファイルとはデータベース・リソースの制限の集合。 DEFAULTプロファイルは最初から用意されているプロファイルで、 明示的にプロファイルを設定しなければ、 Oracleアカウントはこのプロファイルの制限を受けます。 で、その中にパスワードに関する制限というか設定があります。 制限には、何日間でパスワード変えなさいとか、 失効したら何日使えないというような、一般的なパスワードの制限があります。 では、プロファイルについて見ていきます。 ■10gのDEFALUTプロファイルのパスワード関連の制限 SQL> select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from DBA_PROFILES where RESOURCE_TYPE='PASSWORD' order by RESOURCE_NAME; PROFILE RESOURCE_NAME RESOURCE LIMIT ------- ------------------------- -------- --------- DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10 DEFAULT PASSWORD_GRACE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_LIFE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_LOCK_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL 7行が選択されました。 ---------------------------------------------------------------------- FAILED_LOGIN_ATTEMPTS :アカウントロックまでのログイン失敗回数 PASSWORD_GRACE_TIME :警告が出され、ログインが許可される猶予期間の日数 PASSWORD_LIFE_TIME :警告が出され、ログインが許可される猶予期間の日数 PASSWORD_LOCK_TIME :ログインが指定された回数連続して失敗した場合、 アカウントがロックされる日数 PASSWORD_REUSE_MAX :現行のパスワードを再利用する前に必要な パスワードの変更回数 PASSWORD_REUSE_TIME :パスワードを再利用できない日数 PASSWORD_VERIFY_FUNCTION:PL/SQLの複雑なパスワード検証スクリプトの CREATE PROFILE文の引数 ---------------------------------------------------------------------- パスワードミスの猶予回数10回以外はフリーダムです。 失効してしまうとユーザがアカウントのアンロックをしないと、 使用できないくらいです。 では、11gは？ ■11gのDEFALUTプロファイルのパスワード関連の制限 SQL> select PROFILE,RESOURCE_NAME,RESOURCE_TYPE,LIMIT from DBA_PROFILES where RESOURCE_TYPE='PASSWORD' order by RESOURCE_NAME; PROFILE RESOURCE_NAME RESOURCE LIMIT -------- -------------------------- -------- --------------------------- DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10 DEFAULT PASSWORD_GRACE_TIME PASSWORD 7 DEFAULT PASSWORD_LIFE_TIME PASSWORD 180 DEFAULT PASSWORD_LOCK_TIME PASSWORD 1 DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL 7行が選択されました。 パスワードミスの猶予回数10回は同じですが、 180日間後にパスワードが自動的に失効するようになっています。 (7日間の猶予を設けてくれていますが。) 187日間を越えて、アカウントがロックされてしまうと、 パスワードが変更されるまでそのアカウントへのログインは許可されません。。。 まとめです、 11gではデフォルト設定のままだと、半年毎にアカウントのパスワード変更が必要 DB設計時には、システム全体のパスワードポリシーやアプリケーションの作りに 合わせて対処を考えておく必要があります。 現実的には、11gの初期DEFAULTプロファイル設定に合わせて、 アプリケーションを作ったり、ポリシーを考えることはほぼありないので、 設定変更やどのようにセキュリティを高めるかを考えることになると思います。 大切なのは、このようなアップグレード時の仕様変更を把握して、 自分のシステムではどのように対処するかということ。 気が付いたらシステムが止まってたは避けたいですよね。 対処はこちら つづきはこちら
Oracle Database 11g の標準セキュリティ設定について#1
最近、DBバージョンアップ＆移行案件のDB設計をやっているので、
ただでさえ多いベーシックネタが更に多くなります。
自分へのメモだけど、誰かの一助になれば。。
(バージョンアップの時にこういうところも気にしているんだとかね。)
さて、今回はOracle Database 11g での標準セキュリティ設定について。
ここ数年の世相を受けてデフォルトがいくつか変わっています。
バージョンアップしてから、「え？そうなの？」というのはお粗末な話。
(割とよく聞くけど。。)
11gで大きく変わったセキュリティ関連の設定は3つ
1)Auditの監査設定が標準設定されている
2)DEFALUTプロファイルのパスワード関連の設定が強固に
3)パスワードの大文字小文字を区別するようになった
では、見ていきます。
■環境
Windows7 64Bit
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64Bit
1)Auditの監査設定がデフォルトで設定されている
気付かない内に監査ログ取られているなんて領域が心配です。
設計時に方針を決めておかないと、SYSTEM表領域が・・・
まずは、Audit関係の初期化パラメータ
SQL> show parameter audit
NAME TYPE VALUE
--------------------- --------- ------------------------------
audit_file_dest string C:\APP\ORACLE\ADMIN\ORCL\ADUMP
audit_sys_operations boolean FALSE
audit_trail string DB
10gのaudit_trailのデフォルトはnoneだったのが、11gではDB※1になっています。
※1.Database Configuration Assistantを使用してデータベースを作成した場合の
デフォルト。それ以外の方法だとnone。
none：標準監査機能は使用禁止
DB:標準監査機能使用可能状態。監査レコードをSYS.AUD$表に書き込みます。
audit_sys_operationsとaudit_file_destは変更無いようです。
まぁ、audit_trailの値がDBになっていたって、監査設定がされていなければ、
なんてことはありません。
監査設定を見ていきます。
■権限監査設定
SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from DBA_PRIV_AUDIT_OPTS;
SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from DBA_PRIV_AUDIT_OPTS
order by PRIVILEGE;
USER_NAME PRIVILEGE SUCCESS FAILURE
--------- ----------------------------- ---------- ---------
ALTER ANY PROCEDURE BY ACCESS BY ACCESS
ALTER ANY TABLE BY ACCESS BY ACCESS
ALTER DATABASE BY ACCESS BY ACCESS
ALTER PROFILE BY ACCESS BY ACCESS
ALTER SYSTEM BY ACCESS BY ACCESS
ALTER USER BY ACCESS BY ACCESS
AUDIT SYSTEM BY ACCESS BY ACCESS
CREATE ANY JOB BY ACCESS BY ACCESS
CREATE ANY LIBRARY BY ACCESS BY ACCESS
CREATE ANY PROCEDURE BY ACCESS BY ACCESS
CREATE ANY TABLE BY ACCESS BY ACCESS
CREATE EXTERNAL JOB BY ACCESS BY ACCESS
CREATE PUBLIC DATABASE LINK BY ACCESS BY ACCESS
CREATE SESSION BY ACCESS BY ACCESS
CREATE USER BY ACCESS BY ACCESS
DROP ANY PROCEDURE BY ACCESS BY ACCESS
DROP ANY TABLE BY ACCESS BY ACCESS
DROP PROFILE BY ACCESS BY ACCESS
DROP USER BY ACCESS BY ACCESS
EXEMPT ACCESS POLICY BY ACCESS BY ACCESS
GRANT ANY OBJECT PRIVILEGE BY ACCESS BY ACCESS
GRANT ANY PRIVILEGE BY ACCESS BY ACCESS
GRANT ANY ROLE BY ACCESS BY ACCESS
23行が選択されました。
がっつり設定されています。
「CREATE SESSION」で成功も失敗もって、、、
環境によってはログが大量に出そうです。。。
■文監査
SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE from DBA_STMT_AUDIT_OPTS
order by AUDIT_OPTION;
USER_NAME AUDIT_OPTION SUCCESS FAILURE
--------- ----------------------------- ---------- ----------
DATABASE LINK BY ACCESS BY ACCESS
PROFILE BY ACCESS BY ACCESS
PUBLIC SYNONYM BY ACCESS BY ACCESS
ROLE BY ACCESS BY ACCESS
SYSTEM AUDIT BY ACCESS BY ACCESS
SYSTEM GRANT BY ACCESS BY ACCESS
※権限監査と重複しているものは記載していません。
文監査も設定されています。
■オブジェクト監査
SQL> select OWNER,OBJECT_NAME,SEL,INS,DEL from DBA_OBJ_AUDIT_OPTS;
レコードが選択されませんでした。
SQL> select * from ALL_DEF_AUDIT_OPTS;
ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ----
-/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
流石にオブジェクト監査は設定されていませんね。
ALL_DEF_AUDIT_OPTSは、オブジェクトが作成されるときに適用される
デフォルトのオブジェクト監査オプションですが、こちらも何もありません。
オブジェクト監査はユーザ次第という感じです。
実際に取得されている監査ログを見てみると、、、
SQL> select USERNAME,ACTION_NAME from DBA_AUDIT_TRAIL
USERNAME ACTION_NAME
--------- ------------------------
DBSNMP SET ROLE
SYSTEM LOGON
SYSTEM LOGON
DBSNMP LOGON
SYSMAN LOGON
SYSMAN LOGON
DBSNMP LOGON
DBSNMP LOGON
DBSNMP LOGON
DBSNMP LOGOFF
DBSNMP LOGOFF
SYSMAN LOGOFF
SYSMAN LOGOFF
・・・
SYSTEM SYSTEM GRANT
SYSTEM CREATE PUBLIC SYNONYM
SYSTEM CREATE PUBLIC SYNONYM
SYSTEM DROP PUBLIC SYNONYM
SYSTEM DROP PUBLIC SYNONYM
SYSTEM GRANT ROLE
うーん。。
1件のデータ量はそんなに多くないんでしょうが、
レコード数は結構なペースで増えていきそう。。
あとあと、気が付いたらSYSTEM表領域がアレレレ？？？
という感じでボディーブローのように効きそうな気も？
まとめですが、DBCAでDBを作成するとデフォルトでログが取られます。
自動的に消してはくれないので、領域を消費し続けます。
ログの生成量は環境によると思いますが、
個人的には気にしなてくもいいかもとは思います。
(コネクションプーリングとかしてれば。)
大切なのは、このようなアップグレード時の仕様変更を把握して、
自分のシステムではどのように対処するかということ。
セキュリティ事故が発生した際に、監査ログが自動で取得されていて良かった。
ということもあるでしょうし、
SYSTEM表領域を自動拡張にしてなかったので、気が付いたら。。。
ということもあるかもしれません。
対処はこちら
つづきはこちら
2012年2月6日月曜日
Oracleのバージョンとconnectロール
基本的なことだけど、一応メモ。
(いまさらか。。)
Connectロールに含まれる権限は10.2.0.1.0以降、縮小されている。
■10.1.0.X.Xより以前のバージョンのConnectロールと含まれる権限
SQL>select GRANTEE,PRIVILEGE from DBA_SYS_PRIVS where GRANTEE='CONNECT'
GRANTEE PRIVILEGE
---------------- ---------------
CONNECT CREATE VIEW
CONNECT CREATE TABLE
CONNECT ALTER SESSION
CONNECT CREATE CLUSTER
CONNECT CREATE SESSION
CONNECT CREATE SYNONYM
CONNECT CREATE SEQUENCE
CONNECT CREATE DATABASE LINK
■10.2.0.X.X以降のバージョンのConnectロールと含まれる権限
SQL>select GRANTEE,PRIVILEGE from DBA_SYS_PRIVS where GRANTEE='CONNECT'
GRANTEE PRIVILEGE
---------------- --------------
CONNECT CREATE SESSION
以前は色々作れる権限が入ってたのに、接続できるだけになっちゃったんですね～
昔の感覚で適当にConnectロール振っておけばいんじゃね？
とかでやっちゃうとビックリします。
ちなみに、同じ感覚で付与してたRESOURCEはというと・・・
■10.2.0.X.X以降のバージョンのConnectロールと含まれる権限
SQL> select GRANTEE,PRIVILEGE from dba_sys_privs where GRANTEE='RESOURCE' order by PRIVILEGE;
GRANTEE PRIVILEGE
----------------- -------------------
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE
10.2.0.1.0以前と変更はなし。
RESOURCEロールだけじゃ、VIEWは作れません。。
ちゃんとユーザロール作るか、必要な権限のみを適切に付与しろ。
というOracle社のメッセージが見えますね。
(実際にマニュアル内で、「CONNECTおよびRESOURCEのロールはともにOracleの
将来のバージョンで非推奨になります」と言っています。)
さて、もうひとつの有名なロールといえば、DBA。
なんでもできちゃうロール。
説明するまでもないですし、健在です。
時たま、アプリケーションユーザや、
全部のユーザにこのロールが付与されている環境があってびっくりしたり。。。
バージョンアップや移行のタイミングで合わせて見直したいですね。
「Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)から
新しいOracle Database 11gリリースにアップグレードすると、
CONNECTロールに含まれる権限はCREATE SESSION権限のみになります。
以前のリリースでCONNECTロールに付与された他の権限は、
アップグレード時に取り消されます。」
出典：Oracle® Databaseアップグレード・ガイド 11g リリース2(11.2)
気を付けなくちゃですね。
(いまさらか。。)
Connectロールに含まれる権限は10.2.0.1.0以降、縮小されている。
■10.1.0.X.Xより以前のバージョンのConnectロールと含まれる権限
SQL>select GRANTEE,PRIVILEGE from DBA_SYS_PRIVS where GRANTEE='CONNECT'
GRANTEE PRIVILEGE
---------------- ---------------
CONNECT CREATE VIEW
CONNECT CREATE TABLE
CONNECT ALTER SESSION
CONNECT CREATE CLUSTER
CONNECT CREATE SESSION
CONNECT CREATE SYNONYM
CONNECT CREATE SEQUENCE
CONNECT CREATE DATABASE LINK
■10.2.0.X.X以降のバージョンのConnectロールと含まれる権限
SQL>select GRANTEE,PRIVILEGE from DBA_SYS_PRIVS where GRANTEE='CONNECT'
GRANTEE PRIVILEGE
---------------- --------------
CONNECT CREATE SESSION
以前は色々作れる権限が入ってたのに、接続できるだけになっちゃったんですね～
昔の感覚で適当にConnectロール振っておけばいんじゃね？
とかでやっちゃうとビックリします。
ちなみに、同じ感覚で付与してたRESOURCEはというと・・・
■10.2.0.X.X以降のバージョンのConnectロールと含まれる権限
SQL> select GRANTEE,PRIVILEGE from dba_sys_privs where GRANTEE='RESOURCE' order by PRIVILEGE;
GRANTEE PRIVILEGE
----------------- -------------------
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE
10.2.0.1.0以前と変更はなし。
RESOURCEロールだけじゃ、VIEWは作れません。。
ちゃんとユーザロール作るか、必要な権限のみを適切に付与しろ。
というOracle社のメッセージが見えますね。
(実際にマニュアル内で、「CONNECTおよびRESOURCEのロールはともにOracleの
将来のバージョンで非推奨になります」と言っています。)
さて、もうひとつの有名なロールといえば、DBA。
なんでもできちゃうロール。
説明するまでもないですし、健在です。
時たま、アプリケーションユーザや、
全部のユーザにこのロールが付与されている環境があってびっくりしたり。。。
バージョンアップや移行のタイミングで合わせて見直したいですね。
「Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)から
新しいOracle Database 11gリリースにアップグレードすると、
CONNECTロールに含まれる権限はCREATE SESSION権限のみになります。
以前のリリースでCONNECTロールに付与された他の権限は、
アップグレード時に取り消されます。」
出典：Oracle® Databaseアップグレード・ガイド 11g リリース2(11.2)
気を付けなくちゃですね。
2011年11月28日月曜日
[ASMLIB]EMC PowerPathの場合のお作法_6
前回：[ASMLIB]EMC PowerPathの場合のお作法_5
今回はまとめや参考情報について
1.EMC PowerPath環境でのASMLIBの設定方法
通常のoracleasmコマンドを使用するとエラーになったりするので、
emcpowerの時はasmtoolコマンドを使用する。
投稿はこちら
2.マルチパスと(マルチデバイスパス)とは
疑似デバイスとも言われるが、LU(ディスク)へのパスが複数存在しており、
冗長化やI/Oの効率化を図ること出来る仕組み。
特徴としては、1つのLUに対してパス+マルチパス分の複数デバイスが存在するように、
OS上からは見える。/dev/配下など
投稿はこちら
3.マルチパス環境におけるASMLIBのお作法
/etc/sysconfig/oracleasmのORACLEASM_SCANORDERと
(または)ORACLEASM_SCANEXCLUDEを設定して、
誤ってシングルパスを読み込まないように、マルチパス優先して読み込ませたり、
シングルパスを読み込ませない設定を行う。
投稿はこちら
4.その他参考情報
<参考資料>
・Oracle Databaseストレージ管理者ガイド 11gリリース1（11.1）マニュアル
・Dell™ PowerEdge™ Systems Oracle® Database on Enterprise Linux® x86_64
Troubleshooting Guide Version 4.3 (p14ページ)
・Dell PowerEdge Systems Oracle 11g R2 Database on Enterprise Linux x86_64
Getting Started Guide
<参考情報>
My Oracle Support情報
・ASMLib: oracleasm createdisk command fails:
Device '/dev/emcpowera1 is not a partition [Failed] [ID 469163.1]
・Collecting The Required Information For Support To Troubleshot ASM/ASMLIB Issues.
[ID 869526.1]
・Troubleshooting a multi-node ASMLib installation [ID 811457.1]
今回はまとめや参考情報について
1.EMC PowerPath環境でのASMLIBの設定方法
通常のoracleasmコマンドを使用するとエラーになったりするので、
emcpowerの時はasmtoolコマンドを使用する。
投稿はこちら
2.マルチパスと(マルチデバイスパス)とは
疑似デバイスとも言われるが、LU(ディスク)へのパスが複数存在しており、
冗長化やI/Oの効率化を図ること出来る仕組み。
特徴としては、1つのLUに対してパス+マルチパス分の複数デバイスが存在するように、
OS上からは見える。/dev/配下など
投稿はこちら
3.マルチパス環境におけるASMLIBのお作法
/etc/sysconfig/oracleasmのORACLEASM_SCANORDERと
(または)ORACLEASM_SCANEXCLUDEを設定して、
誤ってシングルパスを読み込まないように、マルチパス優先して読み込ませたり、
シングルパスを読み込ませない設定を行う。
投稿はこちら
4.その他参考情報
<参考資料>
・Oracle Databaseストレージ管理者ガイド 11gリリース1（11.1）マニュアル
・Dell™ PowerEdge™ Systems Oracle® Database on Enterprise Linux® x86_64
Troubleshooting Guide Version 4.3 (p14ページ)
・Dell PowerEdge Systems Oracle 11g R2 Database on Enterprise Linux x86_64
Getting Started Guide
<参考情報>
My Oracle Support情報
・ASMLib: oracleasm createdisk command fails:
Device '/dev/emcpowera1 is not a partition [Failed] [ID 469163.1]
・Collecting The Required Information For Support To Troubleshot ASM/ASMLIB Issues.
[ID 869526.1]
・Troubleshooting a multi-node ASMLib installation [ID 811457.1]
[ASMLIB]EMC PowerPathの場合のお作法_5
前回：[ASMLIB]EMC PowerPathの場合のお作法_4
前回は、はまらないためには？
って話を書きました。
今回はその他色々を見ていきます。
1.マルチパスと/proc/partitions
/proc/partitionsの内容を見るとなんとなく、
マルチパスとそれを構成しているパーティション、
シングルデバイスパスの関係が見えてきます。
# cat /proc/partitions
major minor #blocks name
8 0 292421632 sda
8 1 104391 sda1
8 2 100663290 sda2
8 3 191647417 sda3
8 32 1059840 sdc --emocpoweraを構成するシングルパス1●
8 16 10598400 sdb --emocpowerbを構成するシングルパス1▲
8 48 1059840 sdd --emocpoweraを構成するシングルパス2●
8 64 1048780804 sde --emocpowerdを構成するシングルパス1★
8 80 1048780804 sdf --emocpowerdを構成するシングルパス2★
8 96 10598400 sdg --emocpowerbを構成するシングルパス2▲
8 112 52439040 sdh --emocpowercを構成するシングルパス1■
8 128 52439040 sdi --emocpowercを構成するシングルパス2■
253 0 1059840 emcpowera --●で構成されるマルチデバイスパス
253 1 10598400 emcpowerb --▲で構成されるマルチデバイスパス
253 2 52439040 emcpowerc --■で構成されるマルチデバイスパス
253 3 1048780804 emcpowerd --★で構成されるマルチデバイスパス
sdc,sdb,emcpoweraは同じブロック数です。
なんとなく想像できますが、実際のLUだとかパーティションは1つですが、
同一のパーティションに対して2つのパスがあるので
sdc、sdbという形でデバイス(orパーティション)が見えており、
その二つのパスを束ねたマルチパスemcpoweraも見えています。
ls -l /dev/*で確認すると/dev/sdbcや/dev/emcpowera等が確認できます。
また、LU(ディスク)までの経路でポートなどが冗長化されている場合は、
4つ等に見える場合にもあります。
2./proc/partitionsと/dev/oracleasm/disks
/dev/oracleasm/disks配下にはASMLIBでラベルマーキングした、
ラベル名のブロックデバイスが存在します。
# ls -l /dev/oracleasm/disks
合計 0
brw-rw---- 1 grid asmadmin 253, 0 11月 28 02:00 CRS
brw-rw---- 1 grid asmadmin 253, 1 11月 28 02:00 DG1
brw-rw---- 1 grid asmadmin 253, 2 11月 28 02:00 DG2
brw-rw---- 1 grid asmadmin 253, 3 11月 28 02:00 DG3
真ん中のの数字は/proc/partitionsにも似たようなのがありました。
デバイス番号 253,0 = CRS用ディスク(ラベル) = emcpoweraディスク(orデバイス)
というの関係が読み取れます。
ディスクスキャン時に誤ってシングルデバイスパスを読み込んでしまうと、
この部分の関係が崩れることによってトラブルが発生します。
また、DELLさんのEqualLogicの場合は、/dev/mapper配下のブロックデバイスを
ORACLEASM_SCANORDERに指定しますが、
この場合もデバイス番号から、
/dev/mapper/配下のブロックデバイスとマルチデバイスパス、
ASMディスクの関係を読み取ることが出来ます。
# cat /proc/partitions grep dm
253 0 1059840 dm-0 --マルチデバイスパス
253 1 10598400 dm-1 --マルチデバイスパス
253 2 52439040 dm-2 --マルチデバイスパス
253 3 1048780804 dm-3 --マルチデバイスパス
# ls -l /dev/mapper/db*
合計 0
brw-rw---- 1 root disk 253, 0 11月 28 02:00 db-crs
brw-rw---- 1 root disk 253, 3 11月 28 02:00 db-data
brw-rw---- 1 root disk 253, 1 11月 28 02:00 db-redo
brw-rw---- 1 root disk 253, 2 11月 28 02:00 db-arc
# ls -l /dev/oracleasm/disks
合計 0
brw-rw---- 1 grid asmadmin 253, 0 11月 28 02:00 CRS
brw-rw---- 1 grid asmadmin 253, 1 11月 28 02:00 DG1
brw-rw---- 1 grid asmadmin 253, 2 11月 28 02:00 DG2
brw-rw---- 1 grid asmadmin 253, 3 11月 28 02:00 DG3
3.ASMLIBによるディスクスキャン時のログファイル
/var/log/oracleasmファイルから、
ASMLIBによるディスクスキャン時のログを見ることが出来ます。
以上、取りとめなく書きましたが、次回はまとめ
前回は、はまらないためには？
って話を書きました。
今回はその他色々を見ていきます。
1.マルチパスと/proc/partitions
/proc/partitionsの内容を見るとなんとなく、
マルチパスとそれを構成しているパーティション、
シングルデバイスパスの関係が見えてきます。
# cat /proc/partitions
major minor #blocks name
8 0 292421632 sda
8 1 104391 sda1
8 2 100663290 sda2
8 3 191647417 sda3
8 32 1059840 sdc --emocpoweraを構成するシングルパス1●
8 16 10598400 sdb --emocpowerbを構成するシングルパス1▲
8 48 1059840 sdd --emocpoweraを構成するシングルパス2●
8 64 1048780804 sde --emocpowerdを構成するシングルパス1★
8 80 1048780804 sdf --emocpowerdを構成するシングルパス2★
8 96 10598400 sdg --emocpowerbを構成するシングルパス2▲
8 112 52439040 sdh --emocpowercを構成するシングルパス1■
8 128 52439040 sdi --emocpowercを構成するシングルパス2■
253 0 1059840 emcpowera --●で構成されるマルチデバイスパス
253 1 10598400 emcpowerb --▲で構成されるマルチデバイスパス
253 2 52439040 emcpowerc --■で構成されるマルチデバイスパス
253 3 1048780804 emcpowerd --★で構成されるマルチデバイスパス
sdc,sdb,emcpoweraは同じブロック数です。
なんとなく想像できますが、実際のLUだとかパーティションは1つですが、
同一のパーティションに対して2つのパスがあるので
sdc、sdbという形でデバイス(orパーティション)が見えており、
その二つのパスを束ねたマルチパスemcpoweraも見えています。
ls -l /dev/*で確認すると/dev/sdbcや/dev/emcpowera等が確認できます。
また、LU(ディスク)までの経路でポートなどが冗長化されている場合は、
4つ等に見える場合にもあります。
2./proc/partitionsと/dev/oracleasm/disks
/dev/oracleasm/disks配下にはASMLIBでラベルマーキングした、
ラベル名のブロックデバイスが存在します。
# ls -l /dev/oracleasm/disks
合計 0
brw-rw---- 1 grid asmadmin 253, 0 11月 28 02:00 CRS
brw-rw---- 1 grid asmadmin 253, 1 11月 28 02:00 DG1
brw-rw---- 1 grid asmadmin 253, 2 11月 28 02:00 DG2
brw-rw---- 1 grid asmadmin 253, 3 11月 28 02:00 DG3
真ん中のの数字は/proc/partitionsにも似たようなのがありました。
デバイス番号 253,0 = CRS用ディスク(ラベル) = emcpoweraディスク(orデバイス)
というの関係が読み取れます。
ディスクスキャン時に誤ってシングルデバイスパスを読み込んでしまうと、
この部分の関係が崩れることによってトラブルが発生します。
また、DELLさんのEqualLogicの場合は、/dev/mapper配下のブロックデバイスを
ORACLEASM_SCANORDERに指定しますが、
この場合もデバイス番号から、
/dev/mapper/配下のブロックデバイスとマルチデバイスパス、
ASMディスクの関係を読み取ることが出来ます。
# cat /proc/partitions grep dm
253 0 1059840 dm-0 --マルチデバイスパス
253 1 10598400 dm-1 --マルチデバイスパス
253 2 52439040 dm-2 --マルチデバイスパス
253 3 1048780804 dm-3 --マルチデバイスパス
# ls -l /dev/mapper/db*
合計 0
brw-rw---- 1 root disk 253, 0 11月 28 02:00 db-crs
brw-rw---- 1 root disk 253, 3 11月 28 02:00 db-data
brw-rw---- 1 root disk 253, 1 11月 28 02:00 db-redo
brw-rw---- 1 root disk 253, 2 11月 28 02:00 db-arc
# ls -l /dev/oracleasm/disks
合計 0
brw-rw---- 1 grid asmadmin 253, 0 11月 28 02:00 CRS
brw-rw---- 1 grid asmadmin 253, 1 11月 28 02:00 DG1
brw-rw---- 1 grid asmadmin 253, 2 11月 28 02:00 DG2
brw-rw---- 1 grid asmadmin 253, 3 11月 28 02:00 DG3
3.ASMLIBによるディスクスキャン時のログファイル
/var/log/oracleasmファイルから、
ASMLIBによるディスクスキャン時のログを見ることが出来ます。
以上、取りとめなく書きましたが、次回はまとめ
登録:
投稿 (Atom)