How do I use chkconfig to enable a script for a service that accepts start, stop, and status options?
Resolution:Not all scripts with start/stop/status options are manageable by chkconfig. The script must adhere to the following requirements:
The first line indicates what shell is used to run the script
The second line is just a blank comment.
The third line should be a comment that indicates which runlevels should the service be started by default as well as the start and stop priority levels.
The fourth line should be a comment that contains the description for the service. The description may extend up to several (commented) lines as necessary. Use the backslash character (\) if the comment extends to several lines.
(The script must be in the /etc/init.d/ directory)
Below is an example for the Samba script /etc/init.d/smb:
#!/bin/sh
#
# chkconfig: - 91 35
# description: Starts and stops the Samba smbd and nmbd daemons \
# used to provide SMB network services.
The start/stop priority levels (91 and 35, respectively, shown above) are important for services that depend on other services. For example, it is required that portmap is started before nfs. If the script does not depend on other services, you may choose to execute it after the system is completely up and running. The easiest way is to call it from /etc/rc.d/rc.local. The command to do that is
echo /etc/init.d/yourscript >> /etc/rc.d/rc.localMake sure that the script is executable. Issue the command:
chmod 0755 /etc/init.d/yourscript
Friday, June 29, 2007
Thursday, June 28, 2007
[Linux] dbshut スクリプトが動作しない
[概要]
Linux 環境でシステム停止・起動時に、自動的に Oracle データベースを
起動・停止できるように dbstart および dbshut スクリプトを使用しています。
システム再起動時に dbshut スクリプトが動作せず、自動的にデータベースが
停止しません。
[対象リリース]
すべて
[対象プラットフォーム]
Linux
[詳細]
下記の点を確認してください
1. dbora が実行権限を持っているかどうか
例：chmod +x /etc/rc.d/init.d/dbora
2. /etc/rc.d/rcX.d から リンクが正常に張られているかどうか
例：/etc/rc.d/rc6.d/K01dbora -> ../init.d/dbora ( multi user mode)
/etc/rc.d/rc0.d/K01dbora -> ../init.d/dbora (single user mode)
3. 手動でスクリプトを実行してデータベースの停止が可能であるか
例：/etc/rc.d/rc6.d/K01dbora stop
4. /etc/rc.d/init.d/dbora に touch /var/lock/subsys/dbora という
一行が含まれているかどうか
'inittab' から呼び出されるスクリプトは '/var/lock/subsys' 以下の
lock file の存在を探します。このファイルが存在していないと stop command
が実行されません。下記のような形で touch /var/lock/subsys/dbora という
一行を付け加える必要があります。
[変更前]
- 9i 用 dbora
#Start the database
su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
- 10g 用 dbora
#
if [ ! "$2" = "ORA_DB" ] ; then
if [ "$PLATFORM" = "HP-UX" ] ; then
remsh $HOST -l $ORACLE -n "$0 $1 ORA_DB"
exit
else
rsh $HOST -l $ORACLE $0 $1 ORA_DB
exit
fi
fi
#
[変更後]
- 9i 用 dbora
#Start the database
touch /var/lock/subsys/dbora
su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
touch /var/lock/subsys/dbora が必要になるのは、
#Start the database のときだけです。stop には必要ありません。
- 10g 用 dbora
#
if [ ! "$2" = "ORA_DB" ] ; then
if [ "$PLATFORM" = "HP-UX" ] ; then
remsh $HOST -l $ORACLE -n "$0 $1 ORA_DB"
exit
else
touch /var/lock/subsys/dbora <===(*)
rsh $HOST -l $ORACLE $0 $1 ORA_DB
exit
fi
fi
#
一度 dbora が実行されると、作成された '/var/lock/subsys/dbora' は
OS 側で OS 停止時や再起動時に削除されます。
[参照情報]
Oracle9i for UNIX Systems インストレーション・ガイド リリース2（9.2.0.1.0）部品番号: J06455-01
p4-5 データベースの起動および停止の自動化
Oracle Database 管理者リファレンス 10g リリース1（10.1）for UNIX Systems 部品番号: B13705-04
p2-10 その他のオペレーティング・システムにおけるデータベースの起動と停止の自動化
[更新履歴]
2005/06/17 10g 用 dbora の記述を追加
2004/05/13 本文書作成
Linux 環境でシステム停止・起動時に、自動的に Oracle データベースを
起動・停止できるように dbstart および dbshut スクリプトを使用しています。
システム再起動時に dbshut スクリプトが動作せず、自動的にデータベースが
停止しません。
[対象リリース]
すべて
[対象プラットフォーム]
Linux
[詳細]
下記の点を確認してください
1. dbora が実行権限を持っているかどうか
例：chmod +x /etc/rc.d/init.d/dbora
2. /etc/rc.d/rcX.d から リンクが正常に張られているかどうか
例：/etc/rc.d/rc6.d/K01dbora -> ../init.d/dbora ( multi user mode)
/etc/rc.d/rc0.d/K01dbora -> ../init.d/dbora (single user mode)
3. 手動でスクリプトを実行してデータベースの停止が可能であるか
例：/etc/rc.d/rc6.d/K01dbora stop
4. /etc/rc.d/init.d/dbora に touch /var/lock/subsys/dbora という
一行が含まれているかどうか
'inittab' から呼び出されるスクリプトは '/var/lock/subsys' 以下の
lock file の存在を探します。このファイルが存在していないと stop command
が実行されません。下記のような形で touch /var/lock/subsys/dbora という
一行を付け加える必要があります。
[変更前]
- 9i 用 dbora
#Start the database
su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
- 10g 用 dbora
#
if [ ! "$2" = "ORA_DB" ] ; then
if [ "$PLATFORM" = "HP-UX" ] ; then
remsh $HOST -l $ORACLE -n "$0 $1 ORA_DB"
exit
else
rsh $HOST -l $ORACLE $0 $1 ORA_DB
exit
fi
fi
#
[変更後]
- 9i 用 dbora
#Start the database
touch /var/lock/subsys/dbora
su - $ORA_OWNER -c $ORA_HOME/bin/dbstart
touch /var/lock/subsys/dbora が必要になるのは、
#Start the database のときだけです。stop には必要ありません。
- 10g 用 dbora
#
if [ ! "$2" = "ORA_DB" ] ; then
if [ "$PLATFORM" = "HP-UX" ] ; then
remsh $HOST -l $ORACLE -n "$0 $1 ORA_DB"
exit
else
touch /var/lock/subsys/dbora <===(*)
rsh $HOST -l $ORACLE $0 $1 ORA_DB
exit
fi
fi
#
一度 dbora が実行されると、作成された '/var/lock/subsys/dbora' は
OS 側で OS 停止時や再起動時に削除されます。
[参照情報]
Oracle9i for UNIX Systems インストレーション・ガイド リリース2（9.2.0.1.0）部品番号: J06455-01
p4-5 データベースの起動および停止の自動化
Oracle Database 管理者リファレンス 10g リリース1（10.1）for UNIX Systems 部品番号: B13705-04
p2-10 その他のオペレーティング・システムにおけるデータベースの起動と停止の自動化
[更新履歴]
2005/06/17 10g 用 dbora の記述を追加
2004/05/13 本文書作成
How do I rsh, rlogin, or rexec as root?
How do I rsh, rlogin, or rexec as root?
Resolution:For security reasons, rexec, rsh, and rlogin are not enabled by default in Red Hat Enterprise Linux, you should use the OpenSSH suite of tools instead. Information concerning the OpenSSH tools can be found in the Red Hat Enterprise Linux 4: Reference Guide available at: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/ch-ssh.html.
If you must use rexec, rsh, and rlogin, and if you need to use them as root, you will need to make a few modifications to the /etc/securetty file and also need a .rhost file in root's home directory. All three of these tools have PAM configuration files that require the pam_securetty.so PAM module, so you must edit /etc/securetty to allow root access.
Before you can log in as root using these tools, you first have to have them properly set up. First, install the rsh-server package using up2date rsh-server.
Restart xinetd with /sbin/service xinetd restart to activate the changes. At this point, all users except root will be able to use rexec, rsh, and rlogin.
To allow root to use these tools, add the names of the tools you wish to allow to the /etc/securetty. If you wanted to enable root login using rexec, rsh, and rlogin, add the following lines to the /etc/securetty file:
rexec
rsh
rlogin
You also must have a .rhosts file in root's home directory to allow a user to log on as root. This file contains the host or a range of hosts, and the user on that host/hosts that can log in as root.
192.168.1.13 bob
Resolution:For security reasons, rexec, rsh, and rlogin are not enabled by default in Red Hat Enterprise Linux, you should use the OpenSSH suite of tools instead. Information concerning the OpenSSH tools can be found in the Red Hat Enterprise Linux 4: Reference Guide available at: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/ch-ssh.html.
If you must use rexec, rsh, and rlogin, and if you need to use them as root, you will need to make a few modifications to the /etc/securetty file and also need a .rhost file in root's home directory. All three of these tools have PAM configuration files that require the pam_securetty.so PAM module, so you must edit /etc/securetty to allow root access.
Before you can log in as root using these tools, you first have to have them properly set up. First, install the rsh-server package using up2date rsh-server.
Restart xinetd with /sbin/service xinetd restart to activate the changes. At this point, all users except root will be able to use rexec, rsh, and rlogin.
To allow root to use these tools, add the names of the tools you wish to allow to the /etc/securetty. If you wanted to enable root login using rexec, rsh, and rlogin, add the following lines to the /etc/securetty file:
rexec
rsh
rlogin
You also must have a .rhosts file in root's home directory to allow a user to log on as root. This file contains the host or a range of hosts, and the user on that host/hosts that can log in as root.
192.168.1.13 bob
How do I change the color of my shell prompt?
How do I change the color of my shell prompt?
Resolution:Since many Linux commands, programs, and utilities use a shell interface, it is some times helpful to customize the command prompt to distinguish it from the output of these commands, programs, and utilities. In Red Hat Enterprise Linux the default shell is the bash shell. The following information is for the bash shell but may work with other shells as well.
The prompt is stored in the $PS1 environmental variable. It can be displayed by typing the following:
# echo $PS1
[\u@\h \W]\$
By default the command prompt is set to: [\u@\h \W]\$ These special characters display things like hostname and current directory. For more details see the PROMPTING section in the bash man pages.
To add colors to the prompt change the prompt to '\e[x;ym $PS1 \e[m' where:
\e[ is the symbol to start and ascii code and m stops it
x;y is what colors to use, change the x and y values to use different colors
$PS1 is your prompt you can use the default shown above or your own
\e[m is another ascii break and close to tell it to stop using the new color
To set the new prompt use the command:
# export PS1='\e[0;33m[\u@\h \W]\$ \e[m '
This example sets the prompt to asci color 0;33 which is a orange color. See the below table for additional colors:
Black 0;30 White 1;37 Blue 0;34 Light Blue 1;34 Green 0;32 Light Green 1;32 Cyan 0;36 Light Cyan 1;36 Red 0;31 Light Red 1;31 Purple 0;35 Pink 1;35 Brown 0;33 Yellow 1;33 Light Gray 0;37 Dark Gray 1;30
However, this will only set it temporarily. To have it set every time you log in, add it to to the bottom of your .bachrc file in your home directory. See the below example of /home/$username/.bashrc
# .bashrc
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
export PS1='\e[0;33m[\u@\h \W]\$ \e[m '
Resolution:Since many Linux commands, programs, and utilities use a shell interface, it is some times helpful to customize the command prompt to distinguish it from the output of these commands, programs, and utilities. In Red Hat Enterprise Linux the default shell is the bash shell. The following information is for the bash shell but may work with other shells as well.
The prompt is stored in the $PS1 environmental variable. It can be displayed by typing the following:
# echo $PS1
[\u@\h \W]\$
By default the command prompt is set to: [\u@\h \W]\$ These special characters display things like hostname and current directory. For more details see the PROMPTING section in the bash man pages.
To add colors to the prompt change the prompt to '\e[x;ym $PS1 \e[m' where:
\e[ is the symbol to start and ascii code and m stops it
x;y is what colors to use, change the x and y values to use different colors
$PS1 is your prompt you can use the default shown above or your own
\e[m is another ascii break and close to tell it to stop using the new color
To set the new prompt use the command:
# export PS1='\e[0;33m[\u@\h \W]\$ \e[m '
This example sets the prompt to asci color 0;33 which is a orange color. See the below table for additional colors:
Black 0;30 White 1;37 Blue 0;34 Light Blue 1;34 Green 0;32 Light Green 1;32 Cyan 0;36 Light Cyan 1;36 Red 0;31 Light Red 1;31 Purple 0;35 Pink 1;35 Brown 0;33 Yellow 1;33 Light Gray 0;37 Dark Gray 1;30
However, this will only set it temporarily. To have it set every time you log in, add it to to the bottom of your .bachrc file in your home directory. See the below example of /home/$username/.bashrc
# .bashrc
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
export PS1='\e[0;33m[\u@\h \W]\$ \e[m '
How do I change the color of text in a terminal or virtual console?
Issue:
How do I change the color of text in a terminal or virtual console? Resolution:Release Found: Red Hat Enterprise Linux
Problem:
You need to display text in a terminal or virtual console but would like it to display in a pre-determined color.
Solution:
To change the color in or within a string of characters, prefix one of the codes from the table below with the escape character (ASCII code- 27 decimal, 0x1b hex, or 033 octal), followed by a [ character (ASCII code- 91 decimal, 0x5b hex, or 133 octal), and follow the code with the letter m (ASCII code- 109 decimal, 0x6d hex, or 155 octal). If you specify only escape, bracket and the letter m, without any codes inbetween, then the text properties will revert back to their default
For example, try typing the following at a shell prompt:
$ echo -e "\033\1331;33;44\155 This is yellow on blue text\033\133\155"
1;33;44 means a combination from below
How do I change the color of text in a terminal or virtual console? Resolution:Release Found: Red Hat Enterprise Linux
Problem:
You need to display text in a terminal or virtual console but would like it to display in a pre-determined color.
Solution:
To change the color in or within a string of characters, prefix one of the codes from the table below with the escape character (ASCII code- 27 decimal, 0x1b hex, or 033 octal), followed by a [ character (ASCII code- 91 decimal, 0x5b hex, or 133 octal), and follow the code with the letter m (ASCII code- 109 decimal, 0x6d hex, or 155 octal). If you specify only escape, bracket and the letter m, without any codes inbetween, then the text properties will revert back to their default
For example, try typing the following at a shell prompt:
$ echo -e "\033\1331;33;44\155 This is yellow on blue text\033\133\155"
1;33;44 means a combination from below
Wednesday, June 27, 2007
oem/isqlplus中button乱码（Patch 3639533）
注意，下文中删除cache文件只是针对oem；isqlplus的cache文件为$ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/isqlplus/isqlplus/cabo/images/cache/<你的语言e.g "zhs" or "ja">/*
文書番号 100150 最終更新日 2006-02-22 公開区分 契約顧客のみ
製品名(バージョン)[コンポーネント] Application Server 全般(インストール,PSR等) (9.0.4 - 10.1.2) [Release Notes]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 91571
概要 Application Server Contorol で「ログイン」「更新」「停止」「実行」等のボタン部分が文字化けする
内容:
[概要]
Application Server Contorol で「ログイン」「更新」「停止」「実行」等の
ボタン部分が文字化けします。
[対象リリース]
Oracle Application Server 10g Release2(10.1.2)
Oracle Application Server 10g (9.0.4)
[対象プラットフォーム]
すべてのプラットフォーム
[詳細]
Application Server Contorol に初回アクセスを行った際に、画面で使用する
ボタンが生成されます。その際に、日本語のフォントファイルにアクセスでき
ない場合、作成されるボタンが文字化けします。
Application Server Contorol は下記の順序で、フォントファイルを探します。
1. 日本語でのインストール時に作成される ALBANWTJ.TTF
存在する場所:
~~~~~~~~~~~~~
UnixおよびLinuxプラットフォーム: $ORACLE_HOME/jdk/jre/lib/fonts
Microsoft Windowsプラットフォーム: %ORACLE_HOME%\jdk\jre\lib\fonts
2. OS に存在するフォントファイル
例: HG-GothicB.ttf,HeiseiMin-W3H.ttf など
存在する場所:
~~~~~~~~~~~~~
OS の環境に依存します。
1と2のいずれにもアクセスすることができない場合、生成されるボタンが文字
化けします。
インストール時の言語に日本語が選択されていない場合、ALBANWTJ.TTF が存在
しないため、文字化けが発生する可能性があります。
[FAQ]
Q1.文字化けが発生した場合の対応策を教えてください。
A1.下記の手順で文字化けに対応することが可能です。
1. 正常な環境の ALBANWTJ.TTF を、問題が発生している環境の以下のパスに
コピーします。 正常にインストールした環境がない場合は、別の環境に
インストールし、その環境よりファイルをコピーして下さい。
UnixおよびLinuxプラットフォーム: $ORACLE_HOME/jdk/jre/lib/fonts
Microsoft Windowsプラットフォーム: %ORACLE_HOME%\jdk\jre\lib\fonts
2. Application Server Contorol を停止します。
UnixおよびLinuxプラットフォーム :
$ORACLE_HOME/bin/emctl stop iasconsole
Microsoft Windowsプラットフォーム:
%ORACLE_HOME%\bin\emctl stop iasconsole
3. 以下のディレクトリのファイルを削除します。
UnixおよびLinuxプラットフォーム :
$ORACLE_HOME/sysman/webapps/emd/cabo/images/cache/ja
Microsoft Windowsプラットフォーム:
%ORACLE_HOME%\sysman\webapps\emd\cabo\images\cache\ja
4. Application Server Contorol を起動します。
UnixおよびLinuxプラットフォーム :
$ORACLE_HOME/bin/emctl start iasconsole
Microsoft Windowsプラットフォーム:
%ORACLE_HOME%\bin\emctl start iasconsole
[参照情報]
KROWN:91571
「Enterprise Manager Database Contorol で「ログイン」「更新」「停止」
「実行」等のボタン部分だけが文字化けする」
[更新履歴]
2006/01/10 本文書を修正・公開区分を変更
2005/05/12 本文書を公開
2005/05/11 本文書を作成
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
[起こりうる現象]
Enterprise Manager Database Contorol で「ログイン」「更新」「停止」
「実行」等のボタン部分だけが文字化けします。
[対象リリース]
問題が発生するリリース ：Oracle Enterprise Manager 10g Database Control (10.1.0)
問題を修正したリリース ：なし
問題を修正予定のリリース：なし
問題を修正したPSR ：なし
問題を修正予定のPSR ：なし
[対象プラットフォーム]
すべてのプラットフォーム
[起こりうる条件]
インストール時の言語に日本語が選択されていない場合に発生します。
[原因]
インストール時の言語に日本語が選択されていないことが原因です。
本件に該当しているかどうかは、$ORACLE_HOME/jdk/jre/lib/fonts/ に
ALBANWTJ.TTF というファイルが存在するかどうかで確認可能です。
存在しない場合は本件に該当しています。
[回避策]
以下の方法で回避可能です。
1. 正常な環境の、$ORACLE_HOME/jdk/jre/lib/fonts/ALBANWTJ.TTF を
問題が発生している環境の $ORACLE_HOME/jdk/jre/lib/fonts/ にコピー
します。 正常にインストールした環境がない場合は、別の環境にインス
トールしその環境よりファイルをコピーする方法でご対応下さい。
2. Enterprise Manager を停止します。
emctl stop dbconsole
3. $ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/cabo/images/cache/ja
ディレクトリのファイルを削除します。
4. Enterprise Manager を再起動します。
emctl start dbconsole
[補足]
プラットフォームによっては、$ORACLE_HOME/jdk/jre/lib/fonts/ALBANWTJ.TTF
が 0バイトとしてインストールされる問題が確認できております。
本問題が確認できているプラットフォームは以下の通りとなります。
- HP-UX Itanium
- IBM zSeries Based Linux
- Solaris (X86)
本問題につきましては、Bug:4044060 Bug:4424037 として弊社開発部門で調査中
です。 この為、これらのプラットフォームでは、他の Unix プラットフォーム
より $ORACLE_HOME/jdk/jre/lib/fonts/ALBANWTJ.TTF をコピーすることで
回避下さい。
[更新履歴]
2005/06/10 補足の情報を更新
2004/12/03 補足を追記
2004/10/27 本文書を公開
Patch 3639533
文書番号 100150 最終更新日 2006-02-22 公開区分 契約顧客のみ
製品名(バージョン)[コンポーネント] Application Server 全般(インストール,PSR等) (9.0.4 - 10.1.2) [Release Notes]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 91571
概要 Application Server Contorol で「ログイン」「更新」「停止」「実行」等のボタン部分が文字化けする
内容:
[概要]
Application Server Contorol で「ログイン」「更新」「停止」「実行」等の
ボタン部分が文字化けします。
[対象リリース]
Oracle Application Server 10g Release2(10.1.2)
Oracle Application Server 10g (9.0.4)
[対象プラットフォーム]
すべてのプラットフォーム
[詳細]
Application Server Contorol に初回アクセスを行った際に、画面で使用する
ボタンが生成されます。その際に、日本語のフォントファイルにアクセスでき
ない場合、作成されるボタンが文字化けします。
Application Server Contorol は下記の順序で、フォントファイルを探します。
1. 日本語でのインストール時に作成される ALBANWTJ.TTF
存在する場所:
~~~~~~~~~~~~~
UnixおよびLinuxプラットフォーム: $ORACLE_HOME/jdk/jre/lib/fonts
Microsoft Windowsプラットフォーム: %ORACLE_HOME%\jdk\jre\lib\fonts
2. OS に存在するフォントファイル
例: HG-GothicB.ttf,HeiseiMin-W3H.ttf など
存在する場所:
~~~~~~~~~~~~~
OS の環境に依存します。
1と2のいずれにもアクセスすることができない場合、生成されるボタンが文字
化けします。
インストール時の言語に日本語が選択されていない場合、ALBANWTJ.TTF が存在
しないため、文字化けが発生する可能性があります。
[FAQ]
Q1.文字化けが発生した場合の対応策を教えてください。
A1.下記の手順で文字化けに対応することが可能です。
1. 正常な環境の ALBANWTJ.TTF を、問題が発生している環境の以下のパスに
コピーします。 正常にインストールした環境がない場合は、別の環境に
インストールし、その環境よりファイルをコピーして下さい。
UnixおよびLinuxプラットフォーム: $ORACLE_HOME/jdk/jre/lib/fonts
Microsoft Windowsプラットフォーム: %ORACLE_HOME%\jdk\jre\lib\fonts
2. Application Server Contorol を停止します。
UnixおよびLinuxプラットフォーム :
$ORACLE_HOME/bin/emctl stop iasconsole
Microsoft Windowsプラットフォーム:
%ORACLE_HOME%\bin\emctl stop iasconsole
3. 以下のディレクトリのファイルを削除します。
UnixおよびLinuxプラットフォーム :
$ORACLE_HOME/sysman/webapps/emd/cabo/images/cache/ja
Microsoft Windowsプラットフォーム:
%ORACLE_HOME%\sysman\webapps\emd\cabo\images\cache\ja
4. Application Server Contorol を起動します。
UnixおよびLinuxプラットフォーム :
$ORACLE_HOME/bin/emctl start iasconsole
Microsoft Windowsプラットフォーム:
%ORACLE_HOME%\bin\emctl start iasconsole
[参照情報]
KROWN:91571
「Enterprise Manager Database Contorol で「ログイン」「更新」「停止」
「実行」等のボタン部分だけが文字化けする」
[更新履歴]
2006/01/10 本文書を修正・公開区分を変更
2005/05/12 本文書を公開
2005/05/11 本文書を作成
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
[起こりうる現象]
Enterprise Manager Database Contorol で「ログイン」「更新」「停止」
「実行」等のボタン部分だけが文字化けします。
[対象リリース]
問題が発生するリリース ：Oracle Enterprise Manager 10g Database Control (10.1.0)
問題を修正したリリース ：なし
問題を修正予定のリリース：なし
問題を修正したPSR ：なし
問題を修正予定のPSR ：なし
[対象プラットフォーム]
すべてのプラットフォーム
[起こりうる条件]
インストール時の言語に日本語が選択されていない場合に発生します。
[原因]
インストール時の言語に日本語が選択されていないことが原因です。
本件に該当しているかどうかは、$ORACLE_HOME/jdk/jre/lib/fonts/ に
ALBANWTJ.TTF というファイルが存在するかどうかで確認可能です。
存在しない場合は本件に該当しています。
[回避策]
以下の方法で回避可能です。
1. 正常な環境の、$ORACLE_HOME/jdk/jre/lib/fonts/ALBANWTJ.TTF を
問題が発生している環境の $ORACLE_HOME/jdk/jre/lib/fonts/ にコピー
します。 正常にインストールした環境がない場合は、別の環境にインス
トールしその環境よりファイルをコピーする方法でご対応下さい。
2. Enterprise Manager を停止します。
emctl stop dbconsole
3. $ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/cabo/images/cache/ja
ディレクトリのファイルを削除します。
4. Enterprise Manager を再起動します。
emctl start dbconsole
[補足]
プラットフォームによっては、$ORACLE_HOME/jdk/jre/lib/fonts/ALBANWTJ.TTF
が 0バイトとしてインストールされる問題が確認できております。
本問題が確認できているプラットフォームは以下の通りとなります。
- HP-UX Itanium
- IBM zSeries Based Linux
- Solaris (X86)
本問題につきましては、Bug:4044060 Bug:4424037 として弊社開発部門で調査中
です。 この為、これらのプラットフォームでは、他の Unix プラットフォーム
より $ORACLE_HOME/jdk/jre/lib/fonts/ALBANWTJ.TTF をコピーすることで
回避下さい。
[更新履歴]
2005/06/10 補足の情報を更新
2004/12/03 補足を追記
2004/10/27 本文書を公開
Patch 3639533
Monday, June 25, 2007
Default password of iSQL*Plus DBA realm administrator user, admin
设置isqlplus可以以dba身份登录时，iSQL*Plus DBA realm administrator user, admin的默认密码是welcome。
Wednesday, June 13, 2007
NLS_DATABASE_PARAMETERSのNLS関連のパラメータに任意の値を設定する方法
文書番号 40614 最終更新日 2002-02-16 公開区分 契約顧客のみ
製品名(バージョン)[コンポーネント] Oracle Server - Enterprise Edition (ALL - ALL) [RDBMS]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書
概要 NLS_DATABASE_PARAMETERSのNLS関連のパラメータに任意の値を設定する方法
内容:
[質問]
NLS_DATABASE_PARAMETERSビューのNLS関連の値(NLS_LANGUAGE、NLS_TERRITORY、NLS_DATE_LANGUAGE
など）に、任意の値を設定する方法を教えてください。
また、これらの値をDB作成完了後に変更する方法はありますか。
[回答]
NLS_DATABASE_PARAMETERSビューを参照すると、DBのNLS関連のデフォルト値が確認できます。
NLS_LANGUAGE、NLS_TERRITORY、NLS_DATE_LANGUAGEなど、DBのキャラクタ・セット以外の
NLS関連のパラメータは、CREATE DATABASEコマンドに直接指定することはできません。
これらの設定値を任意の値に設定するには、init初期化パラメータ内に、任意の値を
あらかじめ記述した状態で、CREATE DATABASEコマンドを実行します。
このデフォルト値(NLS_DATABASE_PARAMETERSビューに出力される値）ですが、CREATE DATABASE
コマンド完了後に変更する手段はありません。ただ、確かにデフォルト値そのものはDB固有の値
となり変更ができないのですが、init初期化パラメータに値を設定する、NLS_LANGに値を設定する、
alter sessionコマンドを使用するなどにより、適宜、必要な値に上書きした上で処理を行うこと
が可能ですので、CREATE DATABASEコマンド実行時にNLS関連の値を初期化パラメータファイル内に
あえて記述しておかなければならないということはございません。
（記述しておく必要はございません。）
[更新履歴]
2002/02/16 誤字を修正
製品名(バージョン)[コンポーネント] Oracle Server - Enterprise Edition (ALL - ALL) [RDBMS]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書
概要 NLS_DATABASE_PARAMETERSのNLS関連のパラメータに任意の値を設定する方法
内容:
[質問]
NLS_DATABASE_PARAMETERSビューのNLS関連の値(NLS_LANGUAGE、NLS_TERRITORY、NLS_DATE_LANGUAGE
など）に、任意の値を設定する方法を教えてください。
また、これらの値をDB作成完了後に変更する方法はありますか。
[回答]
NLS_DATABASE_PARAMETERSビューを参照すると、DBのNLS関連のデフォルト値が確認できます。
NLS_LANGUAGE、NLS_TERRITORY、NLS_DATE_LANGUAGEなど、DBのキャラクタ・セット以外の
NLS関連のパラメータは、CREATE DATABASEコマンドに直接指定することはできません。
これらの設定値を任意の値に設定するには、init初期化パラメータ内に、任意の値を
あらかじめ記述した状態で、CREATE DATABASEコマンドを実行します。
このデフォルト値(NLS_DATABASE_PARAMETERSビューに出力される値）ですが、CREATE DATABASE
コマンド完了後に変更する手段はありません。ただ、確かにデフォルト値そのものはDB固有の値
となり変更ができないのですが、init初期化パラメータに値を設定する、NLS_LANGに値を設定する、
alter sessionコマンドを使用するなどにより、適宜、必要な値に上書きした上で処理を行うこと
が可能ですので、CREATE DATABASEコマンド実行時にNLS関連の値を初期化パラメータファイル内に
あえて記述しておかなければならないということはございません。
（記述しておく必要はございません。）
[更新履歴]
2002/02/16 誤字を修正
Monday, June 11, 2007
Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成する方法について
文書番号 106289 最終更新日 2007-03-10 公開区分 契約顧客のみ
製品名(バージョン)[コンポーネント] Oracle Enterprise Manager ( - ) [Oracle Enterprise Manager]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 106355 120390 86570
概要 Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成する方法について
内容:
[概要]
Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成
する方法について
[対象リリース]
Oracle Enterprise Manager 10g Database Control (10.2.0)
[対象プラットフォーム]
すべてのプラットフォーム
[詳細]
Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成
する方法は以下の通りです。
1. Database Control (リポジトリ及び構成ファイル)を構成するには以下の
コマンドを実行ください。
emca -config dbcontrol db -repos create
2. Database Control (リポジトリ及び構成ファイル)を削除するには以下の
コマンドを実行ください。
emca -deconfig dbcontrol db -repos drop
3. Database Control (リポジトリ及び構成ファイル)を再構成するには以下の
コマンドを実行ください。
emca -config dbcontrol db -repos recreate
4. Database Control の構成ファイルのみを再作成するには以下のコマンドを
実行ください。
emca -deconfig dbcontrol db
emca -config dbcontrol db
何らかの問題が発生した場合は、$ORACLE_HOME/cfgtoollogs/emca/ 配下及び
$ORACLE_HOME/cfgtoollogs/emca/ 配下のログを確認します。
[補足1]
複数 Network Interface Card（NIC）環境などにおいて、シングルデータベース
環境の場合は以下の方法で任意のホスト名を emca に認識させて、
Database Control を構成することが可能です。
KROWN:120390 Oracle Enterprise Manager Database Control を任意のホスト
名で構成する方法について
[補足2]
リポジトリの削除の開始時及び完了時には以下のコマンドが内部的に実行され
ます。
リポジトリの削除開始時 ALTER SYSTEM QUIESCE RESTRICTED
リポジトリの削除完了時 ALTER SYSTEM UNQUIESCE
QUIESCE RESTRICTED は、データベースがオープン中のすべてのインスタンス
に次の影響を与えますのでご注意下さい。
Oracleデータベースは、すべてのインスタンスのデータベース・リソース・
マネ－ジャに、アクティブでないすべてのセッション（SYSおよびSYSTEM以
外）をアクティブにしないように指示します。SYSおよびSYSTEM以外の
ユーザーは、新しいトランザクション、問合せ、フェッチまたはPL/SQL
操作を開始できません。
[補足3]
Database Control ではリポジトリの削除は以下のような手順で行わ
れております。基本的には、上記手順での削除を推奨させて頂きます
が、何らかの理由により上記手順では何度再試行してもどうしても
削除できない場合には、以下の例を参考に削除することについても
ご検討下さい。
1. USER 及び ROLE の削除
drop user MGMT_VIEW cascade;
drop user SYSMAN cascade;
drop role MGMT_USER;
2. PUBLIC SYNONYM の削除(注1)
以下の結果から得られるシノニムを DROP PUBLIC SYNONYM により削除
SELECT object_name from all_objects
WHERE (object_name like 'MGMT$%' OR
object_name like 'MGMT_%' OR
object_name like 'SMP_EMD%' OR
object_name like 'SMP_MGMT%' OR
object_name = 'SETEMVIEWUSERCONTEXT' OR
object_name = 'DBMS_SHARED_POOL' OR
object_name = 'EMD_MNTR' OR
object_name = 'ECM_UTIL'
)
AND object_type='SYNONYM';
3. 以下の結果得られるロールを削除して下さい。(注1)
select role from sys.dba_roles where role like 'MGMT_%';
なお、上記手順では、構成ファイル等は削除されませんので、以下の例の
ように別途 emca -deconfig を実行する必要があります。
% emca -deconfig dbcontrol db
(注1) 上記手順で確認できるシノニムやロールにお客様のオブジェクトが
含まれる場合は、そのオブジェクトについては削除しないよう
お願い致します。
[参照情報]
Oracle Enterprise Manager 10g Database Control 10.1.0 をご利用のお客様は
以下をご参照下さい。
KROWN:86570 Enterprise Manager 10g Database Control のサービス構成ファ
イルおよび Management Repository の再作成手順
KROWN:106355 Database Control 10.2.0 の emca のオプションの概要について
[更新履歴]
2007/03/10 補足及び参照情報を更新
2007/02/09 補足を追記
2005/09/26 本文書を公開
製品名(バージョン)[コンポーネント] Oracle Enterprise Manager ( - ) [Oracle Enterprise Manager]
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 106355 120390 86570
概要 Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成する方法について
内容:
[概要]
Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成
する方法について
[対象リリース]
Oracle Enterprise Manager 10g Database Control (10.2.0)
[対象プラットフォーム]
すべてのプラットフォーム
[詳細]
Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成
する方法は以下の通りです。
1. Database Control (リポジトリ及び構成ファイル)を構成するには以下の
コマンドを実行ください。
emca -config dbcontrol db -repos create
2. Database Control (リポジトリ及び構成ファイル)を削除するには以下の
コマンドを実行ください。
emca -deconfig dbcontrol db -repos drop
3. Database Control (リポジトリ及び構成ファイル)を再構成するには以下の
コマンドを実行ください。
emca -config dbcontrol db -repos recreate
4. Database Control の構成ファイルのみを再作成するには以下のコマンドを
実行ください。
emca -deconfig dbcontrol db
emca -config dbcontrol db
何らかの問題が発生した場合は、$ORACLE_HOME/cfgtoollogs/emca/ 配下及び
$ORACLE_HOME/cfgtoollogs/emca/
[補足1]
複数 Network Interface Card（NIC）環境などにおいて、シングルデータベース
環境の場合は以下の方法で任意のホスト名を emca に認識させて、
Database Control を構成することが可能です。
KROWN:120390 Oracle Enterprise Manager Database Control を任意のホスト
名で構成する方法について
[補足2]
リポジトリの削除の開始時及び完了時には以下のコマンドが内部的に実行され
ます。
リポジトリの削除開始時 ALTER SYSTEM QUIESCE RESTRICTED
リポジトリの削除完了時 ALTER SYSTEM UNQUIESCE
QUIESCE RESTRICTED は、データベースがオープン中のすべてのインスタンス
に次の影響を与えますのでご注意下さい。
Oracleデータベースは、すべてのインスタンスのデータベース・リソース・
マネ－ジャに、アクティブでないすべてのセッション（SYSおよびSYSTEM以
外）をアクティブにしないように指示します。SYSおよびSYSTEM以外の
ユーザーは、新しいトランザクション、問合せ、フェッチまたはPL/SQL
操作を開始できません。
[補足3]
Database Control ではリポジトリの削除は以下のような手順で行わ
れております。基本的には、上記手順での削除を推奨させて頂きます
が、何らかの理由により上記手順では何度再試行してもどうしても
削除できない場合には、以下の例を参考に削除することについても
ご検討下さい。
1. USER 及び ROLE の削除
drop user MGMT_VIEW cascade;
drop user SYSMAN cascade;
drop role MGMT_USER;
2. PUBLIC SYNONYM の削除(注1)
以下の結果から得られるシノニムを DROP PUBLIC SYNONYM により削除
SELECT object_name from all_objects
WHERE (object_name like 'MGMT$%' OR
object_name like 'MGMT_%' OR
object_name like 'SMP_EMD%' OR
object_name like 'SMP_MGMT%' OR
object_name = 'SETEMVIEWUSERCONTEXT' OR
object_name = 'DBMS_SHARED_POOL' OR
object_name = 'EMD_MNTR' OR
object_name = 'ECM_UTIL'
)
AND object_type='SYNONYM';
3. 以下の結果得られるロールを削除して下さい。(注1)
select role from sys.dba_roles where role like 'MGMT_%';
なお、上記手順では、構成ファイル等は削除されませんので、以下の例の
ように別途 emca -deconfig を実行する必要があります。
% emca -deconfig dbcontrol db
(注1) 上記手順で確認できるシノニムやロールにお客様のオブジェクトが
含まれる場合は、そのオブジェクトについては削除しないよう
お願い致します。
[参照情報]
Oracle Enterprise Manager 10g Database Control 10.1.0 をご利用のお客様は
以下をご参照下さい。
KROWN:86570 Enterprise Manager 10g Database Control のサービス構成ファ
イルおよび Management Repository の再作成手順
KROWN:106355 Database Control 10.2.0 の emca のオプションの概要について
[更新履歴]
2007/03/10 補足及び参照情報を更新
2007/02/09 補足を追記
2005/09/26 本文書を公開
Enterprise Manager 10g Database Control のサービス構成ファイルおよび Management Repository の再作成手順
文書番号 86570 最終更新日 2007-02-09 公開区分 契約顧客のみ
製品名(バージョン)[コンポーネント] Oracle Enterprise Manager (10.1.0 - 10.1.0) []
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 106541 86574 106289 120390
概要 Enterprise Manager 10g Database Control のサービス構成ファイルおよび Management Repository の再作成手順
内容:
[概要]
Enterprise Manager 10g (10.1) Database Control のサービス構成ファイル
および Management Repository の再作成手順
(10.2 の場合は KROWN:106289 をご参照ください)
[対象リリース]
Oracle Enterprise Manager 10g リリース 1 (10.1)
[対象プラットフォーム]
すべてのプラットフォーム
[詳細]
Enterprise Manager 10g Database Contorol のサービス構成ファイルおよび
Management Repository は、下記の手順で再作成することが可能です。
サーバーのホスト名や IP アドレスを変更する場合には、サービス構成ファイル
と Management Repository の両方の再作成が必要です (KROWN:86574 参照)。
なお、複数 Network Interface Card（NIC）環境などにおいて、シングルデータ
ベース環境の場合は KROWN:120390 の方法で任意のホスト名を emca に認識させて
Database Control を構成することが可能です。
次の項目別に手順について説明します。
1. Management Repository の削除手順
2. Enterprise Manager 10g Database Contorol のサービス構成ファイルの
再構成手順
2.1. シングルデータベース環境での再構成手順
2.2. Real Application Cluster + ASM 環境での再構成手順
1. の Management Repository の再作成をおこなった場合は、必ず 2. の
Enterprise Manager 10g Database Contorol のサービス構成ファイルを行う
必要があります。
但し、1. の Management Repository の再作成を行わずに、2. の Enterprise
Manager 10g Database Contorol のサービス構成ファイル再作成のみを行うこと
は可能です。この場合は、2 の手順の emca コマンド実行の際に -r オプション
を使用する必要があります。
■ 1. Management Repository の削除手順
- Unix システム
RepManager スクリプトで Management Repository を削除します。
% cd $ORACLE_HOME/sysman/admin/emdrep/bin
% ./RepManager <ホスト名> <リスナーのポート番号> -sys_password -action drop
- Windows システム
以下のいずれかの方法にて Management Repository を削除します。
a. RepManager スクリプトで削除する手順（10.1.0.3 以降）
コマンドプロンプト上で下記を実行します
set ORACLE_HOME=
set ORACLE_SID=
cd %ORACLE_HOME%\sysman\admin\emdrep\bin
RepManager.bat <ホスト名> <リスナーのポート番号> -sys_password -action drop
b. perl スクリプトで削除する手順
コマンドプロンプト上で下記を実行します
set ORACLE_HOME=
set ORACLE_SID=
path %ORACLE_HOME%\perl\5.6.1\bin\MSWin32-x86;%PATH%
cd %ORACLE_HOME%\sysman\admin\emdrep\bin
perl emrepmgr.pl <ホスト名> <リスナーのポート番号> -sys_password -action drop
この際、sysman ユーザーのパスワードを入力する前後で stty が見つ
からないというメッセージが表示されますが、メッセージは無視して
sysman ユーザーのパスワードを入力してください。
c. データベース上から手動で削除する手順
OracleDBConsoleサービスを停止します。
DBA 権限を持つユーザーで SQL*Plus でデータベースに接続して下記を実行します
drop user sysman cascade;
drop user mgmt_view cascade;
drop role mgmt_user;
drop public synonym mgmt_target_blackouts;
drop public synonym setemviewusercontext;
■ 2. Enterprise Manager 10g Database Contorol のサービス構成ファイルの
再構成手順
2.1. シングルデータベース環境での再構成手順
以下の方法にて Enterprise Manager 10g Database Contorol のサービス
構成ファイルの削除を行います。
emca -x
※ 予め環境変数 ORACLE_HOME、ORACLE_SID の設定が必要です。
例) (Windows の場合)
set ORACLE_HOME=
set ORACLE_SID=
続いて Enterprise Manager 10g Database Contorol サービス構成
ファイルの構成を以下の方法で行います。
emca
※ 1. の Management Repository の再作成を行わない場合は、
-r オプションを使用して行ってください
例) emca -r
emca コマンドを実行すると、下記の入力を求められます。
リスナーのポート番号
データベースの SID
サービス名（データベースの service_name です。lsnrctl status 等で確認可能です）
通知用の電子メール・アドレス（オプションです。入力しなくても先に進めます）
通知用の電子メール・ゲートウェイ（同上）
DBSNMP のパスワード
SYSMAN のパスワード
SYS のパスワード
2.2. Real Application Cluster + ASM 環境での再構成手順
以下の方法にて Enterprise Manager 10g Database Contorol のサービス
構成ファイルの削除を行います。
emca -c -x
※ は初期化パラメータ db_name で指定している値です。
ではないため、ご注意ください。
※ 予め環境変数 ORACLE_HOME、ORACLE_SID の設定が必要です。
例) (Windows の場合)
set ORACLE_HOME=
set ORACLE_SID=
続いて Enterprise Manager 10g Database Contorol サービス構成
ファイルの構成を以下の方法で行います。
emca -a -c
-a : ASM 環境で設定するオプションです。
-c : Real Application Cluster 環境で設定するオプションです。
※ 1. の Management Repository の再作成行わない場合は、
-r オプションを使用して行ってください
例) emca -a -c -r
emca コマンドを実行すると、下記の入力を求められます。
リスナーのポート番号
クラスタ名 (CRS 側の ORACLE_HOME/install/cluster.ini の cluster_name で指定されている値です)
データベース名 (初期化パラメータ db_name で指定されている値です)
サービス名（データベースの service_name です。lsnrctl status 等で確認可能です）
通知用の電子メール・アドレス:（オプションです。入力しなくても先に進めます）
通知用の電子メール・ゲートウェイ:（オプションです。入力しなくても先に進めます）
ASM ORACLE_HOME [ ... ]
ASMポート [ ... ]
ASMユーザー・ロール [ SYSDBA ]
ASMユーザー名 [ SYS ]
ASMユーザー・パスワード
DBSNMPのパスワード
SYSMANのパスワード
SYSのパスワード
■ 補足 1
- シングルデータベースにおいて、ASM 環境を利用している場合は以下のよう
に構成することも可能です。
emca -a
※ 1. の Management Repository の再作成を行わない場合は以下のように
なります。
emca -a -r
- emca コマンドにより構成行った場合は以下のディレクトリにログファイルが
出力されます。
UNIX の場合: $ORACLE_HOME/cfgtoollogs/
Windows の場合: %ORACLE_HOME%\cfgtoollogs\
■ 補足 2
リポジトリの削除の開始時及び完了時には以下のコマンドが内部的に実行され
ます。
リポジトリの削除開始時 ALTER SYSTEM QUIESCE RESTRICTED
リポジトリの削除完了時 ALTER SYSTEM UNQUIESCE
QUIESCE RESTRICTED は、データベースがオープン中のすべてのインスタンス
に次の影響を与えますのでご注意下さい。
Oracleデータベースは、すべてのインスタンスのデータベース・リソース・
マネ－ジャに、アクティブでないすべてのセッション（SYSおよびSYSTEM以
外）をアクティブにしないように指示します。SYSおよびSYSTEM以外の
ユーザーは、新しいトランザクション、問合せ、フェッチまたはPL/SQL
操作を開始できません。
[参照情報]
『Oracle Enterprise Manager 構成ガイド 10g リリース 1 (10.1)』
KROWN:86574 サーバーのホスト名や IP アドレスを変更すると Enterprise Manager 10g Database Control が起動しない
KROWN:106541 Enterprise Manager 10g Database Control でリポジトリを再構成した際の影響について
KROWN:106289 Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成する方法について
KROWN:120390 Oracle Enterprise Manager Database Control を任意のホスト 名で構成する方法について
[更新履歴]
2007/02/09 補足 2 を追記
2006/12/13 KROWN:120390 への参照を追記
2006/05/11 KROWN:106289 への参照を追記
2005/12/06 Management Repositoryの削除手順のc.の方法に OracleDBConsoleの停止を追加
2005/10/11 KROWN:106541 への参照を追記
2005/10/06 構成を変更に伴い、クラスタ、ASM環境における方法を追記
2005/02/03 参照情報に KROWN:86574 を追記
2004/09/14 Windows 版で 10.1.0.3 から追加された RepManager.bat を追記
2004/07/12 本文書を公開
製品名(バージョン)[コンポーネント] Oracle Enterprise Manager (10.1.0 - 10.1.0) []
プラットフォーム(バージョン) すべてのプラットフォーム ( - )
関連文書 106541 86574 106289 120390
概要 Enterprise Manager 10g Database Control のサービス構成ファイルおよび Management Repository の再作成手順
内容:
[概要]
Enterprise Manager 10g (10.1) Database Control のサービス構成ファイル
および Management Repository の再作成手順
(10.2 の場合は KROWN:106289 をご参照ください)
[対象リリース]
Oracle Enterprise Manager 10g リリース 1 (10.1)
[対象プラットフォーム]
すべてのプラットフォーム
[詳細]
Enterprise Manager 10g Database Contorol のサービス構成ファイルおよび
Management Repository は、下記の手順で再作成することが可能です。
サーバーのホスト名や IP アドレスを変更する場合には、サービス構成ファイル
と Management Repository の両方の再作成が必要です (KROWN:86574 参照)。
なお、複数 Network Interface Card（NIC）環境などにおいて、シングルデータ
ベース環境の場合は KROWN:120390 の方法で任意のホスト名を emca に認識させて
Database Control を構成することが可能です。
次の項目別に手順について説明します。
1. Management Repository の削除手順
2. Enterprise Manager 10g Database Contorol のサービス構成ファイルの
再構成手順
2.1. シングルデータベース環境での再構成手順
2.2. Real Application Cluster + ASM 環境での再構成手順
1. の Management Repository の再作成をおこなった場合は、必ず 2. の
Enterprise Manager 10g Database Contorol のサービス構成ファイルを行う
必要があります。
但し、1. の Management Repository の再作成を行わずに、2. の Enterprise
Manager 10g Database Contorol のサービス構成ファイル再作成のみを行うこと
は可能です。この場合は、2 の手順の emca コマンド実行の際に -r オプション
を使用する必要があります。
■ 1. Management Repository の削除手順
- Unix システム
RepManager スクリプトで Management Repository を削除します。
% cd $ORACLE_HOME/sysman/admin/emdrep/bin
% ./RepManager <ホスト名> <リスナーのポート番号>
- Windows システム
以下のいずれかの方法にて Management Repository を削除します。
a. RepManager スクリプトで削除する手順（10.1.0.3 以降）
コマンドプロンプト上で下記を実行します
set ORACLE_HOME=
set ORACLE_SID=
cd %ORACLE_HOME%\sysman\admin\emdrep\bin
RepManager.bat <ホスト名> <リスナーのポート番号>
b. perl スクリプトで削除する手順
コマンドプロンプト上で下記を実行します
set ORACLE_HOME=
set ORACLE_SID=
path %ORACLE_HOME%\perl\5.6.1\bin\MSWin32-x86;%PATH%
cd %ORACLE_HOME%\sysman\admin\emdrep\bin
perl emrepmgr.pl <ホスト名> <リスナーのポート番号>
この際、sysman ユーザーのパスワードを入力する前後で stty が見つ
からないというメッセージが表示されますが、メッセージは無視して
sysman ユーザーのパスワードを入力してください。
c. データベース上から手動で削除する手順
OracleDBConsole
DBA 権限を持つユーザーで SQL*Plus でデータベースに接続して下記を実行します
drop user sysman cascade;
drop user mgmt_view cascade;
drop role mgmt_user;
drop public synonym mgmt_target_blackouts;
drop public synonym setemviewusercontext;
■ 2. Enterprise Manager 10g Database Contorol のサービス構成ファイルの
再構成手順
2.1. シングルデータベース環境での再構成手順
以下の方法にて Enterprise Manager 10g Database Contorol のサービス
構成ファイルの削除を行います。
emca -x
※ 予め環境変数 ORACLE_HOME、ORACLE_SID の設定が必要です。
例) (Windows の場合)
set ORACLE_HOME=
set ORACLE_SID=
続いて Enterprise Manager 10g Database Contorol サービス構成
ファイルの構成を以下の方法で行います。
emca
※ 1. の Management Repository の再作成を行わない場合は、
-r オプションを使用して行ってください
例) emca -r
emca コマンドを実行すると、下記の入力を求められます。
リスナーのポート番号
データベースの SID
サービス名（データベースの service_name です。lsnrctl status 等で確認可能です）
通知用の電子メール・アドレス（オプションです。入力しなくても先に進めます）
通知用の電子メール・ゲートウェイ（同上）
DBSNMP のパスワード
SYSMAN のパスワード
SYS のパスワード
2.2. Real Application Cluster + ASM 環境での再構成手順
以下の方法にて Enterprise Manager 10g Database Contorol のサービス
構成ファイルの削除を行います。
emca -c -x
※
※ 予め環境変数 ORACLE_HOME、ORACLE_SID の設定が必要です。
例) (Windows の場合)
set ORACLE_HOME=
set ORACLE_SID=
続いて Enterprise Manager 10g Database Contorol サービス構成
ファイルの構成を以下の方法で行います。
emca -a -c
-a : ASM 環境で設定するオプションです。
-c : Real Application Cluster 環境で設定するオプションです。
※ 1. の Management Repository の再作成行わない場合は、
-r オプションを使用して行ってください
例) emca -a -c -r
emca コマンドを実行すると、下記の入力を求められます。
リスナーのポート番号
クラスタ名 (CRS 側の ORACLE_HOME/install/cluster.ini の cluster_name で指定されている値です)
データベース名 (初期化パラメータ db_name で指定されている値です)
サービス名（データベースの service_name です。lsnrctl status 等で確認可能です）
通知用の電子メール・アドレス:（オプションです。入力しなくても先に進めます）
通知用の電子メール・ゲートウェイ:（オプションです。入力しなくても先に進めます）
ASM ORACLE_HOME [ ... ]
ASMポート [ ... ]
ASMユーザー・ロール [ SYSDBA ]
ASMユーザー名 [ SYS ]
ASMユーザー・パスワード
DBSNMPのパスワード
SYSMANのパスワード
SYSのパスワード
■ 補足 1
- シングルデータベースにおいて、ASM 環境を利用している場合は以下のよう
に構成することも可能です。
emca -a
※ 1. の Management Repository の再作成を行わない場合は以下のように
なります。
emca -a -r
- emca コマンドにより構成行った場合は以下のディレクトリにログファイルが
出力されます。
UNIX の場合: $ORACLE_HOME/cfgtoollogs/
Windows の場合: %ORACLE_HOME%\cfgtoollogs\
■ 補足 2
リポジトリの削除の開始時及び完了時には以下のコマンドが内部的に実行され
ます。
リポジトリの削除開始時 ALTER SYSTEM QUIESCE RESTRICTED
リポジトリの削除完了時 ALTER SYSTEM UNQUIESCE
QUIESCE RESTRICTED は、データベースがオープン中のすべてのインスタンス
に次の影響を与えますのでご注意下さい。
Oracleデータベースは、すべてのインスタンスのデータベース・リソース・
マネ－ジャに、アクティブでないすべてのセッション（SYSおよびSYSTEM以
外）をアクティブにしないように指示します。SYSおよびSYSTEM以外の
ユーザーは、新しいトランザクション、問合せ、フェッチまたはPL/SQL
操作を開始できません。
[参照情報]
『Oracle Enterprise Manager 構成ガイド 10g リリース 1 (10.1)』
KROWN:86574 サーバーのホスト名や IP アドレスを変更すると Enterprise Manager 10g Database Control が起動しない
KROWN:106541 Enterprise Manager 10g Database Control でリポジトリを再構成した際の影響について
KROWN:106289 Oracle Enterprise Manager Database Control 10.2 を構成、削除、再構成する方法について
KROWN:120390 Oracle Enterprise Manager Database Control を任意のホスト 名で構成する方法について
[更新履歴]
2007/02/09 補足 2 を追記
2006/12/13 KROWN:120390 への参照を追記
2006/05/11 KROWN:106289 への参照を追記
2005/12/06 Management Repositoryの削除手順のc.の方法に OracleDBConsole
2005/10/11 KROWN:106541 への参照を追記
2005/10/06 構成を変更に伴い、クラスタ、ASM環境における方法を追記
2005/02/03 参照情報に KROWN:86574 を追記
2004/09/14 Windows 版で 10.1.0.3 から追加された RepManager.bat を追記
2004/07/12 本文書を公開
Sunday, June 10, 2007
workflow
workflow
# 关于发生的现象请详细说明。(必须)
・是否是错误代码/错误信息？
・是否属于bug或时间延迟？
・是否是instance down、node down之类？
・进行了什么样的处理/执行了什么样的命令？
・请告知现象发生的node、精确的时刻。(必须)
・最近数据库、CRS、application有什么相关的变更吗。
# 请告知现象发生的频度。(必须)
・ 是（毎次 / 经常/ 有时候 / 首次 / 其他）中的哪一个？
・ 错误发生的时候处于哪个阶段？（执行处理的时候 / 其他）
・ 是否有可能人工的让现象重现？
# 请告知运行数据库的服务器的环境构成。(必须)
・node名(host名)、node数、instance名(各node上的ORACLE_SID)
・是否存在vendor cluster ware?
・使用ASM的instance了吗?
・请告知数据库的辅助记忆装置。(例：RAW DEVICE、OCFS、NAS、CFS、etc)
・如果node间存在系统时间差、请告知。
# 请告知是否使用个别补丁。(必須)
・使用个别补丁的时候、请告知其BUG#。
(如有可能、请提供最新的opatch的opatch lsinventory –detail之结果的text file。)
# 为了连接数据库、运用了什么工具(Version)?
例) SQL*Plus/Server Manager/Pro*C/Pro*COBOL
请告知是否能通过连接工具进行现象的再现。
还有，是否能通过SQL*Plus进行再现?
# 请告知与application的连接状态和所使用的protocol。(必須)
・连接状态 – 专用服务器连接/MTS(multi・thread・server)连接
・protocol -- TCP/BEQ/IPC/其他
# 为了解决问题、如能再现现象，请提供小型的再现case。
如果不能，请告知不能提供的原因。
# 问题有没有回避的方法?
请告诉回避方法的具体步骤。
# 问题发生是在真正环境还是在试验环境中发生的？
问题对业务和项目有多大程度的影响業務？
# 问题等现象发生后、还能正常使用吗?
另外，问题发生呢后，要复原的话，用该采取什么样的步骤?
# 请提供以下信息。(※ 以下都可从node上获得。)
・数据库相关的log一份
原始参数・file、问题生前一时刻的startup以后的ALERT.LOG，以及
问题生前后48小时生成的thread・file(*.trc)
（thread file是指、bdump、udump 下的全部内容)
(使用ASMinstance的场合、ASM instance方面的相关信息也请一并提供。)
・CRS相关log一份 (10g Release1) 请提供下述目录下的log。
$ORA_CRS_HOME/crs/log、 $ORA_CRS_HOME/css/log、$ORA_CRS_HOME/evm/log、
$ORA_CRS_HOME/racg/dump、$ORACLE_HOME/racg/dump
・Oracle Clusterware(CRS) 相关的log一份 (10g Release2)
请提供下述目录下的log。
$ORA_CRS_HOME/log/＜hostname＞/crsd、$ORA_CRS_HOME/log/＜hostname＞/cssd
$ORA_CRS_HOME/log/＜hostname＞/evmd、$ORA_CRS_HOME/log/＜hostname＞/racg
$ORACLE_HOME/log/＜hostname＞/racg
・Linux、Windows上是 9i的时候、提供oracm 的log (cm.log、cmsrvr.＜nodename＞.log)
・OS方的log
syslog、messages 等、AIX是、errpt、errpt -a
Windows的情况下、提供event log(application log、text形式的system log。)
・问题属于bug，时间延迟的时候、提供SQL_TRACE(event 10046 level 12)和STATSPACK。
另外、请提供OS level的负荷状况相关信息(vmstat、sar、iotstat、top、glance 等)。
# 请告知贵公司调查内容。
・哪个log的哪个地方报错？（或者注意到哪个地方输出的信息有问题？）。
・ 请告知所参考过的相关KROWN、Metalink的信息。
# 另外、注意到哪个地方不正常等，也请告诉我们。
另外、进行障害验证等的时候、请告诉我们贵公司所想定的具体是怎样的验证内容。
# 关于发生的现象请详细说明。(必须)
・是否是错误代码/错误信息？
・是否属于bug或时间延迟？
・是否是instance down、node down之类？
・进行了什么样的处理/执行了什么样的命令？
・请告知现象发生的node、精确的时刻。(必须)
・最近数据库、CRS、application有什么相关的变更吗。
# 请告知现象发生的频度。(必须)
・ 是（毎次 / 经常/ 有时候 / 首次 / 其他）中的哪一个？
・ 错误发生的时候处于哪个阶段？（执行处理的时候 / 其他）
・ 是否有可能人工的让现象重现？
# 请告知运行数据库的服务器的环境构成。(必须)
・node名(host名)、node数、instance名(各node上的ORACLE_SID)
・是否存在vendor cluster ware?
・使用ASM的instance了吗?
・请告知数据库的辅助记忆装置。(例：RAW DEVICE、OCFS、NAS、CFS、etc)
・如果node间存在系统时间差、请告知。
# 请告知是否使用个别补丁。(必須)
・使用个别补丁的时候、请告知其BUG#。
(如有可能、请提供最新的opatch的opatch lsinventory –detail之结果的text file。)
# 为了连接数据库、运用了什么工具(Version)?
例) SQL*Plus/Server Manager/Pro*C/Pro*COBOL
请告知是否能通过连接工具进行现象的再现。
还有，是否能通过SQL*Plus进行再现?
# 请告知与application的连接状态和所使用的protocol。(必須)
・连接状态 – 专用服务器连接/MTS(multi・thread・server)连接
・protocol -- TCP/BEQ/IPC/其他
# 为了解决问题、如能再现现象，请提供小型的再现case。
如果不能，请告知不能提供的原因。
# 问题有没有回避的方法?
请告诉回避方法的具体步骤。
# 问题发生是在真正环境还是在试验环境中发生的？
问题对业务和项目有多大程度的影响業務？
# 问题等现象发生后、还能正常使用吗?
另外，问题发生呢后，要复原的话，用该采取什么样的步骤?
# 请提供以下信息。(※ 以下都可从node上获得。)
・数据库相关的log一份
原始参数・file、问题生前一时刻的startup以后的ALERT.LOG，以及
问题生前后48小时生成的thread・file(*.trc)
（thread file是指、bdump、udump 下的全部内容)
(使用ASMinstance的场合、ASM instance方面的相关信息也请一并提供。)
・CRS相关log一份 (10g Release1) 请提供下述目录下的log。
$ORA_CRS_HOME/crs/log、 $ORA_CRS_HOME/css/log、$ORA_CRS_HOME/evm/log、
$ORA_CRS_HOME/racg/dump、$ORACLE_HOME/racg/dump
・Oracle Clusterware(CRS) 相关的log一份 (10g Release2)
请提供下述目录下的log。
$ORA_CRS_HOME/log/＜hostname＞/crsd、$ORA_CRS_HOME/log/＜hostname＞/cssd
$ORA_CRS_HOME/log/＜hostname＞/evmd、$ORA_CRS_HOME/log/＜hostname＞/racg
$ORACLE_HOME/log/＜hostname＞/racg
・Linux、Windows上是 9i的时候、提供oracm 的log (cm.log、cmsrvr.＜nodename＞.log)
・OS方的log
syslog、messages 等、AIX是、errpt、errpt -a
Windows的情况下、提供event log(application log、text形式的system log。)
・问题属于bug，时间延迟的时候、提供SQL_TRACE(event 10046 level 12)和STATSPACK。
另外、请提供OS level的负荷状况相关信息(vmstat、sar、iotstat、top、glance 等)。
# 请告知贵公司调查内容。
・哪个log的哪个地方报错？（或者注意到哪个地方输出的信息有问题？）。
・ 请告知所参考过的相关KROWN、Metalink的信息。
# 另外、注意到哪个地方不正常等，也请告诉我们。
另外、进行障害验证等的时候、请告诉我们贵公司所想定的具体是怎样的验证内容。
Monday, June 04, 2007
When Dropping or Truncating Table, When Creating or Rebuilding Index
ORA-0054: When Dropping or Truncating Table, When Creating or Rebuilding Index
Doc ID: Note:117316.1 Type: TROUBLESHOOTING
Last Revision Date: 20-OCT-2005 Status: PUBLISHED
Problem Description
-------------------
When trying to drop or truncate a table, or create or alter an index
of a table, you receive the following error message:
ORA-00054: resource busy and acquire with NOWAIT specified
Cause: Resource interested is busy
Action: Retry if necessary
Solution Description
--------------------
You need to analyze who has a lock on the table being dropped/truncated,
or on the table whose index is being created/alter-ed, and if it is valid.
Do the following:
1. Go to svrmgrl and connect internal.
2. select object_id from dba_objects where object_name='';
3. select * from v$locked_object where object_id=;
Note the "oracle_username" and "session_id".
4. Or you can query v$access
select sid from v$access where owner='' and
object='';
Note the session id number or "sid".
5. select sid, serial#, command, taddr from v$session
where sid=;
6. Now you have identified the user and what they are doing.
Investigation into the validity of this session needs to be
made. Many times it may be a job that ran before or a
hanging query. If it is determined that this session
needs to be terminated, go to step 7, or else wait until the user
has completed the action. To find out what they are doing,
look at the command number in the COMMAND column and match it
with the Command Number Values Table in either the Oracle 7 or
8 Server Reference manual listed under the entry for "V$SESSION".
7. To terminate the session:
alter system kill session '';
8. The session should now be killed and the lock SHOULD release.
Rechecking "v$locked_object" will tell you this. If the lock does
not immediately release, there may be a rollback occuring. To
check this, goto step nine, else dropping the table should
work now.
9. To check for rollback:
select used_ublk from v$transaction where ADDR=
If there is a value there, this is the number of undo blocks used by
the transaction. Wait one minute and again select "used_ublk" from
"v$transaction" where ADDR=; .
Note the value. If it is decreasing, a rollback is occuring and based
on the difference between these values, you can "guesstimate" the time
required to complete the rollback. For example, if the first query
returns a value of 80000 and the second one returns 70000, it
took 1 minute to rollback 10000 blocks. Based on this number,
you can guestimate the time to complete the rollback. In this
case, it would be 7 minutes.
10. In some cases, you might need to kill the session at the OS
level as well. Some 3rd party database monitoring software and
certain unexplained situations will cause the lock to remain
despite not showing up in "v$locked_object" after killing the
session.
Explanation
-----------
Dropping or truncating a table requires you to acquire an exclusive lock
on the table. A table is a "busy" resource if there are other sessions
modifying or holding a lock on the same table.
Doing a CREATE INDEX, DROP INDEX and ALTER INDEX REBUILD will lock the table
with a Share Table Lock (S). No DML operations are permitted on the base table.
Note, this is true for pre-8.1. For 8.1, if the ONLINE key word is
included as part of the CREATE INDEX or ALTER INDEX....REBUILD commands,
the table is locked with a Row Share Table Lock (RS). Other users will be
able to continue to access the table as normal except for any DDL operations.
DML operations are permitted.
Doc ID: Note:117316.1 Type: TROUBLESHOOTING
Last Revision Date: 20-OCT-2005 Status: PUBLISHED
Problem Description
-------------------
When trying to drop or truncate a table, or create or alter an index
of a table, you receive the following error message:
ORA-00054: resource busy and acquire with NOWAIT specified
Cause: Resource interested is busy
Action: Retry if necessary
Solution Description
--------------------
You need to analyze who has a lock on the table being dropped/truncated,
or on the table whose index is being created/alter-ed, and if it is valid.
Do the following:
1. Go to svrmgrl and connect internal.
2. select object_id from dba_objects where object_name='
3. select * from v$locked_object where object_id=
Note the "oracle_username" and "session_id".
4. Or you can query v$access
select sid from v$access where owner='
object='
Note the session id number or "sid".
5. select sid, serial#, command, taddr from v$session
where sid=
6. Now you have identified the user and what they are doing.
Investigation into the validity of this session needs to be
made. Many times it may be a job that ran before or a
hanging query. If it is determined that this session
needs to be terminated, go to step 7, or else wait until the user
has completed the action. To find out what they are doing,
look at the command number in the COMMAND column and match it
with the Command Number Values Table in either the Oracle 7 or
8 Server Reference manual listed under the entry for "V$SESSION".
7. To terminate the session:
alter system kill session '
8. The session should now be killed and the lock SHOULD release.
Rechecking "v$locked_object" will tell you this. If the lock does
not immediately release, there may be a rollback occuring. To
check this, goto step nine, else dropping the table should
work now.
9. To check for rollback:
select used_ublk from v$transaction where ADDR=
If there is a value there, this is the number of undo blocks used by
the transaction. Wait one minute and again select "used_ublk" from
"v$transaction" where ADDR=
Note the value. If it is decreasing, a rollback is occuring and based
on the difference between these values, you can "guesstimate" the time
required to complete the rollback. For example, if the first query
returns a value of 80000 and the second one returns 70000, it
took 1 minute to rollback 10000 blocks. Based on this number,
you can guestimate the time to complete the rollback. In this
case, it would be 7 minutes.
10. In some cases, you might need to kill the session at the OS
level as well. Some 3rd party database monitoring software and
certain unexplained situations will cause the lock to remain
despite not showing up in "v$locked_object" after killing the
session.
Explanation
-----------
Dropping or truncating a table requires you to acquire an exclusive lock
on the table. A table is a "busy" resource if there are other sessions
modifying or holding a lock on the same table.
Doing a CREATE INDEX, DROP INDEX and ALTER INDEX REBUILD will lock the table
with a Share Table Lock (S). No DML operations are permitted on the base table.
Note, this is true for pre-8.1. For 8.1, if the ONLINE key word is
included as part of the CREATE INDEX or ALTER INDEX....REBUILD commands,
the table is locked with a Row Share Table Lock (RS). Other users will be
able to continue to access the table as normal except for any DDL operations.
DML operations are permitted.
What To Do and Not To Do When 'shutdown immediate' Hangs
Subject: What To Do and Not To Do When 'shutdown immediate' Hangs
Doc ID: Note:375935.1 Type: HOWTO
Last Revision Date: 02-JUN-2007 Status: MODERATED
In this Document
Goal
Solution
References
--------------------------------------------------------------------------------
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.
Applies to:
Oracle Server - Enterprise Edition - Version: 8.1.7 to 10.2
Information in this document applies to any platform.
Goal
What to do when shutdown immediate appears to hang.
Sometimes, the message 'Waiting for smon to disable tx recovery' is posted in the alert log.
This note only addresses situations when the apparent hang occurs when the database is going from OPEN to MOUNT, which is actually the most common situation.
If the apparent hang occurs at a different step, then this note does not apply.
Solution
The big problem in these situations is that it is noticed only after the shutdown immediate has been issued.
This kind of situation is mostly caused by 2 things:
1. a large query running at the shutdown moment.
2. a large transaction running at the shutdown moment.
Both have to complete in order for the database to be brought down when shutdown immediate is issued.
Actually, the files cannot be closed consistently because of one of the 2 possibilities above and, as such, the transition from OPEN to MOUNT is postponed until the files are closed, which means that either the large query completes or the large transaction is rolled back. This is not a hang, it is the expected behavior.
So, before issuing the shutdown immediate, it would be recommended to check the following views, especially when the database needs to be brought down for a very short period of time:
1. for large queries:
select count(*) from v$session_longops where time_remaining>0;
2. for large transactions:
select sum(used_ublk) from v$transaction;
A result greater than 0 for the first query and a large value returned for the second one would mean a relatively long time to wait until the shutdown immediate completes.
For the second situation, please also check step 9 in Note 117316.1 to "guestimate" the time to rollback the transactions.
1. For the large queries situation, when the shutdown immediate is hanging, you can just bring down the database using: shutdown abort, as the database could be easily brought to a consistent state by:
startup restrict followed by shutdown immediate.
One should take the backup and/or do whatever else need to be done after the shutdown immediate.
2. For the second situation, the workaround cannot be applied, especially when it's needed to take a cold backup. The database must be closed in a consistent state in order to do this and the consistent state cannot be achieved until all the transactions have completed one way or another (commit/rollback).
As such, it's up to the local personnel to decide what to do, depending on the local needs.
It is very important to realize that: BY SHUTTING DOWN A DATABASE YOU DO NOT SOLVE A PERFORMANCE PROBLEM CAUSED BY A LARGE TRANSACTION. You are only making things worse.
There are situations when the database is brought down even when a large transaction/large recovery is taking place. Then it's brought up again and a new shutodwn is tried. Again, the shutdown immediate is hanging, for a very simple reason - the large recovery is still going on.
At this moment, the v$transaction view is not displaying anything.
Hoever, it is still possible to check the recovery operation by checking the:
select * from v$fast_start_transactions;and/orselect * from v$fast_start_servers;
views. They are the ones that display the recovery status.
As such, when a large transaction is taking place, do not try successive shutdown aborts, startups and shutdown immediate. The hang will reoccur. The database must be consistent when the database is dismounted - performing successive shutdowns/startups is not helping at all, it's only making the recovery even more lengthy.
You should prevent these situations by notifying the users a shutdown will be done and no large operations should be started.
If a large operation has already started at the moment when you want to shutdown immedate, assess what would be faster - rollback the current situation or allow it to complete.
Doc ID: Note:375935.1 Type: HOWTO
Last Revision Date: 02-JUN-2007 Status: MODERATED
In this Document
Goal
Solution
References
--------------------------------------------------------------------------------
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.
Applies to:
Oracle Server - Enterprise Edition - Version: 8.1.7 to 10.2
Information in this document applies to any platform.
Goal
What to do when shutdown immediate appears to hang.
Sometimes, the message 'Waiting for smon to disable tx recovery' is posted in the alert log.
This note only addresses situations when the apparent hang occurs when the database is going from OPEN to MOUNT, which is actually the most common situation.
If the apparent hang occurs at a different step, then this note does not apply.
Solution
The big problem in these situations is that it is noticed only after the shutdown immediate has been issued.
This kind of situation is mostly caused by 2 things:
1. a large query running at the shutdown moment.
2. a large transaction running at the shutdown moment.
Both have to complete in order for the database to be brought down when shutdown immediate is issued.
Actually, the files cannot be closed consistently because of one of the 2 possibilities above and, as such, the transition from OPEN to MOUNT is postponed until the files are closed, which means that either the large query completes or the large transaction is rolled back. This is not a hang, it is the expected behavior.
So, before issuing the shutdown immediate, it would be recommended to check the following views, especially when the database needs to be brought down for a very short period of time:
1. for large queries:
select count(*) from v$session_longops where time_remaining>0;
2. for large transactions:
select sum(used_ublk) from v$transaction;
A result greater than 0 for the first query and a large value returned for the second one would mean a relatively long time to wait until the shutdown immediate completes.
For the second situation, please also check step 9 in Note 117316.1 to "guestimate" the time to rollback the transactions.
1. For the large queries situation, when the shutdown immediate is hanging, you can just bring down the database using: shutdown abort, as the database could be easily brought to a consistent state by:
startup restrict followed by shutdown immediate.
One should take the backup and/or do whatever else need to be done after the shutdown immediate.
2. For the second situation, the workaround cannot be applied, especially when it's needed to take a cold backup. The database must be closed in a consistent state in order to do this and the consistent state cannot be achieved until all the transactions have completed one way or another (commit/rollback).
As such, it's up to the local personnel to decide what to do, depending on the local needs.
It is very important to realize that: BY SHUTTING DOWN A DATABASE YOU DO NOT SOLVE A PERFORMANCE PROBLEM CAUSED BY A LARGE TRANSACTION. You are only making things worse.
There are situations when the database is brought down even when a large transaction/large recovery is taking place. Then it's brought up again and a new shutodwn is tried. Again, the shutdown immediate is hanging, for a very simple reason - the large recovery is still going on.
At this moment, the v$transaction view is not displaying anything.
Hoever, it is still possible to check the recovery operation by checking the:
select * from v$fast_start_transactions;and/orselect * from v$fast_start_servers;
views. They are the ones that display the recovery status.
As such, when a large transaction is taking place, do not try successive shutdown aborts, startups and shutdown immediate. The hang will reoccur. The database must be consistent when the database is dismounted - performing successive shutdowns/startups is not helping at all, it's only making the recovery even more lengthy.
You should prevent these situations by notifying the users a shutdown will be done and no large operations should be started.
If a large operation has already started at the moment when you want to shutdown immedate, assess what would be faster - rollback the current situation or allow it to complete.
Subscribe to:
Posts (Atom)
