Installing Oracle 10g R2 on Linux 64 bit(Centos 6)

Installing Oracle 10g R2 on Linux 64 bit(Centos 6)
Need these RPM’s otherwise you will get this error when running the installer
/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory

• yum install libXp.i686
• yum install libXt.i686
• yum install libXtst.i686
• yum install libXp-devel.i686

Oracle GoldenGate DDL setup

Cấu hình DDL:

$cd $GGS_HOME

$sqlplus / as sysdba

SQL> @marker_setup 

SQL> alter session set recyclebin=OFF;

SQL> @ddl_setup

SQL> @role_setup

SQL> grant ggs_ggsuser_role to ggs_owner;

SQL> @ddl_enable

SQL> @ddl_pin GGS_OWNER

SOURCE:

Edit params ./GLOBALS

CHECKPOINTTABLE GGS_OWNER.GGS_CHECKPOINT

GGSCHEMA GGS_OWNER

Edit params mgr

PORT 7809

PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS

PURGEMARKERHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 5

PURGEDDLHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 5

GGSCI> dblogin userid ggs_owner, password xxxx

GGSCI> info checkpointtable

GGSCI> add checkpointtable

GGSCI> edit param eddl

EXTRACT EDDL

EXTTRAIL ./dirdat/ed

USERID ggs_owner, PASSWORD xxxx

DDL INCLUDE MAPPED OBJNAME “FLEXLIVE.*”

DDLOPTIONS ADDTRANDATA, REPORT

TABLE FLEXLIVE.*;

GGSCI> add extract eddl, tranlog, begin now

GGSCI> add exttrail ./dirdat/ed, extract eddl, megabytes 100

GGSCI> edit param pddl

EXTRACT PDDL

RMTHOST <hostname>, MGRPORT 15001, COMPRESS

RMTTRAIL ./dirdat/pd

PASSTHRU

TABLE FLEXLIVE.*;

GGSCI> add extract pddl, exttrailsource ./dirdat/ed

GGSCI> add rmttrail ./dirdat/pd, extract pddl, megabytes 100

Target

GGSCI> dblogin userid ggs_owner, password xxxx

GGSCI> info checkpointtable

GGSCI> add checkpointtable

GGSCI> edit param rddl

REPLICAT RDDL    

DISCARDFILE ./dirrpt/rddl.dsc, PURGE

ASSUMETARGETDEFS

USERID ggs_owner, PASSWORD xxxx

DDL INCLUDE MAPPED

MAP FLEXLIVE.*, TARGET FLEXLIVE.*;

GGSCI> add replicat rddl, exttrail ./dirdat/pd

Check:

GGSCI> stats eddl, total

Delete Trace file

Crontab -> run $GGS_HOME/ddl_cleartrace

How to increase SESSION initialization parameter

ORA-00018 maximum number of sessions exceeded
Cause: All session state objects are in use.
Action: Increase the value of the SESSIONS initialization parameter.

How to increase SESSION initialization parameter:

1. Login as sysdba
 sqlplus / as sysdba
 
2. Check Current Setting of Parameters
 sql> show parameter sessions
 sql> show parameter processes
 sql> show parameter transactions

3. If you are planning to increase "sessions" parameter you should also plan to increase 
"processes and "transactions" parameters.
A basic formula for determining  these parameter values is as follows:
  processes=x
  sessions=x*1.1+5
  transactions=sessions*1.1
  
4. These paramters can't be modified in memory. You have to modify the spfile only 
(scope=spfile) and bounce the instance.
 sql> alter system set processes=500 scope=spfile;
 sql> alter system set sessions=555 scope=spfile;
 sql> alter system set transactions=610 scope=spfile;
 sql> shutdown abort
 sql> startup 

OPatch Principle

Rolling Patch - OPatch Support for RAC (Doc ID 244241.1)

APPLIES TO: Oracle Database - Enterprise Edition - Version 9.0.1.0 to 12.1.0.1 [Release 9.0.1 to 12.1] Information in this document applies to any platform. PURPOSE This note is to describe the current support of OPatch for Real Application Clusters. Before reading opatch RAC Support, you should be familiar with single-instance OPatch processing. For more information about OPatch, please refer to Note 189489.1 - Oracle Data Server Interim Patch Installation (OPatch)  For more information about Oracle Clusterware (CRS) Rolling Upgrades, please refer to Note 338706.1 Also, refer to: note 1339140.1 - FAQ: OPatch/Patch Questions/Issues for Oracle Clusterware (Grid Infrastructure or CRS) and RAC Environments SCOPE This document is intended for DBAs, System Administrators and Oracle Support Engineers who are going to apply Oracle Interim Patche(s) on RAC environment. DETAILS 1 - RAC Patching methods OPatch supports 3 different patch methods on a RAC environment: Patching RAC as a single instance (All-Node Patch) In this mode, OPatch applies the patch to the local node first, then propagates the patch to all the other nodes, and finally updates the inventory. All instances must be down during the whole patching process. Patching RAC using a minimum down-time strategy (Min. Downtime Patch) In this mode, OPatch patches the local node, asks users for a sub-set of nodes, which will be the first subset of nodes to be patched. After the initial subset of nodes are patched, Opatch propagates the patch to the other nodes and finally updates the inventory. The downtime would happen between the shutdown of the second subset of nodes and the startup of the initial subset of nodes patched. Patching RAC using a rolling strategy - No down time (Rolling Patch) With this method, there is no downtime. Each node would be patched and brought up while all the other nodes are up and running, resulting in no disruption of the system. Rolling patching strategy incur no downtime, however, some rolling patches may incur downtime due to post-installation steps, i.e. running sql scripts to patch the actual database. Please refer to patch readme to find out whether post-installation steps requires downtime or not. 2 - Flow diagrams All-Node Patch . Shutdown all Oracle instances on all nodes . Apply the patch to the RAC home on all nodes . Bring all instances up Minimum downtime . Shutdown the Oracle instance on node 1  . Apply the patch to the RAC home on node 1  . Shutdown the Oracle instance on node 2  . Apply the patch to the RAC home on node 2  . Shutdown the Oracle instance on node 3  . At this point, instances on nodes 1 and 2 can be brought up . Apply the patch to the RAC home on node 3  . Startup the Oracle instance on node 3 Rolling patch (no downtime) . Shutdown the Oracle instance on node 1  . Apply the patch to the RAC home on node 1  . Start the Oracle instance on node 1  . Shutdown the Oracle instance on node 2  . Apply the patch to the RAC home on node 2  . Start the Oracle instance on node 2  . Shutdown the Oracle instance on node 3  . Apply the patch to the RAC home on node 3  . Start the Oracle instance on node 3 3 - How does OPatch select which method to use? To be eligible as a rolling patch, the patch needs to meet certain criterias, which are determined by Oracle developers. In order to be applied in a "rolling fashion", the patch must be designated as a "rolling updatable patch" or simply "rolling patch". The algorithm used to decide which method is going to be used is the following:        If (users specify minimize_downtime)               patching mechanism = Min. Downtime        else if (patch is a rolling patch)               patching mechanism = Rolling             else                   patching mechanism = All-Node 4 - Availability of rolling patches When patches are released, they have a tag as "rolling" or "not rolling" patch. While most patches can be applied in a rolling fashion, some patches can not be applied in this fashion. Patches that could potentially be installed on rolling fashion include:    . Patches that do not affect the contents of the database.     . Patches that are not related to the RAC internode communication infrastructure.     . Patches that change procedural logic and do not modify common header definitions of kernel modules. This includes client side patches that only affect utilities like export, import, sql*plus, sql*loader, etc.  Only individual patches -- not patch sets -- will be “rollable”. It should also be noted that a merge patch of a “rolling patch” and an ordinary patch will not be a “rolling patch”.  From 9.2.0.4 onwards, all patches released will be marked as a "rolling" or "not rolling patch", based on defined set of rules. Patches previously released are packaged as "not rolling". Because the set of rules currently defined are very conservative, patches released as "not rolling patches", either before and after 9.2.0.4, may be eligible to be re-released as "rolling patches", after analysis from Oracle Development.    If you plan to apply a patch that is marked as "not rolling" and want to check if is possible to take advantage of the rolling patch strategy, please contact Oracle Support. 5 - How to determine if a patch is a "rolling patch" or not? As database user execute the following:     - 9i or 10gR1: opatch query -is_rolling     - 10gR2: opatch query -all  [unzipped patch location] | grep rolling     - 10gR2 on Windows: opatch query -all [unzipped patch location] | findstr rolling     - Later 10gR2 or 11g: opatch query -is_rolling_patch [unzipped patch location] The command may not work if unzipped patch location has more than one patch sub-directory, example output while checking CPU patches: Failed to load the patch object.  Possible causes are:   The specified path is not an interim Patch shiphome   Meta-data files are missing from the patch area   Patch location = /home/oracle/stage/8836308   Details = Input metadata files are missing. Patch Location "/home/oracle/stage/8836308" doesn't point to a valid patch area. OPatch failed with error code 75 Please refer to patch readme to find out whether the patch is rolling patch or not.  6 - Current Limitations Patching with Shared File System Currently OPatch treats Shared File System, like CFS, as a single-instance patch.  It means that OPatch will blindly patch files under a given ORACLE_HOME knowing that other nodes will pick up the changes via the Shared File System. Unfortunately, this means that OPatch cannot take advantage of a rolling patch on a Shared File System environment; all nodes must be down throughout the patching process. Patching one node at time The Opatch strategies discussed above (All-Node, Min. Down-Time, and Rolling) presumes that all nodes will be patched at the same time. Additionally, each node can be patched individually, at different times, using the "-local" key word, which will patch only the local node.