In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)06/01 Report--
Execute it on DataGuard first. After all the nodes of DataGuard are upgraded successfully, it will be executed on production. Dg does not need to run the script operation after upgrading. It only needs to be executed in a node of the main database after the patches of the master and backup libraries are finished.
When the master database needs to stop the log transfer to the standby database before upgrading, and the standby database needs to stop the log application.
When the upgrade is completed, check the application of the main and standby libraries.
The core steps are as follows:
1. The master library disables log shipping to the standby library.
two。 Close the standby library, apply patches, but do not execute scripts (catpatch.sql, etc.), start to mount, and do not enable log recovery
3. Close the main library, apply patches, execute scripts (run catpatch/catbundle/catcpu, etc.)
4. Start the main library and reopen log delivery to the standby database
5. Enable log recovery for standby database
6. Check the patch application
* * *
* first, check the main and standby database before upgrading and related operations *
* * *
This patch is Data Guard Standby First Installable-See My Oracle Support Document 1265700.1 Oracle Patch Assurance-Data Guard Standby-First Patch Apply for details on how to remove risk and reduce downtime when applying this patch.
-main database / DG slave database execution before upgrade
Stop transferring logs from the main library first
Alter system set log_archive_dest_state_2=defer
-- for the preparation of the database, see check the database status and role; then prepare the database modification, stop the log application, and close all nodes (see whether the database needs to be stopped according to the patches)
Select inst_id,host_name,instance_name,status from gv$instance
Select inst_id,database_role,switchover_status from gv$database
Recover managed standby database cancel
Shutdown immediate;-check whether the database needs to be stopped according to the patches made
-- Master / slave patches are applied as described in the following steps 12345. Note: you do not need to register after the update of the slave database:
* * *
* second, the following steps are performed on all nodes of RAC in turn *
* * *
1. Confirm the opatch version
Su-oracle
Opatch version-11.2.0.3.6 or above
Su-grid
Opatch version-11.2.0.3.6 or above
two。 Upgrade opatch (if step 1 is not satisfied, perform this step, otherwise ignore)
Su-oracle
Unzip p6880880_112000_Linux-x86-64.zip-d $ORACLE_HOME
Opatch version
Su-grid
Unzip p6880880_112000_Linux-x86-64.zip-d $GI_HOME
Opatch version
* * *
* third, the following steps are performed on all nodes of RAC in turn *
* * *
Play GI PSU
How to Create an OCM Response file to Apply a Patch in Silent Mode-opatch silent (document ID 966023.1)
2.1. Create an OCM file
Su-oracle
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp-no_banner-output / home/oracle/ocm.rsp
Chmod 775 / home/oracle/ocm.rsp
-- Validation of Oracle Inventory (run as GI and DB users respectively)
/ OPatch/opatch lsinventory-detail-oh
$ORACLE_HOME/OPatch/opatch lsinventory-detail-oh $ORACLE_HOME
2.2 stop the EM process (ignore if EM is not installed)
Su-oracle
Emctl stop dbconsole
-- One-off Patch Conflict Detection and Resolution patch conflict detection
How to Use the My Oracle Support Conflict Checker Tool for Patches Installed with OPatch [Video] (document ID 1091294.1)
2.3 upgrade PSU (As root user, execute the following command on each node of the cluster: cannot be executed in parallel)
Su-root
Cd / tmp/patch
Unzip p26030870_112040_Linux-x86-64.zip
Opatch auto / tmp/patch/26030870/26030799-ocmrf / home/oracle/ocm.rsp
Use the opatch tool under GI
* * *
* fourth, OJVM patch upgrade *
* * *
3. OJVM patch upgrade (executed under db)
3.1 check for patch conflicts
$cd / tmp/patch/26030870/26027154
Opatch prereq CheckConflictAgainstOHWithDetail-ph. /
3.2 check the number of database connections, turn off listening, and finally shut down crs (all nodes execute)
-check the pmon process:
Ps-ef | grep pmon
-- check the number of connections, kill connections, and turn off monitoring
Ps-ef | grep LOCAL=NO | grep-v grep | wc-l
Ps-ef | grep LOCAL=NO | grep-v grep | awk'{print $2}'| xargs kill-9
Lsnrctl stop
-- stop crs:
Crsctl stop crs
3.3 apply patches:
Cd / tmp/patch/26030870/26027154
Opatch apply-local
3.4 confirm whether the patch database is applied
Opatch lsinventory
Opatch lspatches
3.5 start the crs of all patched nodes
Crsctl start crs
*
* 5. After the upgrade is successful, execute it on a node in the production (and hit it in a node in the main database, but not in the standby database *
*
-- For an Oracle RAC environment, perform these steps on only one node. (it can be executed on a node in the main database, but not in the slave database, and all the patches in the master and slave libraries have been successfully applied.)
SQL installation is performed after the primary database and all standby databases have the database home binaries patched to the same level .
4.1 Post-upgrade script for Big GI PSU
-- execute catbundle.sql file
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > STARTUP
SQL > @ catbundle.sql psu apply
SQL > QUIT
-- perform a recompilation
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > @ utlrp.sql
-Check the following log files in $ORACLE_BASE/cfgtoollogs/catbundle for any errors:
Catbundle_PSU__APPLY_.log
Catbundle_PSU__GENERATE_.log
-- upgrade RMAN CATALOG (ignore if Oracle Recovery Manager is not used)
Su-oracle
Rman catalog username/password@alias
RMAN > UPGRADE CATALOG
-- Verification: executed under both DB and GI
Opatch lspatches
4.2 Registration operation after OJVM patch upgrade
Install the SQL portion of the patch by running the following command against a single instance environment.
Note: this step is suitable for single instance playing OJVM PSU.
Cd $ORACLE_HOME/sqlpatch/26027154
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > startup upgrade
SQL > @ postinstall.sql
SQL > shutdown
SQL > startup
For the Oracle RAC environment, reload the package on one of the nodes using the following command. Ensure that no other database instance is started on the remote node.
Note: this step requires closing other instances of non-running scripts on rac
Cd $ORACLE_HOME/sqlpatch/26027154
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > STARTUP
SQL > alter system set cluster_database=false scope=spfile
SQL > SHUTDOWN
SQL > STARTUP UPGRADE
SQL > @ postinstall.sql
SQL > alter system set cluster_database=true scope=spfile
SQL > SHUTDOWN
SQL > STARTUP
After installing the SQL portion of the patch, some packages may become invalid. This will be recompiled on access, or you can run utlrp.sql to bring them back to a valid state.
Note: both RAC and single instance need to be executed.
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > @ utlrp.sql
* * *
* if an exception occurs, roll back and stop the upgrade, and analyze the reason *
* * *
Rollback (GI PUS)
Su-root
Opatch auto / tmp/patch/26030799-rollback-ocmrf / home/oracle/ocm.rsp
Rollback registration: note that you need to operate on the rac node that is registered after the patch is completed.
Step 1:Start all database instances running from the Oracle home. For more information, see Oracle Database Administrator's Guide.
Step 2:For each database instance running out of the ORACLE_HOME, connect to the database using SQL*Plus as SYSDBA and run the rollback script as follows:
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > STARTUP
SQL > @ catbundle_PSU__ROLLBACK.sql
SQL > QUIT
In an Oracle RAC environment, the name of the rollback script will have the format catbundle_PSU__ROLLBACK.sql.
Step 3:If the OJVM PSU was applied for a previous GI PSU patch, you may see invalid Java classes after execution of the catbundle.sql script in the previous step. If this is the case, run utlrp.sql to re-validate these Java classes.
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > @ utlrp.sql
Step 4:check
$opatch lsinventory
Rollback (OJVM patch)
Crsctl stop crs
Opatch rollback-id 26027154
Crsctl start crs
Opatch lsinventory
Register after rollback:
The following steps load modified SQL files into the database. For an Oracle RAC environment, perform these steps on only one node.
Step 1:Install the SQL portion of the patch by running the following command for a single instance environment.
Cd $ORACLE_HOME/sqlpatch/26027154
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > startup upgrade
SQL > @ postdeinstall.sql
SQL > shutdown
SQL > startup
For an Oracle RAC environment, reload the packages on one of the nodes using the following commands. Make sure no other instance of the database is up on the remote nodes.
Note: this step requires closing other instances of non-running scripts on rac
Cd $ORACLE_HOME/sqlpatch/26027154
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > STARTUP
SQL > alter system set cluster_database=false scope=spfile
SQL > SHUTDOWN
SQL > STARTUP UPGRADE
SQL > @ postdeinstall.sql
SQL > alter system set cluster_database=true scope=spfile
SQL > SHUTDOWN
SQL > STARTUP
Step 2:After installing the SQL portion of the patch, some packages could become INVALID. This will get recompiled upon access or you can run utlrp.sql to get them back into a VALID state.
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > @ utlrp.sql
* * *
* 7. Enable the slave database after the master and slave database is upgraded successfully, and check the synchronization situation *
* * *
-- after the master database log is successfully applied, modify the master database parameters and slave database application log, and check the synchronization:
Enable the transfer log in the main library first
Alter system set log_archive_dest_state_2=enable
Prepare the library to start and apply the log
Startup
Recover managed standby database using current logfile
Finally, check the synchronization:
Select process, sequence#, status, delay_mins from v$managed_standby
=
* * *
* sample procedure for GI PSU patch upgrade *
* * *
The GI PSU patch can apply GI HOME and DB HOME in a scrolling manner. Note that the location where the patch is downloaded should be the directory shared by GI and db.
1. Check that the opatch tool version of the rac node is greater than or equal to 11.2.0.3.6:
Update the opatch tools under db and GI:
$unzip-d
$/ OPatch/opatch version
Second, configure the response file
Su-oracle
$ORACLE_HOME/OPatch/ocm/bin/emocmrsp-no_banner-output / home/oracle/ocm.rsp
Chmod 775 / home/oracle/ocm.rsp
Third, verify the period of validity
-- Validation of Oracle Inventory (run as GI and DB users respectively)
$ORACLE_HOME/OPatch/opatch lsinventory-detail-oh $ORACLE_HOME
Stop the EM process before patching or rolling back the patch (ignore if EM is not installed)
Su-oracle
/ bin/emctl stop dbconsole
5. Upgrade PSU (As root user, execute the following command on each node of the cluster: cannot be executed in parallel)
-As root user, execute the following command on each node of the cluster:
As root, execute the following command on each node of the cluster:
Note: the location of the PSU patch should be the directory shared by GI and db, and be executed by the opatch tool under GI
$cd
$unzip p27107360_112040_.zip
# opatch auto / 27107360-ocmrf
6. Register the database after upgrade and run the script: for rac, you only need to operate on one node.
-- execute script catbundle.sql
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > STARTUP
SQL > @ catbundle.sql psu apply
SQL > QUIT
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series PSU.
-- compiling failed objects
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > @ utlrp.sql
-- check the log for errors
Catbundle_PSU__APPLY_.log
Catbundle_PSU__GENERATE_.log
-- if you are using rman to restore the directory, do the following:
$rman catalog username/password@alias
RMAN > UPGRADE CATALOG
7. Roll back PSU:
-- root identity execution:
As root user, execute the following command on each node of the cluster.
# opatch auto / 27107360-rollback-ocmrf
Registration after rollback: registration after rollback is performed on the node after patching registration
8.1 Start all database instances running from the Oracle home
8.2 execute script
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > STARTUP
SQL > @ catbundle_PSU__ROLLBACK.sql
SQL > QUIT
8.3 compilation failure object
Cd $ORACLE_HOME/rdbms/admin
Sqlplus / nolog
SQL > CONNECT / AS SYSDBA
SQL > @ utlrp.sql
8.4 Check the log file for any errors.
The log file is found in $ORACLE_BASE/cfgtoollogs/catbundle and is named catbundle_PSU__ROLLBACK_.log where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are error.
8.5 check
$opatch lsinventory
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.