Oracle Database Appliance X7-2S、X7-2M、およびX7-2-HAのデプロイ、更新、および管理に関する既知の問題は次のとおりです:
odacliを使用することはできません。/etc/security/limits.confには、カスタム環境の場合でもデフォルトのエントリが含まれています。odacli update-repositoryジョブが失敗し、patch-name.zipファイルが/tmpディレクトリに存在しません。/opt/oracle/dcs/bin/にある2つのdcscli.jarファイルのため、ODACLIは機能しません。--localオプションはサポートされません。oakcli validate -aとoakcli validate -cは、仮想化されたプラットフォーム上でいくつかのエラーを返します。cleanup.plスクリプトを実行すると、DCS-10001:Internal error encountered: Fail to start hand shakeという次のエラー・メッセージが表示されます。Oracle ACFSとOracle ASMのデータベースが同じOracleホームに存在する場合、パッチ適用後に起動できないことがあります。
これは、Oracle ASMベースのデータベースが初めて起動する前にOracle ACFSデータベースが起動したときに発生します。 これは、データベースのホーム・パッチまたはOracleバイナリの再リンク直後にのみ発生します。 Oracle ASMデータベースの前に起動する非ASMデータベースでは、非ASMデータベースは問題なく起動しますが、Oracle ASMデータベースの起動後に次のエラーが発生する可能性があります:
ORA-27140: attach to post/wait facility failed ORA-27300: OS system dependent operation:invalid_egid failed with status: 1 ORA-27301: OS failure message: Operation not permitted ORA-27302: failure occurred at: skgpwinit6 ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1006 (asmadmin)
Oracle Database homeにパッチを適用する前に、ASM以外のデータベースにOracle ASMディスク・グループの依存性を追加することで、このエラーを回避できます。
Oracle ASMディスク・グループの依存性を追加するには、次のステップを実行します:
すべてのステップをOracleホームの所有者またはユーザーとして実行します。 環境をGIホームに設定します。
レビューするデータベースを決定します:
$ /opt/oracle/oak/bin/oakcli show databases
現在の構成をOracle ACFSデータベースごとに確認します:
crsctl stat res ora.DBName.db -p | grep DEPENDENCIES | grep uniform:global
何も返されなければ、次のステップに進みます。
そのデータベースのホーム環境を設定した後、依存関係を更新します:
srvctl modify database -db DBName -diskgroup DATA
アップデートを確認します:
crsctl stat res ora.DBName.db -p | grep DEP | grep uniform:global
変更には次のものが含まれている必要があります:
START_DEPENDENCIES=hard(uniform:global:ora.DATA.dg,ora.redo.datastore.acfs,ora.data.datastore.acfs,ora.reco.datastore.acfs,ora.flash.flashdata.acfs) weak(type:ora.listener.type,global:type:ora.scan_listener.type,uniform:ora.ons,global:ora.gns) pullup(global:ora.DATA.dg,ora.redo.datastore.acfs,ora.data.datastore.acfs,ora.reco.datastore.acfs,ora.flash.flashdata.acfs)
ハードウェア・モデル
Oracle Database Applianceのサポート対象のすべてのモデル
回避策
すべてのOracle ACFSデータベースを再起動します。
この問題は、Oracleバグ25795974および28058830によって追跡されます。
特定の構成変更が加えられていない場合、Oracle Database Applianceの仮想化されたプラットフォームでパフォーマンスに大きな影響を与える可能性があります。
仮想化されたプラットフォームでは、デフォルト・スケーリング・ガバナー機能(scaling_governor)がパフォーマンス・モードの代わりにオンデマンドに設定され、CPUクロック・スピードの低下によりスタックの安定性の問題が発生します。
ハードウェア・モデル
Oracle Database Appliance仮想プラットフォーム
回避策
dom0にscaling governor、max_cstate、max grant表フレームを明示的に指定します。
/etc/default/grubファイルにcmd行オプションcpufreq=xen:performance max_cstate=1 gnttab_max_frames=256を追加します。
GRUB_CMDLINE_XEN="dom0_mem=max:4096MM allowsuperpage extra_guest_irqs=256,2048 nr_irqs=2048 dom0_vcpus_pin dom0_max_vcpus=20 cpufreq=xen:performance max_cstate=1 gnttab_max_frames=256 "
GRUB (GRand Unified Boot Loader)ファイルを次のように変更します:
非X7-2ハードウェア・モデルの場合:
# grub2-mkconfig -o /boot/grub2/grub.cfg
X7-2ハードウェア・モデルの場合:
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
ノードを再起動します。
cmd行が有効であることを確認します:
# xenpm get-cpuidle-states|grep "Max possible C-state" Max possible C-state: C1 # xenpm get-cpufreq-para|grep current_governor current_governor: performance
この問題は、Oracle Bug#28057749で追跡されます。
Oracle Database Applianceの特定のハードウェア・モデルでは、NVMeデバイスの電源がオフになるとノードが再起動します。
Oracle Automatic Storage Management Filter Driver (Oracle ASMFD)を構成したOracle Database Applianceでは、NVMeデバイスの電源がオフになるとノードが再起動します。
ハードウェア・モデル
Oracle Database Appliance X7-2S, X7-2M, X6-2S, X6-2M, X6-2L
回避策
なし。
このバグは、Oracle Bug#28090492によって追跡されます。
Microsoft EdgeおよびMicrosoft Internet Explorer Webブラウザで、Oracle Appliance ManagerのWebコンソールが正しく表示されない。
モデル
Oracle Database Appliance X7-2-HA, X7-2S, X7-2M, X6-2S, X6-2M, X6-2L
回避策
Webコンソールにアクセスするには、Google ChromeまたはFirefoxを使用します。
この問題は、Oracle Bug#27028446によって追跡されます。
Oracle Appliance Manager Webコンソールから保存されたデータベース・バックアップ・レポートからデータベースをリカバリするためにodacliを使用することはできません。
モデル
Oracle Database Appliance X7-2-HA, X7-2S, X7-2M, X6-2S, X6-2M, X6-2L
回避策
Webコンソールではなく、odacliで保存されたバックアップ・レポートを使用して、odacli recover-databaseコマンドでデータベースをリカバリします。
この問題は、Oracle Bug#27742604で追跡されます。
12.2.0.1 Oracle Databaseのホームを最新のパッチセットにパッチする際にエラーが発生しました
既存の12.1.0.2データベースをパッチ済みのOracle Databaseホームにアップグレードする場合、12.2.0.1 Oracle Databaseホームを最新のパッチにパッチしようとすると、アップグレード・エラーが発生することがあります。
モデル
Oracle Database Appliance X7-2-HA, X7-2S, X7-2M, X6-2S, X6-2M, X6-2L, X5-2, X4-2, X3-2, V1
回避策
1月18日の12.2クローンを使用して新しい12.2 Oracle Databaseホームを作成するか、バグ24923080のパッチをパッチ適用された12.2.0.1 Oracle Databaseホームに手動で適用してから、アップグレードを試みます。
この問題は、Oracle Bug#27983436で追跡されます。
両方のノードを12.2.1.4.0にローリングまたはローカル・パッチした後、リポジトリはノード0または1上でオフラインまたは不明な状態になります。
コマンドoakcli start repo <reponame>が次のエラーで失敗します:
OAKERR8038 The filesystem could not be exported as a crs resource OAKERR:5015 Start repo operation has been disabled by flag
モデル
Oracle Database Appliance X7-2-HA、X6-2-HA、X5-2、X4-2、X3-2、およびV1。
回避策
任意のノードのoda_baseにログインし、次の2つのコマンドを実行します:
oakcli enable startrepo -node 0 oakcli enable startrepo -node 1
これらのコマンドはリポジトリを起動し、オンラインで利用できるようにします。
この問題は、Oracle Bug#27539157によって追跡されます。
クラスタ・レディ・サービス(CRS)が停止または再起動された場合、リポジトリおよび仮想マシンを停止する前にエラーが発生する可能性があります。
リポジトリ・ステータスは不明で、リポジトリと仮想マシンを停止する前にCluster Ready Services (CRS)を停止または再起動すると、High Availability Virtual IPがオフラインになります。
ハードウェア・モデル
Oracle Database Appliance HAモデルX7-2-HA、X6-2-HA、X5-2、X4-2、X3-2、V1
回避策
次の手順を実行します。
# /u01/app/GI_version/grid/bin/srvctl start havip -id havip_0
dom0のoakVmAgent.pyプロセスを停止します。
dom0リポジトリのマウントでlazy unmountオプションを実行します:
umount -l mount_points
この問題は、Oracle Bug#20461930によって追跡されます。
構成ファイル/etc/security/limits.confには、カスタム環境の場合でもデフォルトのエントリが含まれています。
カスタム環境では、単一のユーザーがグリッドとオラクルの両方に構成されている場合、イメージのデフォルトのグリッド・ユーザー・エントリは/etc/security/limits.confファイルから削除されません。
モデル
Oracle Database Appliance X7-2-HA、X7-2S、およびX7-2M
回避策
この問題は機能には影響しません。 手動で/etc/security/limits.confファイルを編集し、無効なエントリを削除します。
この問題は、Oracle Bug#27036374によって追跡されます。
データベースが実行されていない場合、Oracle Database 12.1から12.2へのアップグレードは失敗します。
モデル
Oracle Database Appliance X7-2-HA、X7-2S、およびX7-2M
回避策
アップグレードを実行する前にデータベースを手動で起動してください。
この問題は、Oracle Bug#27054542によって追跡されます。
odb36データベース・シェイプで作成されたオンライン・トランザクション処理(OLTP)、インメモリー(IMDB)およびディシジョン支援サービス(DSS)データベースの場合、PGAおよびSGA値は正しく表示されません。
odb36シェイプで作成されたOLTPデータベースの場合、以下の問題があります:
sga_targetは144 GBの代わりに128 GBに設定されています
pga_aggregate_targetは72 GBではなく64 GBに設定されています
odb36の形で作成されたDSSデータベースの場合、以下の問題があります:
sga_targetは72 GBではなく64 GBに設定されています
pga_aggregate_targetは144 GBの代わりに128 GBに設定されています
Odb36シェイプで作成されたIMDBデータベースの場合、以下の問題があります:
sga_targetは144 GBの代わりに128 GBに設定されています
pga_aggregate_targetは72 GBではなく64 GBに設定されています
inmmory_sizeは72 GBではなく64 GBに設定されています
モデル
Oracle Database Appliance X7-2-HA、X7-2S、およびX7-2M
回避策
手動でPGAおよびSGAサイズをリセット
この問題は、Oracle Bug#27036374によって追跡されます。
odacli update-repositoryジョブが失敗し、patch-name.zipファイルが/tmpディレクトリに存在しません。
リポジトリを更新すると、更新プログラムはコピーしたファイルを検証できず、ジョブは失敗します。 次のようなエラーが表示されます:
CS-10001:Internal error encountered: /tmp/oda-sm-12.2.1.2.0-171124-GI-12.2.0.1.zip does not exist in the /tmp directory.
ハードウェア・モデル
X7-2M、X7-2-HA、X6-2S、X6-2M、およびX6-2Lからなる群より選択される、請求項1に記載の方法。
回避策
無効なnull_null認証キーがZooKeeperにあります。 無効なキーを削除し、各ノードでdcsagentを再起動して、コマンドodacli update-repository を実行します。
ZooKeeperの/binディレクトリに移動します。
# cd /opt/zookeeper/bin
飼い主とつながる。
# ./zkCli.sh
すべての認証キーを一覧表示します。
# ls /ssh-auth-keys
無効なキーを削除します。
# rmr /ssh-auth-keys/null_null
飼い葉桶でやめろ。
quit
各ノードでdcsagentを再起動します。
/opt/oracle/dcs/bin/restartagent.sh
コマンドodacli update-repository を実行します。
opatchのタイムゾーンの問題により、dbhomeパッチの更新が失敗することがあります。
ジョブの詳細には、次のようなエラーが表示されます:
DCS-10001:Internal error encountered: run datapatch after bundlePatch application on the database home dbhomeID
ハードウェア・モデル
Oracle Database Appliance X7-2S、X7-2M、X7-2-HA、X6-2S、X6-2M、およびX6-2L
回避策
/u01/app/oracle/product/*/*/inventory/ContentsXML/comps.xmlファイルを開きます。
4文字のタイムゾーン(TZ)情報を検索します。
たとえば、HADTとHASTです。
それらのファイルのバックアップをとります。
4文字のタイムゾーンを3文字のタイムゾーンに変換します。
たとえば、HADTとHASTをHSTに変換します。
パッチdbhome。
異なるバージョンのディレクトリ/opt/oracle/dcs/bin/にある2つのdcscli.jarファイルのため、ODACLIは機能しません。
ODA CLIコマンドは機能しません。
odacli: '/opt/oracle/dcs/bin/dcscli-2.4.*-SNAPSHOT.jar' is not an odacli command.
ハードウェア・モデル
Oracle Database Appliance X7-2-HA、X7-2S、X7-2M、X6-2S、X6-2M、およびX6-2L
回避策
/opt/oracle/dcs/binディレクトリに移動します。
ls dcscli-*
CLI jarファイルが2つあるかどうかを確認します。
古いCLI jarファイルを削除します。
この問題は、Oracle Bug#27807116で追跡されます。
Oracle Database 12.2.1.2の問題により、内部エラーCRS-01019が発生することがあります: OCRサービスが終了しました。 これが発生すると、Cluster Ready Servicesデーモン(crsd)が停止します。
ハードウェア・モデル
Oracle Database Appliance X7-2-HA、X7-2S、X7-2M、X6-2S、X6-2M、およびX6-2L
回避策
CRSデーモンを再起動します。
crsを停止します。
# crsctl stop crs -f
crsを開始します。
# crsctl start crs -wait
この問題は、Oracle Bug#27060167によって追跡されます。
仮想化されたプラットフォームにパッチを当てると、--localオプションはサポートされません。
仮想化プラットフォーム上でOracle Database ApplianceをRelease 12.1.2.xからRelease 12.2.1.xにパッチすると、--localオプションを使用して単一ノードにパッチを適用しようとするとエラーになります。
# oakcli update -patch 12.2.1.2.0 --server --local ERROR: -local is not supported for server patching, on VM systems.
ハードウェア・モデル
Oracle Database Appliance X7-2-HA
回避策
次のコマンドを使用して、両方のノードにパッチを適用するOracle Database Applianceのソフトウェアを更新します。
# oakcli update -patch 12.2.1.4.0 --server
コマンドoakcli validate -aとoakcli validate -cは、仮想化されたプラットフォーム上でいくつかのエラーを返します。
1つの例外を除いて、validateコマンドのオプションは、Oracle Database Appliance 12.2.1.1.0リリースではサポートされていません。
注意:
コマンドoakcli validate -c storagetopologyがサポートされています。ハードウェア・モデル
Oracle Database Appliance X7-2-HA仮想化プラットフォーム。
回避策
回避策はありません。
この問題は、Oracle Bug#27022056および27021403によって追跡されます。
cleanup.plスクリプトを実行すると、次のエラー・メッセージが表示されます。 : DCS-10001:Internal error encountered: Fail to start hand shake。
問題を再現するステップは次のとおりです:
最初のノード(Node0)でcleanup.plを実行します。 クリーンアップ・スクリプトが終了するまで待ってから、ノードを再起動します。
2番目のノード(Node1)でcleanup.plを実行します。 クリーンアップ・スクリプトが終了するまで待ってから、ノードを再起動します。
両方のノードを起動したら、コマンド行インタフェースを使用してNode0のジョブをリストします。 内部エラーが表示されます。
# odacli list-jobs DCS-10001:Internal error encountered: Fail to start hand shake to localhost:7070
ハードウェア・モデル
Oracle Database Appliance X7-2-HA
回避策
dcsagentを起動する前に、両方のノードの動物園のステータスを確認します:
/opt/zookeeper/bin/zkServer.sh status
単一ノード環境の場合、ステータスは次のようになります。: リーダー、フォロワ、またはスタンドアロン。
cleanup.plスクリプトを実行した後、Node0でdcsagentを再起動します。
# initctl stop initdcsagent # initctl start initdcsagent
Oracle Database 12.2.0.1グリッド・インフラストラクチャ(GI)を使用して11.2.0.4データベースを作成すると、Oracle Enterprise Manager DBコンソールを構成するオプションが無効になります。
12.2.0.1 GIを使用して11.2.0.4データベースを作成すると、Enterprise Manager Control (emctl)コマンドライン・ユーティリティとEnterprise Manager Configuration Assistant (emca)に関する問題が発生します。
ハードウェア・モデル
Oracle Database Appliance X7-2-HA、X7-2S、X7-2M、X6-2S、X6-2M、およびX6-2Lは、12.2.0.1 GIを使用しています。
回避策
データベースの作成後、Oracle Enterprise Manager DBコンソールを手動で構成してください。
アプライアンスがマルチ・ノード・システムの場合は、両方のノードでステップを実行します。 この例では、マルチ・ノード・システムを想定しています:
ご使用の環境に応じて、次のようにdbconsole.rspレスポンス・ファイルを作成します。
ご使用の環境のクラスタ名を取得するには、コマンド$GI_HOME/bin/cemutlo -nを実行
DB_UNIQUE_NAME=db_unique_name SERVICE_NAME=db_unique_name.db_domain PORT=scan listener port LISTENER_OH=$GI_HOME SYS_PWD=admin password DBSNMP_PWD=admin password SYSMAN_PWD=admin password CLUSTER_NAME=cluster name ASM_OH=$GI_HOME ASM_SID=+ASM1 ASM_PORT=asm listener port ASM_USER_NAME=ASMSNMP ASM_USER_PWD=admin password
コマンドを実行して、レスポンス・ファイルを使用してdbcontrolを構成します。 コマンドはエラーで失敗します。 ステップ4の出力のステップを使用します。
$ORACLE_HOME/bin/emca -config dbcontrol db -repos create -cluster -silent -respFile dbconsole.rsp Error securing Database Control. Database Control has not been brought-up on nodes node1 node2 Execute the following command(s) on nodes: node1 node2 1. Set the environment variable ORACLE_UNQNAME to the Database unique name. 2. /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emctl config emkey -repos -sysman_pwd Password for SYSMAN user -host node -sid Database unique name 3. /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emctl secure dbconsole -sysman_pwd Password for SYSMAN user -host node -sid Database unique name 4. /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emctl start dbconsole To secure Em Key, run /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emctl config emkey -remove_from_repos -sysman_pwd Password for SYSMAN user
viエディタを使用して$ORACLE_HOME/bin/emctlを開き、CRS_HOME=をCRS_HOME=/u01/app/12.2.0.1/gridに変更
ステップ2のemcaによって報告されたステップを適切な値で実行します。
$ORACLE_HOME/bin/emca -reconfig dbcontrol -silent -cluster -EM_NODE node0 host -EM_NODE_LIST node1 host -DB_UNIQUE_NAME db_unique_name -SERVICE_NAME db_unique_name.db_domain
$ORACLE_HOME/bin/emca -reconfig dbcontrol -silent -cluster -EM_NODE node1 host -EM_NODE_LIST node1 host -DB_UNIQUE_NAME db_unique_name -SERVICE_NAME db_unique_name.db_domain
viエディタを使用して$ORACLE_HOME/bin/emctlを開き、CRS_HOME=をCRS_HOME=/u01/app/12.2.0.1/gridに変更
dbコンソールの構成状況を確認します。
# /u01/app/oracle/product/11.2.0.4/dbhome_1/bin/emctl status agent - https://public IP for Node0:1158/em - https://public IP for Node1:1158/em