|
The local_listener init.ora parameter specifies a network name that resolves to an address or address list of Oracle Net local listeners and it is used used ONLY when you have multiple listeners that are running on the same machine as this instance. The LOCAL_LISTENER parameter is a component of the cross instance registration technology for Oracle RAC (Real Application Clusters). Cross instance registration needs the local listener to help manage connections across all database instances for load balancing and failover. The local listener is particularly meaningful for the RAC configuration featured by multiple listeners on cluster nodes. If your Oracle configuration is not RAC enabled, you may as well remove the LOCAL_LISTENER parameter from your spfile in case for default port 1521 . SQL> show parameter local_listener NAME TYPE VALUE ------------ ----------- local_listener string SQL> alter system set local_listener='(ADDRESS = (PROTOCOL=TCP)(HOST=192.168.2.210)(PORT=1521))'; System altered. SQL> alter system register; System altered. To dynamically update the LOCAL_LISTENER parameter, use the SQL statement ALTER SYSTEM SET: ALTER SYSTEM SET LOCAL_LISTENER='LISTENER_PRIM' scope=both sid='*' ; If you set the parameter to null with the statement that follows, then the default local address of TCP/IP, port 1521 is assumed. ALTER SYSTEM SET LOCAL_LISTENER='' example : in local host tnsnames.ora file LISTENER_PRIM = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.129)(PORT = 1521))) suppose we have 2-node cluster: host1 and host2, with VIP address host1-vip and host2-vip respectively.One RAC database (orcl) running on this cluster; instace 1 (orcl1) on host1, and instance 2 (orcl2) on host2 we have listener_host1 running on host1, and listener_host2 running on host2.listener_host1 is considered local listener for orcl1 instance, while listener_host2 is considered remote listener for that same orcl1 instance.similarly, listener_host2 is considered local listener for orcl2 instance, and considered as remote listener for orcl1. |
|
1. Single patch or intrim patch --------- Opatch apply 2. Patchset(100 of patches) BUNDLE PATCH --------- Opatch napply -<Locatio> -id -skip_subset -skip_duplicate 3. Patchset update PSU=CPU(critical patch Update)+ Patchset) Log file for Opatch utility can be found at : $ORACLE_HOME/cfgtoollogs/opatch |
|
You can create local inventory at any location while installing Oracle Home. You need to use -invPtrLoc variable along with runInstaller command and give the location of oraInst.loc. Otherwise the default path assumed for oraInst.loc is /etc/oraInst.loc. ./runInstaller -invPtrLoc /slot/ems2029/appmgr/apps/tech_st/10.1.2/oraInst.loc If you are using central inventory then -invPtrLoc variable is not required. You can also get the detailed view of inventory using following command. In case of detail information it gives which are the files that this patch have touched. $ORACLE_HOME/OPatch/opatch lsinventory -detail -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc |
|
1. You MUST read the Readme.txt file included in opatch file, look for any prereq. steps/ post installation steps or and DB related changes. Also, make sure that you have the correct opatch version required by this patch. 2.Make sure you have a good backup of database. 3. Make a note of all Invalid objects in the database prior to the patch. 4. Shutdown All the Oracle Processes running from that Oracle Home , including the Listener and Database instance, Management agent etc. 5. You MUST Backup your oracle Home and Inventory tar -cvf $ORACLE_HOME $ORACLE_HOME/oraInventory | gzip > Backup_Software_Version.tar.gz 6. Unzip the patch in $ORACLE_HOME/patches 7. cd to the patch direcory and do opatch -apply to apply the patch. 8. Read the output/log file to make sure there were no errors. |
|
I started database in upgrade mode and fired catupgrd.sql : SQL> startup upgrade ORACLE instance started. Total System Global Area 6413680640 bytes Fixed Size 2160112 bytes Variable Size 1946159632 bytes Database Buffers 4429185024 bytes Redo Buffers 36175872 bytes Database mounted. Database opened. SQL> @catupgrd.sql DOC>####################################################################### DOC>####################################################################### DOC> DOC> The first time this script is run, there should be no error messages DOC> generated; all normal upgrade error messages are suppressed. DOC> DOC> If this script is being re-run after correcting some problem, then DOC> expect the following error which is not automatically suppressed: DOC> DOC> ORA-00001: unique constraint () violated DOC># FROM registry$database * ERROR at line 2: ORA-00942: table or view does not exist This error is related to timezone file which must be version 4 for Oracle version 11g.If timezone is not version 4 than patch needs to be applied. Query to check timezone file is: SQL> select * from v$timezone_file; FILENAME VERSION ———— ———- timezlrg.dat 4 SQL> select * from v$timezone_file; FILENAME VERSION ———— ———- timezlrg.dat 4 So I had correct version.I remember applying patch before upgrade.I got lucky because patch existed for version 10.2.0.3. If there is no patch for your Oracle versions than patch can be download for similar version and applied manually. Instructions are below: 1. Download the identified patch. 2. Unzip the patch, and locate the 2 files timezone.dat and timezlrg.dat in the “files/oracore/zoneinfo” directory of the uncompressed patch (or from the relevant .jar file of a patchset). If there is also a readme.txt in this location then make a note of this as well. 3. Backup your existing files in $ORACLE_HOME/oracore/zoneinfo – THIS CAN BE VITAL, DO NOT SKIP. note: Before going on with step 4, make sure the current files are not in use. On Windows the files will simply refuse to be removed when the are in use. On Unix replacing the files whilst they are in use can cause the files to become corrupt. Use the fuser command before replacing the files to make sure they are not in use. 4. Copy the 2 .dat files and possibly the readme.txt file that were found in step 2 into the $ORACLE_HOME/oracore/zoneinfo directory. 5. Restart the database (in case of installation on a database), or restart the client applications (in case of client install). Note that the database did not need to be down before the time zone files were applied, but it does need to be restarted afterwards. |
|
When nodes of the database in a cluster can’t communicate with each other, they modify the data blocks and may continue to process independently. If more than one instance modify the same block, locking or synchronization of the blocks of the data does not occur and it may happen that the blocks get overwritten by others in the cluster. This process is called split brain. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|