Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1のデプロイ、更新、および管理に関する既知の問題は次のとおりです:
Oracle Database Appliance 12.2.1.2を使用してサーバーをプロビジョニング、再イメージング、またはパッチ適用した後も、フラッシュ・ディスク・グループは再起動後にマウントされません。
# oakcli update -patch 12.2.1.2 --server **************************************************************************** ***** For all X5-2 customers with 8TB disks, please make sure to ***** ***** run storage patch ASAP to update the disk firmware to "PAG1". ***** **************************************************************************** INFO: DB, ASM, Clusterware may be stopped during the patch if required INFO: Both Nodes may get rebooted automatically during the patch if required Do you want to continue: [Y/N]?: y INFO: User has confirmed for the reboot INFO: Patch bundle must be unpacked on the second Node also before applying the patch Did you unpack the patch bundle on the second Node? : [Y/N]? : y Please enter the 'root' password : Please re-enter the 'root' password: INFO: Setting up the SSH ..........Completed ..... ... ... INFO: 2017-12-26 00:31:22: -----------------Patching ILOM & BIOS----------------- INFO: 2017-12-26 00:31:22: ILOM is already running with version 3.2.9.23r116695 INFO: 2017-12-26 00:31:22: BIOS is already running with version 30110000 INFO: 2017-12-26 00:31:22: ILOM and BIOS will not be updated INFO: 2017-12-26 00:31:22: Getting the SP Interconnect state... INFO: 2017-12-26 00:31:44: Clusterware is running on local node INFO: 2017-12-26 00:31:44: Attempting to stop clusterware and its resources locally Killed # Connection to server.example.com closed.
Oracle高可用性サービス、クラスタ対応サービス、クラスタ同期サービス、およびイベント・マネージャはオンラインです。 ただし、Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)データベースを作成しようとすると、エラーが発生: flash space is 0。
ハードウェア・モデル
Oracle Database Appliance X5-2、X6-2-HA、およびX7-2 HA SSDシステムが含まれます。
回避策
Oracle ACFSデータベースを作成する前に、FLASHディスクグループを手動でマウントします。
GRID所有者として以下のステップを実行します:
グリッドOSユーザーとして環境変数を設定します:
on node0 export ORACLE_SID=+ASM1 export ORACLE_HOME= /u01/app/12.2.0.1/grid
sysasmとしてASMインスタンスにログオン
$ORACLE_HOME/bin/sqlplus / as sysasm
次のSQLコマンドを実行します:
SQL> ALTER DISKGROUP FLASH MOUNT
この問題は、Oracle Bug#27322213で追跡されます。
仮想化されたプラットフォームにパッチを適用すると、 -localオプションはサポートされません。
仮想化されたプラットフォームで、--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 X6-2-HA、X5-2、X4-2、X3-2、およびV1
回避策
次のコマンドを使用して、両方のノードにパッチを適用するOracle Database Applianceのソフトウェアを更新します。
# oakcli update -patch 12.2.1.3.0 --server
Oracle Databaseをバージョン11.2から12.1または12.2にアップグレードしようとすると、アップグレードの事前チェックが失敗し、データベースはアップグレードされません。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1。
回避策
回避策はありません。
この問題は、Oracle Bug#27332396によって追跡されます。
Oracle Database 12.2.1.2の問題により、内部エラーCRS-01019が発生することがあります: OCRサービスが終了しました。 これが発生すると、Cluster Ready Servicesデーモン(crsd)が停止します。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
Oracle Database Appliance X7-2-HA仮想化プラットフォーム
回避策
CRSデーモンを再起動します。
crsを停止します。
# crsctl stop crs -f
crsを開始します。
# crsctl start crs -wait
この問題は、Oracle Bug#27060167によって追跡されます。
データベース・パッチを実行すると、ノード0へのパッチ適用が終了すると、Clusterwareは実行されず、ノード1でのパッチ適用がハングアップします。
Cluster Ready Servicesデーモン(crsd)プロセスが応答しなくなり、Oracle高可用性サービス・デーモン(OHASD)がリソースをクリーンアップできません。 他のプロセスがCPUで完了できず、サーバー上の負荷が増加すると、サーバーは応答しなくなります。 この問題はバグ27060167に関連しています。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
Oracle Database Appliance X7-2-HA
回避策
両方のノードで実行中のcrsdプロセスを停止し、クラスタを再起動します。
この問題は、Oracle Bug#27366345で追跡されます。
データベースを11.2.0.4 dbhomeから12.2.0.1にアップグレードする場合は、Error: No protocol specifiedまたはExit Code 6を受け取ります。
Oracle Database Applianceは、アップグレードを適用する前に事前チェックを実行します。 1つ以上のデータベースのアップグレード前のチェックで手動の介入が必要な警告状態になった場合は、アップグレードを続行する前に、推奨されているように警告に対処する必要があります。 No protocol specifiedまたはExit Code 6エラーを受け取った場合、警告はアップグレード前に解決されませんでした。
終了コード6は、警告を伴う正常な実行を示します。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
Oracle Database Appliance X7-2-HA仮想化プラットフォーム
回避策
なし。
この問題は、Oracle Bug#27381804および27074202によって追跡されます。
Oracle Automatic Storage Management (Oracle ASM)の既知の問題により、REDOディスクグループがOracle Database Release 12.1でマウントされないことがあります。
12.1.0.2.17814 PSU (12.1.2.12)よりも低いOracle ASMデータベースを作成できません。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1。
回避策
回避策はありません。 Oracle Database (Oracle ASM)を使用しているOracle Database 11.2または12.1があり、Oracle Databaseの上位リリースにアップグレードする場合は、少なくともOracle Database Appliance 12.1.2.12.0とDatabase Home 12.1.0.2.170814が必要です。
Oracle Database 11.2または12.1 Oracle ASMのアップグレード・パスは次のとおりです:
Oracle Database Applianceバージョン12.1.2.6.0以降を使用している場合は、データベースをアップグレードする前に12.1.2.12以上にアップグレードしてください。
Oracle Database Applianceバージョン12.1.2.5以前の場合は、12.1.2.6.0にアップグレードしてから、データベースをアップグレードする前に12.1.2.12以上に再度アップグレードしてください。
この問題は、Oracle Bug#21626377、27682997、および21780146で追跡されます。 問題はOracle Database 12.1.0.2.170814で修正されています。
Oracle Database auto patchに問題があるため、空のOracle Databaseホーム(dbhome)にパッチを適用できません。
ERROR: 2017-12-19 18:48:02: Unable to apply db patch on the following Homes : /u01/app/oracle/product/12.1.0.2/dbhome_name
以下は、dbupdateログからの抜粋の例です:
OPATCHAUTO-68036: Topology empty. OPATCHAUTO-68036: The topology was empty, unable to proceed. OPATCHAUTO-68036: Check the log for more information. OPatchAuto failed. opatchauto failed with error code 42
モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1。
回避策
この問題は、dbhomeにデータベースがない場合に発生します。 回避策は、パッチ適用前にデータベースを作成することです。
この問題は、Oracle Bug#27292674および27126871によって追跡されます。
opatchのタイムゾーンの問題により、dbhomeパッチの更新が失敗することがあります。
ジョブの詳細には、次のようなエラーが表示されます:
DCS-10001:Internal error encountered: run datapatch after bundlePatch application on the database home dbhomeID
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
回避策
/u01/app/oracle/product/*/*/inventory/ContentsXML/comps.xmlファイルを開きます。
4文字のタイムゾーン(TZ)情報を検索します。
たとえば、HADTとHASTです。
それらのファイルのバックアップをとります。
4文字のタイムゾーンを3文字のタイムゾーンに変換します。
たとえば、HADTとHASTをHSTに変換します。
パッチdbhome。
この問題は、Oracle Bug#27313653および27331844によって追跡されます。
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 X6-2-HA、X5-2、X4-2、X3-2、およびV1は、12.2.0.1 GIを使用しています。
Oracle Database Appliance 12.2.0.1 GIを使用しているX7-2-HA仮想化プラットフォーム。
回避策
データベースの作成後、Oracle Enterprise Manager DBコンソールを手動で構成してください。
アプライアンスがマルチ・ノード・システムの場合は、両方のノードでステップを実行します。 この例では、マルチ・ノード・システムを想定しています:
ご使用の環境に応じて、次のようにdbconsole.rspレスポンス・ファイルを作成します。
ご使用の環境のクラスタ名を取得するには、コマンド$GI_HOME/bin/cemutlo -nを実行
DB_UNIQUE_NAME=pdb_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
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
この問題は、Oracle Bug#27071994によって追跡されます。
/OVSディレクトリがいっぱいで、ODA_BASEが読み取り専用モードです。
/OVS/ varディレクトリ内のvmcoreファイルにより、/OVSディレクトリ(Dom 0)が100%使用されるようになる可能性があります。 Dom 0がいっぱいになると、ODA_BASEは読み取り専用モードになっているか、起動できません。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1。
Oracle Database Appliance X7-2-HA仮想化プラットフォーム。
回避策
この問題を修正または防止するには、次の手順を実行します:
Dom 0のファイル使用状況を定期的にチェックし、必要に応じてvmcoreファイルをクリーンアップします。
oda_base vm.cfgファイルを編集し、on_crash = 'coredump-restart'パラメータをon_crash = 'restart'に変更します。 特に、ODA_BASEが200 GB(ギガ・バイト)以上のメモリーを使用している場合。
この問題は、Oracle Bug#26121450で追跡されます。
仮想マシン(VM)を起動すると、ドメインが存在しないというエラー・メッセージが表示されます。
VMがOracle Database Appliance 12.1.2.10以前にクローン化した場合、あなたはOracle Database Appliance 12.1.2.11でHVMドメインの仮想マシンを起動することはできません。
この問題は、Oracle Database Appliance 12.1.2.11または古いバージョンでクローン化された他のタイプのVMに新しくクローン作成されたVMには影響しません。 vmテンプレートは12.1.2.11.0で修正されました。
VM(この例ではvm4)を起動しようとすると、出力は次のようになります:
# oakcli start vm vm4 -d
.
Start VM : test on Node Number : 0 failed.
DETAILS:
Attempting to start vm on node:0=>FAILED.
<OAKERR:7007 Error encountered while starting VM - Error: Domain 'vm4' does not exist.>
vm4のvm.cfgファイルの例を次に示します:
vif = [''] name = 'vm4' extra = 'NODENAME=vm4' builder = 'hvm' cpus = '0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23' vcpus = 2 memory = 2048 cpu_cap = 0 vnc = 1 serial = 'pty' disk = [u'file:/OVS/Repositories/odarepo1/VirtualMachines/vm4/68c32afe2ba8493e89f018a 970c644ea.img,xvda,w'] maxvcpus = 2 maxmem = 2048
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
Oracle Database Appliance X7-2-HA仮想化プラットフォーム。
回避策
起動に失敗したVMのvm.cfgファイルから余分な= 'NODENAME=vm_name'行を削除します。
起動に失敗した仮想マシン(vm)のvm.cfgファイルを開きます。
Dom0 : /Repositories/ vm_repo_name /.ACFS/snaps/ vm_name / VirtualMachines/ vm_name
ODA_BASE : /app/sharedrepo/ vm_repo_name /.ACFS/snaps/ vm_name / VirtualMachines/ vm_name
次の行を削除してください: extra=’NODENAME=vmname’。 たとえば、仮想マシンvm4の起動に失敗した場合は、extra = 'NODENAME=vm4'行を削除します。
vif = [''] name = 'vm4' extra = 'NODENAME=vm4' builder = 'hvm' cpus = '0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23' vcpus = 2 memory = 2048 cpu_cap = 0 vnc = 1 serial = 'pty' disk = [u'file:/OVS/Repositories/odarepo1/VirtualMachines/vm4/68c32afe2ba8493e89f018a 970c644ea.img,xvda,w'] maxvcpus = 2 maxmem = 2048
Oracle Database Appliance 12.1.2.11.0で仮想マシンを起動します。
# oakcli start vm vm4
この問題は、Oracle Bug#25943318で追跡されます。
サーバー・パッチを適用してノードを再起動すると、カーネルのバージョンは更新されません。
この問題は、Oracle Database Appliance 12.1.2.11および12.1.2.12で発生します。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
回避策
12.2.1.3.0をリリースするための更新
# oakli update -patch 12.2.1.3.0 --server --local
カーネルのrpmを削除します。
# rpm -e kernel-uek-4.1.12-103.3.8.1.el6uek.x86_64
rpm -ivhを使用してカーネルrpmを手動でインストールします。
kernel-uek-4.1.12-103.3.8.1.el6uek.x86_64
/boot/grub/grub.confを変更して、新しいカーネルからブートします。 default=1をdefault=0に変更してください
# cat /boot/grub/grub.conf
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=5 serial console
default=0
title Oracle Linux Server Unbreakable Enterprise Kernel
(4.1.12-103.3.8.1.el6uek.x86_64)
root (hd0,0)
kernel /vmlinuz-4.1.12-103.3.8.1.el6uek.x86_64 ro root=LABEL=rootfs
tsc=reliable nohpet nopmtimer hda=noprobe hdb=noprobe ide0=noprobe numa=off
console=tty0 console=ttyS0,115200n8 selinux=0 nohz=off crashkernel=256M@64M
loglevel=3 panic=60 ipv6.disable=1 transparent_hugepage=never NODENUM=0
PRODUCT=SUN_SERVER_X4-2 TYPE=V3 pci=noaer
initrd /initramfs-4.1.12-103.3.8.1.el6uek.x86_64.img
title Oracle Linux Server (4.1.12-61.44.1.el6uek.x86_64)
root (hd0,0)
kernel /vmlinuz-4.1.12-61.44.1.el6uek.x86_64 ro root=LABEL=rootfs
tsc=reliable nohpet nopmtimer hda=noprobe hdb=noprobe ide0=noprobe numa=off
console=tty0 console=ttyS0,115200n8 selinux=0 nohz=off crashkernel=256M@64M
loglevel=3 panic=60 ipv6.disable=1 transparent_hugepage=never NODENUM=0
PRODUCT=SUN_SERVER_X4-2 TYPE=V3 pci=noaer
initrd /initramfs-4.1.12-61.44.1.el6uek.x86_64.img
ノードを再起動します。
# uname -r 4.1.12-103.3.8.1.el6uek.x86_64
ノード1に対して繰り返します。
この問題は、Oracle Bug#26887116で追跡されます。
Oracle Database Applianceを更新すると、認識できないトークン・メッセージが/var/log/messagesに表示されます。
Oracle Database Appliance 12.1.2.11.0に更新すると、Oracle VM Serverのバージョンが3.4.3に更新されます。 アップデート後、/var/log/messagesに次のメッセージが表示されます:
Unrecognized token: "max_seq_redisc" Unrecognized token: "rereg_on_guid_migr" Unrecognized token: "aguid_inout_notice" Unrecognized token: "sm_assign_guid_func" Unrecognized token: "reports" Unrecognized token: "per_module_logging" Unrecognized token: "consolidate_ipv4_mask"
これらのパラメータのメッセージは無視できますが、InfiniBand準拠のSubnet ManagerおよびAdministration(opensm)機能には影響しません。 ただし、/var/log/messagesのフラッディングを避けるためにパラメータを削除することをお薦めします。
ハードウェア・モデル
Oracle Database Appliance InfiniBandを使用したX6-2-HAおよびX5-2
回避策
パラメータを削除するには、次の手順を実行します:
パッチ適用後、ベアメタル・デプロイメントの / etc/opensm/opensm.confファイルと仮想化プラットフォーム環境のDom0を更新して、パラメータを削除します。
cat /etc/opensm/opensm.conf | egrep -w 'max_seq_redisc|rereg_on_guid_migr|aguid_inout_notice|sm_assign_guid_func|repo rts|per_module_logging|consolidate_ipv4_mask' | grep -v ^# max_seq_redisc 0 rereg_on_guid_migr FALSE aguid_inout_notice FALSE sm_assign_guid_func uniq_count reports 2 per_module_logging FALSE consolidate_ipv4_mask 0xFFFFFFFF
再起動 ノードを再起動すると、メッセージは表示されません。
この問題は、Oracle Bug#25985258によって追跡されます。
Oracle Database Appliance 12.1.2.11.0に更新した後、ローカル・ディスクへのIOはスタックしてタスクをブロックする可能性があります。
この問題は、Oracle VM 3.4.3を使用している場合、Oracle Linuxバグが原因です。 複数のVLANを使用し、VDISKSを持つすべてのOracle Database Applianceゲスト仮想マシンでこのバグが発生し、IOがハングアップする可能性があります。 この問題は、どのプロセスが停止しているかに応じて、さまざまな形で現れます。 たとえば、ODA_BASEをデプロイした後、untarコマンドを続行できないか、仮想マシンがハングする可能性があります。
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1に、複数のVLANとVDISKSを使用するゲスト仮想マシンが含まれている。
回避策
Oracle Database Appliance X6-2-HAおよびX5-2 Dom0はgrub2を使用します。 これらのモデルでは、次の手順を実行して、両方のノードのdom0にgnttab_max_framesを256に設定します:
次の行を変更して、/etc/default/grubファイルの更新でgnttab_max_framesを増やします:
GRUB_CMDLINE_XEN="dom0_mem=max:4096MM allowsuperpage crashkernel=256M@64M extra_ guest_irqs=256,2048 nr_irqs=2048 dom0_vcpus_pin dom0_max_vcpus=20"
変更後
GRUB_CMDLINE_XEN="dom0_mem=max:4096MM allowsuperpage crashkernel=256M@64M extra_ guest_irqs=256,2048 nr_irqs=2048 dom0_vcpus_pin dom0_max_vcpus=20 gnttab_max_frames=256"
変更に基づいて新しい構成ファイルを作成します。
grub2-mkconfig -o /boot/grub2/grub.cfg
再起動
2番目のノードのDom0でプロセスを繰り返します。
Oracle Database Appliance X4-2、X3-2、およびV1 Dom0はgrub1を使用します。 これらのモデルでは、次の手順を実行して、両方のノードのDom0上のxenハイパーバイザでgnttab_max_framesを256に設定します:
Dom0の/boot/grub/grub.confファイルを開きます。
xen.gzコマンドラインにgnttab_max_frames=256行を追加します。
たとえば、次の行を変更します:
kernel /xen.gz dom0_mem=4096M crashkernel=256M@64M
変更後
kernel /xen.gz dom0_mem=4096M crashkernel=256M@64M gnttab_max_frames=256
再起動
2番目のノードのDom0でプロセスを繰り返します。
この問題は、Oracle Bug#26731461で追跡されます。
高可用性IP (HAIP)アドレスは、Oracle設計システムではサポートされていません。
HAIPアドレスを使用すると、アドレスがサポートされていないことを示すエラー・メッセージがオペレーティング・システムのログに表示されます。
Oracle Database Applianceシステムの起動時に、システム・ログに次のエラー・メッセージが表示されることがあります:
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651622] ** WARNING WARNING WARNING
WARNING WARNING **
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651624] **
**
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651627] ** RDS/IB: Link local address
169.254.165.15 NOT SUPPORTED **
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651629] **
**
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651631] ** HAIP IP addresses should
not be used on ORACLE **
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651632] ** engineered systems
**
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651634] **
**
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651636] ** If you see this message,
Please refer to **
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651638] ** cluster_interconnects in
MOS note #1274318.1 **
Aug 11 15:31:11 odac1n1 kernel: [ 9932.651639]
これらのメッセージは無視できます。 機能は影響を受けません。
ハードウェア・モデル
Oracle Database Appliance X6-2S、X6-2M、X6-2L、X6-2-HA、X5-2、X4-2、X3-2、およびV1
この問題は、Oracle Bug#26623697で追跡されます。
-uオプションが指定されていない場合、node0のネットワーク情報は、一部のodacliコマンドで常に表示されます。
-uオプションが指定されていない場合、コマンドがnode0またはnode1から実行されているかどうかにかかわらず、describe-networkinterface、list-networksおよびdescribe-network odacliコマンドは常にnode0 (デフォルト・ノード)の結果を表示します。
ハードウェア・モデル
Oracle Database Appliance X7-2-HA、X6-2-HA、X5-2、X4-2、X3-2、およびV1
回避策
現在のノードの詳細については、odacliコマンドで-uオプションを指定してください。
この問題は、Oracle Bug#27251239で追跡されます。
odb-01sという形のDSSデータベースを作成しようとすると、次のエラーでジョブが失敗することがあります:
CRS-2674: Start of 'ora.test.db' on 'rwsoda609c1n1' failed CRS-5017: The resource action "ora.test.db start" encountered the following error: ORA-03113: end-of-file on communication channel Process ID: 0 Session ID: 0 Serial number: 0 . For details refer to "(:CLSN00107:)" in "/u01/app/grid/diag/crs/rwsoda609c1n2/crs/trace/crsd_oraagent_oracle.trc".
ハードウェア・モデル
Oracle Database Appliance X6-2-HA、X5-2、X4-2、X3-2、およびV1
回避策
回避策はありません。 代替シェイプを選択してデータベースを作成します。
この問題は、Oracle Bug#27768012によって追跡されます。