Oracle RAC Opatch auto的时候为什么不打到Rac database home上
Oracle版本:Oracle Rac 11.2.0.3之前打了11.2.0.3.9的补丁集,Rac装上还没正式用,所以就干脆再打到最新的11.2.0.3.11补丁集。
先交代环境:
操作系统:AIX 7.1
Oracle版本:Oracle Rac 11.2.0.3
之前打了11.2.0.3.9的补丁集,Rac装上还没正式用,所以就干脆再打到最新的11.2.0.3.11补丁集。
今日在前段时间新装的两套Rac打最新的psu,同样使用opatch auto的方式来打psu,但是其中一套Rac是连同Rac和Grid一起patch,,而另一套是只patch Grid的补丁集。很郁闷,两套rac的crsconfig_params是基本一样的,两套Rac的相关配置都是我一手安装配置的,为什么会有如此多偏差?
如下是Rac和Grid一同patch的那套Rac:
root@HDB01:/oraapp/oracle/backup>/oraapp/grid/gridhome/OPatch/opatch auto /install/psu -ocmrf /home/grid/grid.rsp
Executing /oraapp/grid/gridhome/perl/bin/perl /oraapp/grid/gridhome/OPatch/crs/patch11203.pl -patchdir /install -patchn psu -ocmrf /home/grid/grid.rsp -paramfile /oraapp/grid/gridhome/crs/install/crsconfig_params
This is the main log file: /oraapp/grid/gridhome/cfgtoollogs/opatchauto2014-09-28_15-07-56.log
This file will show your detected configuration and all the steps that opatchauto attempted to do on your system:
/oraapp/grid/gridhome/cfgtoollogs/opatchauto2014-09-28_15-07-56.report.log
2014-09-28 15:07:56: Starting Clusterware Patch Setup
Using configuration parameter file: /oraapp/grid/gridhome/crs/install/crsconfig_params
Stopping RAC /oraapp/oracle/product/11.2.0/dbhome_1 ...
Stopped RAC /oraapp/oracle/product/11.2.0/dbhome_1 successfully
patch /install/psu/17592127/custom/server/17592127 apply successful for home /oraapp/oracle/product/11.2.0/dbhome_1
patch /install/psu/18522512 apply successful for home /oraapp/oracle/product/11.2.0/dbhome_1
Stopping CRS...
Stopped CRS successfully
patch /install/psu/17592127 apply successful for home /oraapp/grid/gridhome
patch /install/psu/18522512 apply successful for home /oraapp/grid/gridhome
Starting CRS...
CRS-4123: Oracle High Availability Services has been started.
Starting RAC /oraapp/oracle/product/11.2.0/dbhome_1 ...
Started RAC /oraapp/oracle/product/11.2.0/dbhome_1 successfully
opatch auto succeeded.
root@DB01:/oraapp/oracle/backup>su - grid
如下是只patch 了 Grid的那套Rac:
root@ODB01:/install/psu>/oraapp/grid/gridhome/OPatch/opatch auto /install/psu -ocmrf /home/grid/grid.rsp
Executing /oraapp/grid/gridhome/perl/bin/perl /oraapp/grid/gridhome/OPatch/crs/patch11203.pl -patchdir /install -patchn psu -ocmrf /home/grid/grid.rsp -paramfile /oraapp/grid/gridhome/crs/install/crsconfig_params
This is the main log file: /oraapp/grid/gridhome/cfgtoollogs/opatchauto2014-09-28_15-08-19.log
This file will show your detected configuration and all the steps that opatchauto attempted to do on your system:
/oraapp/grid/gridhome/cfgtoollogs/opatchauto2014-09-28_15-08-19.report.log
2014-09-28 15:08:19: Starting Clusterware Patch Setup
Using configuration parameter file: /oraapp/grid/gridhome/crs/install/crsconfig_params
Stopping CRS...
Stopped CRS successfully
patch /install/psu/17592127 apply successful for home /oraapp/grid/gridhome
patch /install/psu/18522512 apply successful for home /oraapp/grid/gridhome
Starting CRS...
CRS-4123: Oracle High Availability Services has been started.
opatch auto succeeded.
root@ODB01:/install/psu>
通过查看Mos文档:(Doc ID 1479651.1)得知,HDB中是有数据库存在的(即通过dbca等形式创建数据库的),而ODB上并没有数据库DB的存在。
ps:这时突然想起来,前段时间确实在HDB上建立过数据库,并做了一些数据迁移做测试。。。(愚钝啊)
opatch的时候oracle在发现没有数据库database注册到OCR中,因此只是patch了Grid。
如下:通过Mos提供的命令发现HDB上CRS中确实有ora.hdb.db的存在:
grid@HDB01:/home/grid>crsctl stat res -p -w "TYPE = ora.database.type"|egrep '^NAME|^ORACLE_HOME'
NAME=ora.hdb.db
ORACLE_HOME=/oraapp/oracle/product/11.2.0/dbhome_1
ORACLE_HOME_OLD=
NAME=ora.hdb.db
ORACLE_HOME=/oraapp/oracle/product/11.2.0/dbhome_1
ORACLE_HOME_OLD=
grid@HDB01:/home/grid>
而在ODB上,次命令下去无任何输出,查看一下/etc/oratab文件,确实未发现除ASM之外的其他数据库:
grid@ODB01:/home/grid>crsctl stat res -p -w "TYPE = ora.database.type"|egrep '^NAME|^ORACLE_HOME'
grid@SRMBODB01:/home/grid>
可以通过以下命令来另外给Rac patch 补丁:
As root user, execute the following command:
opatch auto
Oracle 单实例 从32位 迁移到 64位 方法
在CentOS 6.4下安装Oracle 11gR2(x64)
Oracle 11gR2 在VMWare虚拟机中安装步骤
Debian 下 安装 Oracle 11g XE R2
本文永久更新链接地址:

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

AI Hentai Generator
Générez AI Hentai gratuitement.

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

L'article discute de l'utilisation de l'instruction ALTER TABLE de MySQL pour modifier les tables, notamment en ajoutant / abandon les colonnes, en renommant des tables / colonnes et en modifiant les types de données de colonne.

L'article discute de la configuration du cryptage SSL / TLS pour MySQL, y compris la génération et la vérification de certificat. Le problème principal est d'utiliser les implications de sécurité des certificats auto-signés. [Compte de caractère: 159]

L'article traite des stratégies pour gérer de grands ensembles de données dans MySQL, y compris le partitionnement, la rupture, l'indexation et l'optimisation des requêtes.

L'article traite des outils de GUI MySQL populaires comme MySQL Workbench et PhpMyAdmin, en comparant leurs fonctionnalités et leur pertinence pour les débutants et les utilisateurs avancés. [159 caractères]

L'article discute de la suppression des tables dans MySQL en utilisant l'instruction TABLE DROP, mettant l'accent sur les précautions et les risques. Il souligne que l'action est irréversible sans sauvegardes, détaillant les méthodes de récupération et les risques potentiels de l'environnement de production.

L'article discute de la création d'index sur les colonnes JSON dans diverses bases de données comme PostgreSQL, MySQL et MongoDB pour améliorer les performances de la requête. Il explique la syntaxe et les avantages de l'indexation des chemins JSON spécifiques et répertorie les systèmes de base de données pris en charge.

L'article discute de l'utilisation de clés étrangères pour représenter les relations dans les bases de données, en se concentrant sur les meilleures pratiques, l'intégrité des données et les pièges communs à éviter.

L'article discute de la sécurisation MySQL contre l'injection SQL et les attaques brutales à l'aide de déclarations préparées, de validation des entrées et de politiques de mot de passe solides (159 caractères)
