Learning Oracle

Friday, January 23, 2015

ORA-27101: Shared Memory Realm Does Not Exist

Cause: Unable to locate shared memory realm

Action: Verify that the realm is accessible

Solution:

As root user allow the oracle user to lock the SGA into memory by typing:

"setprivgrp dba MLOCK

Thursday, January 22, 2015

Procedure To Restore The Weblogic User Password On EBS 12.2 In Case Of Lost Or Forgotten Password

Applies to: Oracle Applications DBA - Version 12.2 to 12.2.4 [Release 12.2]

"If the Admin Password of an EBS WebLogic Domain is lost or forgotten"

Please follow the below steps:

An EBS WebLogic domain uses NodeManager to control AdminServer and managed server startup. For an EBS WebLogic domain, the NodeManager and WebLogic AdminServer passwords should be same. When changing the password for an EBS domain, care has to be taken to ensure that both the passwords remain the same, or the AD control scripts will not work properly.

If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps should be carried out on the run file system. As described in the final step, an fs_clone operation should then be performed to bring the patch file system into sync.

1. Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.

   A. Connect to the Oracle E-Business Suite instance and source the application tier environment file.

   B. Identify the PIDs of NodeManager, AdminServer, and all running managed servers:

  ps -ef | grep "NodeManager"
  ps -ef | grep "weblogic.Name=AdminServer"
  ps -ef | grep "weblogic.Name=forms-c4ws_server"
  ps -ef | grep "weblogic.Name=forms_server"
  ps -ef | grep "weblogic.Name=oafm_server"
  ps -ef | grep "weblogic.Name=oacore_server"

   C. Kill all these processes, starting with NodeManager and followed by the servers.

2. Back up these folders, then delete them:

   <EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
   <EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
   <EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
   <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties

Where:

   <EBS_DOMAIN_HOME> is the absolute path of the EBS WebLogic domain
   <server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.

  If the password is not reset correctly, the backed up files and folders can be restored.

  Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.

3. Set up a new environment to change the WLS AdminServer password.

   A. Start a new session and connect to the Oracle E-Business Suite instance.

   B. Do NOT source the application tier environment file.

   C. Source the WebLogic domain environment as per the following command:

         $ cd <EBS_DOMAIN_HOME>/bin
         $ source setDomainEnv.sh

   D. Run the following commands:

         $ cd <EBS_DOMAIN_HOME>/security
         $ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password> .

         Note: Do not omit the trailing period ('.') in the above command, to specify the current domain directory.

         Where:

         <wls_adminuser> is the same as the value of context variable s_wls_admin_user
         <wls_admin_new_password> is the new WLS AdminServer password you wish to set.

4. Start AdminServer from the command line. You will be prompted for the WebLogic Server username and password, so that the AdminServer boot.properties file can be generated.

    A. Go to the EBS Domain Home:

        $ cd <EBS_DOMAIN_HOME>

    B. Start AdminServer:

        $ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server

Where:

        <s_nm_jvm_startup_properties> is the same as the value of context variable ss_nm_jvm_startup_properties

    The above command prompts for the WebLogic Server username and password:

Enter username to boot WebLogic server:
        Enter password to boot WebLogic server:

        Provide the same credentials as you provided in Step 3.

5. Change NodeManager password

    A. Log in to the WebLogic Administration console.

    B. Click the Lock & Edit button.

    C. In the left panel, click on the EBS Domain link.

    D. Select the Security tab.

    E. Click on the 'Advanced' link.

    F. Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.

    G. Edit the 'Confirm NodeManager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.

H. Save and activate the changes.

6. Shut down AdminServer from the console. For the first time, AdminServer has to be stopped from the Admin console. Follow these steps:

A. Log in to the WebLogic Administration console.

B. Shut down AdminServer.

7. Set up your environment to start AdminServer again. AdminServer should now be started using the normal AD script, which will also start NodeManager using the new password.

   A. Launch a new session and connect to the Oracle E-Business Suite instance.

   B. Source the application tier environment file.

   C. Start AdminServer with the following command:

       $ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start

8. Start the managed servers. For the first time, all managed servers should be started from the WebLogic Server Admin console. This step will create boot.properties for the respective managed servers. Follow these steps:

    A. Log in to the WebLogic Server Administration Console

    B. Start all managed servers, one at a time

9. Shut down all the managed servers. This is so the new credentials will be picked up at the next startup. Follow these steps:

    A. Log in to the WebLogic Administration Server console.

    B. Shut down all managed servers.

    C. Shut down AdminServer.

10. Shut down NodeManager using the normal AD script.

  $ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop

11. Copy the boot.properties file for all managed servers.

  WebLogic Server native scripts use the boot.properties file from the the folder. The above steps have created the boot.properties file under, which is used by NodeManager. Copy the newly-generated boot.properties file from <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager to <EBS_DOMAIN_HOME>/ servers/<server_name>/security.

  The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.

To start AdminServer:

  $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start

To start the managed servers:

  $ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start

12. The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS domain password on the patch file system:

A. Launch a new session and connect to the Oracle E-Business Suite instance.

B. Source the application tier environment file.

C. Run the command:

      $ adop phase=fs_clone

Known Issues

This section lists any known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments.

Problem: On a multi-node installation with the Forms Services and Batch Processing Services enabled on separate nodes, OAM fails to update the context variables on the Batch Processing Services node.

Solution: Check whether the Listener Service is up on the Forms Services node.If the service is down, start the service using one of the following options:

Start the TNS listener service manually using the following command:

$ $INST_TOP/admin/scripts/adalnctl.sh start <TWO_TASK>

1. Enable the TNS Listener Service by following the steps mentioned earlier.

2. Stop all the application tier services using adstpall.sh
3. Start all the application tier services using adstrtal.sh

RMAN-06429 TARGET Database is not Compatible with this Version of RMAN

RMAN-06438: error executing package DBMS_RCVMAN in TARGET database

    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============
    RMAN-00571: ===========================================================
    RMAN-00554: initialization of internal recovery manager package failed
    RMAN-06429: TARGET database is not compatible with this version of RMAN

Cause:

The relevant message in this case is RMAN-06438 because package DBMS_RCVMAN   in target database is invalid

Solution:

 SQL>@?/rdbms/admin/dbmsrman.sql
 SQL>@?/rdbms/admin/prvtrmns.plb

RMAN upgrade catalog failed with RMAN-06429

Run RMAN command 'upgrade catalog' to upgrade the RMAN recovery catalog schema from 11.2.0.2 to 11.2.0.3, but experienced the following errors, as shown here.

RMAN-06429: RCVCAT database is not compatible with this version of RMAN

RMAN> upgrade catalog;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06441: cannot upgrade catalog - catalog is already newer than this RMAN

Reason: The 'DBMS_RCVMAN' body package is invalid, because there are two synonyms, namely, TDATT and TFATT, that points to two non-existing RMAN tables.

Solution:

Dropped the two synonyms, namely, TDATT and TFATT, and the RMAN command "upgrade catalog" is successfully completed without any errors.

Friday, January 16, 2015

RMAN-06217

RMAN-06217
not connected to auxiliary database with a net service name

Cause: A command that moves files from the target instance to the
auxiliary instance was requested. Such a command requires a
net service name be present in the connect string used to
connect to the auxiliary instance.

Action: Issue a CONNECT AUXILIARY command and include a net serice name
in the connect string. That service name must be valid on
the target instance.

Solution:
rman target sys/<syspwd>@<OrclDBNameCaps>prim1 auxiliary sys/<syspwd>@<OrclDBNameCaps>stby

Wednesday, August 13, 2014

RMAN Restore and Recovery Scenarios

Restore and Recovery Scenarios

Full Database Restore

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore database;

RMAN> recover database;

RMAN> alter database open;

database opened

Tablespace Restore (online)

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> sql 'alter tablespace users offline';

RMAN> restore tablespace users;

RMAN> recover tablespace users;

RMAN> sql 'alter tablespace users online';

* A SYSTEM tablespace cannot be recovered with the database online.

Tablespace Restore (offline)

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore tablespace users;

RMAN> recover tablespace users;

RMAN> alter database open;

database opened

Restoring a Specific Datafile

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore datafile '/oradata/DB1/dbf/users01.dbf';

RMAN> recover datafile '/oradata/DB1/dbf/users01.dbf';

RMAN> alter database open;

database opened

Control File Restoration

Prerequisite: In your rman backup directory determine the latest control file backup.

Default Format: c-nnnnnnnnnn-nnnnnnnn-nn

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup nomount;

RMAN> set dbid = 1184749195

RMAN> restore controlfile from '/oradata/DB1/rman/c-1184749195-20060626-02'

RMAN> alter database mount;

RMAN> restore database;

RMAN> recover database;

RMAN> alter database open resetlogs;

database opened

Database Point-In-Time-Recovery (PITR)

Also known as time-based incomplete recovery.

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore database until time "to_date('09/03/07 13:00:00', 'MM/DD/YY HH24:MI:SS')";

RMAN> recover database until time "to_date('09/03/07 13:00:00', 'MM/DD/YY HH24:MI:SS')";

RMAN> alter database open resetlogs;

database opened

* Make sure you perform a full backup after this operation!

Restore to Another System

Prerequisites

Ideally ensure destination system configured exactly like source.

Same OS version and patch level.

Same drives (C:, D:, S: etc.).

CPU and RAM same or better.

The same version of Oracle is installed on the target system as the source.

Ensure the ORACLE_HOME and ORACLE_SID environment variables are set.

Ensure the listener is running.

Copy RMAN backupset files to the destination system rman directory.

If Windows:

Create the password file.

orapwd file=orapwDB1 password=mypassword

Creates the file %ORACLE_HOME%\dbs\orapwDB1

Copy %ORACLE_HOME%\dbs\orapwDB1 to %ORACLE_HOME%\database.

In some instances of a restore like this it may look for the file here.

Create or start the Windows database instance service.

oradim -new -sid DB1 -intpwd mypassword -startmode MANUAL

Creates the file: %ORACLE_HOME%\database\PWDDB1.ORA

Ensure the drive\path to the admin (adump,bdump,cdump,udump), data and redo directories on the source and destination systems are identical.

Example:

Admin Dump Directories

mkdir C:\oracle\product\10.2.0\admin

mkdir C:\oracle\product\10.2.0\admin\DB1

mkdir C:\oracle\product\10.2.0\admin\DB1\adump

mkdir C:\oracle\product\10.2.0\admin\DB1\bdump

mkdir C:\oracle\product\10.2.0\admin\DB1\cdump

mkdir C:\oracle\product\10.2.0\admin\DB1\udump

Data Directories

mkdir D:\oradata

mkdir D:\oradata\DB1

Redo and Archive Log Directories

mkdir D:\oradata\DB1\recovery1

mkdir D:\oradata\DB1\recovery2

Procedure

Restore SPFILE and Control File

%ORACLE_HOME%\bin\rman target / nocatalog

RMAN> set dbid 161080442

RMAN> startup nomount;

Creates the file: %ORACLE_HOME%\database\hc_db1.dat

RMAN> restore spfile from 'R:\rman\C-161080442-20080313-00';

Creates the file: %ORACLE_HOME%\database\SPFILEDB1.ORA

RMAN> startup force nomount

RMAN> restore controlfile from 'R:\rman\C-161080442-20080313-00';

RMAN> shutdown immediate

RMAN> exit

Restore and Recover the Data

%ORACLE_HOME%\bin\rman target / nocatalog

RMAN> startup mount;

RMAN> restore database;

For a large database this step may take some time.

RMAN> recover database;

If you do not have\need the very last log(s) you can disregard any error messages.

ORA-00310: archived log contains sequence 100; sequence 101 required...

RMAN> alter database open resetlogs;

database opened

RMAN

=====================================================
RMAN Configuration Parameters
=====================================================

Topic : Description of few parameters in the RMAN Configuration settings

CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION OFF; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP OFF; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO %Ff;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE MAXSETSIZE TO UNLIMITED; CONFIGURE SNAPSHOT CONTROLFILE;

Solution:
RMAN CONFIGURATION PARAMETERS

RMAN has several configuration parameters, which are set to their default values when you first use RMAN. Use show all command to see the default values

RMAN>show all;
By using the V$RMAN_CONFIGURATION view you can view the current configuration values of all the RMAN parameter
By using configure command we can change RMAN configuration parameters

Backup Retention Polity

A backup retention policy tells RMAN to consider backups of datafiles and log files obsolete. You can set a retention policy by using either of two methods: the default redundancy option or recovery window

The Redundancy Option

The Redundancy option lets you specify how many copies of the backups you want to retain
The default is one
You set retention policy this way

RMAN>configure retention policy to REDUNDANCY 2;

The previous RMAN command specifies the RMAN keep only two backups of each database files

The Recovery Window Option

The recovery window refers to a time frame in which all backups will be kept, regardless of how many backups are taken you can set recovery window as follows

RMAN>configure retention policy

To recovery window of 14 days
If you set your policy to a erecovery window of 14 days then all the backups less than 14days old would be retained, and all backups older than 14days would be marked for deletion

Default Device Type

The default device for backups is disk; that is RMAN will automatically backup files to file system on you server. If you want to backup to tape, you configure the default device type of sbt

RMAN>configure default device to type to sbt;
If you wish to switch the default device back to disk then
RMAN>configure default device type to disk;

Channel Configuration

An RMAN session must use some kind of a connection to the server to perform backup and recovery work, and channels represent those connection
If you have four channels configured, four connections will be made to target database to open four separate server sessions
The following example configures two channels with channel 1 backup to the backup directory under /test01 and channel 2 backing up to backup directory under /test02

RMAN>configure channel 1 device type disk format e/test01/app/oracle/oradata/backup/%Uf;

RMAN>configure channel 2 device type disk format e/test02/app/oracle/oradata/backup/%Uf;

Degree of Parallelism

When two or more channels are allocated for single backup operation this is reffered to parallelization. The degree of parallelism denotes the number of channels that RMAN open during a backup or recovery. The time taken to complete the backup or recovery will decrease as you increase degree of parallelism

RMAN>configure device type disk parallelism4;

Backup optimization

The backup optimization option ensure that RMAN doesnft perform a file backup if it has already backed up identical versions of the file
RMAN>configure backup optimization ON;

Control File Auto backup