Quantcast
Channel: Doyensys Allappsdba Blog..
Viewing all 1640 articles
Browse latest View live

Encountering Error 20372 While Running adcfgclone appsTier

$
0
0
ERROR - CLONE-20372 Server port validation failed
 
This error is reported in logs when adcfgclone.pl  run for a R12.2.5 appsTier where many instances are running on same server.

SEVERE : Aug 7, 2017 16:36:36 - ERROR - CLONE-20372   Server port validation failed.
SEVERE : Aug 7, 2017 16:36:36 - CAUSE - CLONE-20372   Possible causes were :Ports of following servers - oacore_server3(7214) - were not available.
SEVERE : Aug 7, 2017 16:36:36 - ACTION - CLONE-20372   Provide valid free ports or if those servers are targeted to non admin host, then use temporary port range mechanism.
java.lang.Exception: Error in validating "SERVER_CONFIG" parameters in "moveplan".
        at oracle.as.clone.cloner.component.j2ee.util.J2EEGenericValidationUtil.validateServerConfig(J2EEGenericValidationUtil.java:218)
        at oracle.as.clone.cloner.component.j2ee.config.GenericPasteConfigSteps.getServerConfig(GenericPasteConfigSteps.java:922)
        at oracle.as.clone.cloner.component.j2ee.config.GenericPasteConfigSteps.executeGenericPasteConfig(GenericPasteConfigSteps.java:385)
        at oracle.as.clone.cloner.component.J2EEComponentApplyCloner.doClone(J2EEComponentApplyCloner.java:259)
        at oracle.as.clone.cloner.Cloner.doFinalClone(Cloner.java:63)
        at oracle.as.clone.request.ApplyCloneRequest.applyArchive(ApplyCloneRequest.java:198)
        at oracle.as.clone.request.ApplyCloneRequest._clone(ApplyCloneRequest.java:77)
        at oracle.as.clone.process.CloningExecutionProcess.execute(CloningExecutionProcess.java:131)
        at oracle.as.clone.process.CloningExecutionProcess.execute(CloningExecutionProcess.java:114)
        at oracle.as.clone.client.CloningClient.executeT2PCommand(CloningClient.java:236)
        at oracle.as.clone.client.CloningClient.main(CloningClient.java:124)
oracle.as.t2p.exceptions.FMWT2PPasteConfigException: PasteConfig failed. Make sure that the move plan and the values specified in moveplan are correct.
        at oracle.as.clone.cloner.component.J2EEComponentApplyCloner.doClone(J2EEComponentApplyCloner.java:314)
        at oracle.as.clone.cloner.Cloner.doFinalClone(Cloner.java:63)
        at oracle.as.clone.request.ApplyCloneRequest.applyArchive(ApplyCloneRequest.java:198)
        at oracle.as.clone.request.ApplyCloneRequest._clone(ApplyCloneRequest.java:77)
        at oracle.as.clone.process.CloningExecutionProcess.execute(CloningExecutionProcess.java:131)
        at oracle.as.clone.process.CloningExecutionProcess.execute(CloningExecutionProcess.java:114)
        at oracle.as.clone.client.CloningClient.executeT2PCommand(CloningClient.java:236)
        at oracle.as.clone.client.CloningClient.main(CloningClient.java:124)
SEVERE : Aug 7, 2017 16:36:36 - SEVERE - CLONE-20937  "pasteConfig" operation of J2EE domain failed. Check clone log and error files for more details.
SEVERE : Aug 7, 2017 16:36:36 - ERROR - CLONE-20237   Restoring the sourceid "J2EECOMPONENT@EBS_domain_FLRPRD" has failed.
SEVERE : Aug 7, 2017 16:36:36 - CAUSE - CLONE-20237   An internal operation failed.
SEVERE : Aug 7, 2017 16:36:36 - ACTION - CLONE-20237   Check the clone log for more details.
SEVERE : Aug 7, 2017 16:36:36 - ERROR - CLONE-20218   Cloning is not successful.
SEVERE : Aug 7, 2017 16:36:36 - CAUSE - CLONE-20218   An internal operation failed.
SEVERE : Aug 7, 2017 16:36:36 - ACTION - CLONE-20218   Provide the clone log and error file for investigation.

It seems the ports reported are using by some other instance in the same server.  Searching on support.oracle.com  I found three articles:

EBS 12.2.2.4 RAPID CLONE FAILS WITH ERROR - CLONE-20372 SERVER PORT VALIDATION(Bug ID 20147454)

12.2: N->1 CLONING TO SAME APPS TIER FAILING DUE TO PORT CONFLICT(Bug ID 20389864)

FS_CLONE IS NOT ABLE TO COMPLETE FOR MULTI-NODE SETUP(Bug ID 18460148)

The situation described in the first two bugs is same.  The articles reference each other but don't provide any solution.

Logically thinking, adcfgclone.pl is picking this up from source configuration that is in $COMMON_TOP/clone directory.  So we did grep on subdirectories of $COMMON_TOP/clone:

cd $COMMON_TOP/clone
find . -type f -print | xargs grep 7214

7214 is  the port that failed validation as per logfile.

It is present in

CTXORIG.xml and
FMW/ohs/moveplan.xml
FMW/wls/moveplan.xml

We tried changing the port numbers in CTXORIG.xml and re-tried adcfgclone.pl and it failed again.

So we changed the port numbers of the ports that failed validation in

$COMMON_TOP/clone/FMW/ohs/moveplan.xml and
$COMMON_TOP/clone/FMW/wls/moveplan.xml

cd $FMW_HOME
find . -name detachHome.sh |grep -v Template

The above command returns the detachHome.sh scripts for all the ORACLE_HOMEs inside FMW_HOME.  Executed this to detach all of them.

Removed the FMW_HOME directory

Re-executed
adcfgclone.pl appsTier

It succeeded this time.  Till we get a patch for this bug, we will continue to use this workaround to complete clones.
 
Happy EBS Learning !!

ORA-02056:2PC:k2lcom:bad two-phase command number rdonly from coordremote DBs may be in-doubt

$
0
0
We need to set the below parameter to fix the issue.

alter system set "_clusterwide_global_transactions"=false scope=spfile sid='*';

and restart the RAC cluster.

This should be done on on both source and target if both are on RAC.

ORA-00020: maximum number of processes

$
0
0
To fix the above we need to increase processes initialization value or to find what is using the processes.

How to increase PROCESSES 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 "PROCESSES" parameter you should also plan to increase "sessions 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;

How to apply DB PSU and OJVM PSU in 11.2.0.4 primary and standby DB

$
0
0
1a. Check the invalids
======================
Spool invalid_objects
select owner, object_name, object_type from dba_objects where status = 'INVALID';
spool off

1b. Download the patches
========================
cd /stage/patches
OPatch id :6880880 (if this is not existing already)
Db Patch  : 24732075
OJVM patch: 25434033



2. Shutdown All Instances and listener from production
=======================================================
$sqlplus / as sysdba

sql> shut immediate;
sql> exit.

$ lsnrctl stop

3. Stop the recovery and stop the standby
==========================================
$sqlplus / as sysdba
sql> alter database recover managed standby database cancel; 
sql> shut immediate;
sql> exit;

$ lsnrctl stop

3.Copy and unzip the latest OPATCH to the Oracle home and export the location:
=============================================================================
$ unzip <stage Location> p6880880_*_.zip -d $ORACLE_HOME

$ export PATH=$ORACLE_HOME/OPatch:$PATH

4. check pre-requisites for both PSU patch and OJVM patch
==========================================================
a) Unzip the patch:
-------------------
$ unzip <PATCH_TOP_DIR>/p24732075_*_.zip
$ unzip <PATCH_TOP_DIR>/p25434033_*_.zip

b) Collect the existing patch information in the oracle home.
------------------------------------------------------------
$ opatch lsinventory > before_patch

c) change the patch folder:
--------------------------
$ cd <PATCH_TOP_DIR>/24732075

d) check the Confilict for both patch before applying to the environment.
-------------------------------------------------------------------------
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./

$ cd <PATCH_TOP_DIR>/25434033

e) check the Confilict for both patch before applying to the environment.
-------------------------------------------------------------------------
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./



5. After pre-requisites are meet, run the below command to apply the PSU and OJVM Patch.
=========================================================================================
$ cd <PATCH_TOP_DIR>/24732075

$ opatch apply

$ cd <PATCH_TOP_DIR>/25434033

$ opatch apply

Note : Do the same step from (1b to 5) for standby .

6. Collect the patch information in the oracle home after patching compltetion
==============================================================================

$opatch lsinventory

7.  compare the result with the step 6 and step 4(b) result.
============================================================

8) Bring up the database and listerner and run the post step only in primary
============================================================================
$ lsnrctl start

$sqlplus / as sysdba

sql>startup

PSU Post Step:
--------------
sql> @?/rdbms/admin/catbundle.sql psu apply

OJVM Post step:
--------------

cd $ORACLE_HOME/sqlpatch/25434033
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> startup upgrade
SQL> @postinstall.sql
SQL> shutdown
SQL> startup



=====
9) Compile the invalids.
========================
sqlplus / as sysdba

sql> @?/rdbms/admin/utlrp.sql
Check the invalids are the same as in step 1a.

Note : Do not need to run the step 8 & 9 on the standby site.

10) Check the patch applied information.
=======================================
$sqlplus / as sysdba
sql> SET linesize 200 pagesize 200
col action_time FOR a28
col version FOR a10
col comments FOR a30
col action FOR a10
col namespace FOR a12
col BUNDLE_SERIES format a15
SELECT comments  FROM registry$history;
Patch 25434033 applied
PSU 11.2.0.4.170418

11) Bring up the standby instance.
==================================
$ lsnrctl start

$ sqlplus / as sysdba

sql>startup nomount;
sql> alter database mount standby database;
sql> alter database open read only;

sql>alter database recover managed standby database disconnect from session;


12) Switch some logs and see, if they are in sync.
==================================================
$ sqlplus / as sysdba

sql> alter system switch logfile;

sql > exit

13) Identify the standby sync using standby alert log.
========================================================
14) Check the patch applied information in the standby.
========================================================
$sqlplus / as sysdba
sql> SET linesize 200 pagesize 200
col action_time FOR a28
col version FOR a10
col comments FOR a30
col action FOR a10
col namespace FOR a12
col BUNDLE_SERIES format a15
SELECT comments  FROM registry$history;
Patch 25434033 applied
PSU 11.2.0.4.170418

ORA-00106: cannot startup/shutdown database when connected to a dispatcher

$
0
0
We have two solution for this.

1. Connect locally that is without service name.
set ORACLE_SID=<your sid>
set ORACLE_HOME=...
sqlplus "/ as sysdba"
or sqlplus "sys as sysdba"

2. Define an entry in the tnsnames.ora with (SERVER=DEDICATED) in the CONNECT_DATA section and connect using this name.

ORA-00055: Maximum Number of DML locks exceeded

$
0
0
Solution:

The number of DML Locks is set by the initialization parameter DML_LOCKS. If this value is set to low (which it is by default) you will get this error. Try to find the issue and if it is temporary we can leave it as such. Other wise we need to increase the value of DML_LOCKS. Some times this occurs at the moment of peak load in database.
Change in the parameter file (initSID.ora) For Example: dml_locks = 200

Cleanup steps for cluster node removal for failed CRS on a particular node in cluster installation

$
0
0
Deinstall method:

Step 1:

On all cluster nodes, run the following command as the "root" user.

perl $GRID_HOME/crs/install/rootcrs.pl -verbose -deconfig -force

Step 2:

On the last cluster node, run the following command as the "root" user.

perl $GRID_HOME/crs/install/rootcrs.pl -verbose -deconfig -force -lastnode

Another method:

If the deinstall utility doesn't works,remove the below commands to remove the failed CRS installation.

If the cluster node removal for failed CRS install on a particular node,

rm -rf /u01/app/oraInventory/*
rm -rf /u01/app/11203/grid/*
rm -rf /u01/app/grid/*
rm -rf /u01/app/oracle/product/11203/racdb/* 
rm -rf /etc/oracle/* 
rm /etc/oraInst.loc 
rm /etc/oratab 
rm /var/tmp/.oracle/*

*** cluster node was deleted and can’t be rebooted ***


RAC/Clusterware installation files were deleted at OS level from a cluster node by running all or any or all of the following rm commands


Warning!!! Due to high volume of data, got out of memory exception Please retry with scalable option or modify the Data template to run in scalable mode.

$
0
0
ERROR:
Warning!!! Due to high volume of data, got out of memory exception
Please retry with scalable option or modify the Data template to run in scalable mode.
 

Cause:
While running a BI publisher report we normally uses XDODTE executable which is nothing but a java executable, It runs on a JVM. Sometimes when the JVM is overloaded with process it throws below error.

Solution:

This issue can be resolved by running the concurrent program with jvm options

Navigate

System Administration-->concurrent-->Program-->Define

and change the option for a suitable jvm value such as

-Xss2560k -Xmx2560m

 




 

Autoinvoice Fails With "Error calling raaprx()" or "Error calling fdprep() - RAXAVR"

$
0
0
ERROR:

Autoinvoice Fails With "Error calling raaprx()" or "Error calling fdprep() - RAXAVR"


Cause

This issue is addressed in Bug 22445687 REW: AUTOINVIOCE: ERROR CALLING FDPREP() - RAXAVR

Solution

1. Bug Summary

  1. Description
    Autoinvoice: ERROR CALLING FDPREP() - RAXAVR

  2. Workaround
    None
  3. Resolution
     nulltermed the errbuf as below:
    errbuf[0] = '\0'; before call to fdprep at multiple places

2. Fixed Files

R12.AR.A:
ad_apply_patch.xml 120.3.12000000.2
raaprx.lc 120.3.12000000.2

R12.AR.B:
raaprx.lc 120.3.12010000.2

R12.AR.C:
raaprx.lc 120.3.12020000.2

3. Recommended Patches

R12.AR.A, B and C: Patch 22445687

4. Solution Steps

  1. Ensure that you have taken a backup of your system before applying the recommended patch.
  2. Apply the patch in a test environment.
  3. Confirm the file versions listed above, by navigating to the directory where the file is and using:
    strings -a |grep '$Header'
  4. Retest the issue.
  5. Migrate the solution as appropriate to other environments.
  6. If the patch for your release is unavailable for download or needs a password, or if you experience any issues applying this patch, please contact the E-Business Patching Community for assistance.

 

























 



ORA-03137: TTC protocol internal error : [3149] [] [] [] [] [] [] [] ORA-03149: Invalid Oracle error code

$
0
0
ERROR:

ORA-03137: TTC protocol internal error : [3149] [] [] [] [] [] [] []
ORA-03149: Invalid Oracle error code


SOLUTION:


The fix for unpublished Bug 14489591 is a client fix, so the fix should be applied to the client as used by the application.

  • Check if the client is 32 or 64-bit to download the correct version of the patch
    This can be done by executing following commands on the 10.1.2 or 10.1.3 ORACLE_HOME:
    • ls -l $ORACLE_HOME/lib/libclntsh.so.10.1
    • file libclntsh.so.10.1
    • ls -l $ORACLE_HOME/bin/sqlplus
    • file $ORACLE_HOME/bin/sqlplus

1. For the client as used by EBS, apply patch 14489591 on top of the 10.1.0.5 RDBMS client included in 10.1.2/10.1.3 (Forms and Reports) Oracle Home

 
2. Relink 'frmweb':
  a) Bring down the application services (or) We can also execute adopmnctl.sh stopall

  b) $cd $ORACLE_HOME/forms/lib32
      $make -f ins_forms.mk installl

      If the location is not found(-bash: cd: /oracle/PROD/apps/tech_st/10.1.3/forms/lib32: No such file or directory), then try to use below instead or contact the Forms Support team:
       $source $INST_TOP/ora/10.1.3/SID_hostname.env
       $cd $ORACLE_HOME/forms/lib
       $make -f ins_forms.mk installl

  c) Bring up the application services

  Remark: Instead of bringing down the application services, you can also execute "adopmnctl.sh stopall"
 

Error "No Invoice Line" When Creating Refunds in Receivables

$
0
0
ERROR:

Error "No Invoice Line" When Creating Refunds in Receivables

SOLUTION: 

1. Bug Summary

  1. Description
    ERROR WHILE TRYING TO REFUND A RECEIPT : NO INVOICE LINES

  2. Workaround
    None
  3. Resolution
    Added the code to pass the accounting level distributions to AP Interface for CM refund otherwise pass the application line information for Receipt refund

2. Fixed Files

R12.AR.A:
ad_apply_patch.xml 120.3.12000000.2
ARXVREFB.pls 120.3.12000000.18

R12.AR.B:
ARXVREFB.pls 120.3.12010000.17

R12.AR.C:
ARXVREFB.pls 120.14.12020000.5

3. Recommended Patches

R12.AR.B and C: Patch 22304981


4. Solution Steps

  1. Ensure that you have taken a backup of your system before applying the recommended patch.
  2. Apply the patch in a test environment.
  3. Confirm the file versions listed above, by navigating to the directory where the file is and using:
    strings -a |grep '$Header'
  4. Retest the issue.
  5. Migrate the solution as appropriate to other environments.
  6. If the patch for your release is unavailable for download or needs a password, or if you experience any issues applying this patch, please contact the E-Business Patching Community for assistance.
 

APP-FND-01630: Cannot open file L6977176.log for appending

$
0
0
ERROR:
 APP-FND-01630: Cannot open file L6977176.log for appending

CAUSE:
 FDPFOP encountered an error when attempting to open file L6977176.log for appending.


SOLUTION:

Check the permission in the Directory where you are trying to do FNDLOAD upload.

touch file1

       If you are able to create the file and have the required permission and still the issue exists,perform the below steps.

Note 1:

In R12. Context File is no more in $APPL_TOP/admin directory.It has been moved to $INST_TOP/appl/admin directory

Note 2:
Check env variables APPLTMP and APPLPTMP
$env|grep TMP
APPLTMP=/product/app/TESTAPPS/inst/apps/TESTAPPS_NodeApps/appltmp
APPLPTMP=/ora_backup/u0001
REPORTS_TMP=/product/app/TESTAPPS/inst/apps/TESTAPPS_NodeApps/temp
NodeApps(TESTAPPS)  /product/app/TESTAPPS/inst/apps/TESTAPPS_NodeApps/admin/install

Change the value of the APPLTMP and APPLPTMP environment variable in context file to point to new Directory and run autoconfig to make changes saved.Also make sure
utl_file_dir has the same value.


sqlplus / as sysdba (On DB Tier)
show parameter utl_file_dir;

Step 1:Run cmclean.sql
>sqlplus apps

SQL*Plus: Release 11.2.0.4.0 Production on Wed Aug 4 19:44:32 2017

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options


SQL> @cmclean.sql

Note:CMCLEAN.SQL is the Non Destructive Script to Clean Concurrent Manager Tables

Step 2:Bounce the middle Tier applications services 

ORA-02020: too many database links in use

$
0
0
ERROR:

ORA-02020: too many database links in use

CAUSE: 

 The current session has exceeded the INIT.ORA open_links maximum.\

SOLUTION:

SQL> show parameter open_links;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------
open_links                           integer     4
open_links_per_instance              integer     4

Action:
Increase the open_links limit, or free up some open links by committing or rolling back the transaction and canceling open cursors that reference remote databases.


SQL> alter system set open_links_per_instance=10 scope=spfile;
SQL> alter system set open_links=10 scope=spfile;

and then, bounce the database. 

ORA-65049: Creation Of Local User Or Role Is Not Allowed In CDB$ROOT

$
0
0
ORA-65049: Creation Of Local User Or Role Is Not Allowed In CDB$ROOT

PROBLEM:

While creating a user in root container in the multitenant database, Got error ORA-65049.



SQL> show con_name

CON_NAME
——————————
CDB$ROOT
SQL> create user TESTUSER identified by TESTUSER container=current;
create user TESTUSER identified by TESTUSER container=current
*
ERROR at line 1:
ORA-65049: creation of local user or role is not allowed in CDB$ROOT

SOLUTION:

Normal user i.e local user can’t be created in root container. Only common users starting with C## can only be created in root container. And use either container=ALL or dont mention anything for container.

SQL>  create user C##TESTUSER identified by TESTUSER;

User created.

ORA-38760: This Database Instance Failed To Turn On Flashback Database

$
0
0
ORA-38760: This Database Instance Failed To Turn On Flashback Database

PROBLEM:

While starting the database, got below error.

SQL> startup
ORACLE instance started.

Total System Global Area 1.2549E+10 bytes
Fixed Size 12155024 bytes
Variable Size 6744442736 bytes
Database Buffers 5771362304 bytes
Redo Buffers 21397504 bytes
Database mounted.
ORA-38760: This database instance failed to turn on flashback database.

SOLUTION:

1. Check the alert log:

Errors in file /oracle/app/oracle/diag/rdbms/db12cr2/DB12CR2/trace/DB12CR2_rvwr_2776.trc:
ORA-38701: Flashback database log 1 seq 1 thread 1: "/oracle/app/oracle/product/12.2.0/dbhome_1/dbs/arch/FRA/DB12CR2/flashback/o1_mf_djfp4fjd_.flb"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 7
2017-05-01T09:43:24.075852+03:00
WARNING: Cannot open the flashback thread for this instance due to the above error.
WARNING: Flashback thread open failed - to resolve this, either correct the reported error or turn off database flashback.
2017-05-01T09:43:24.076337+03:00
Database mounted in Exclusive Mode
Lost write protection disabled
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Completed: ALTER DATABASE   MOUNT

2. Check the flashback_mode of the database.

SQL> select name,flashback_on from v$database;

NAME      FLASHBACK_ON
--------- ------------------
DBATEST   YES ----- > FLASHBACK IS ENABLED

From the alert log, it is clear that flashback mode is enabled in the database and someone has mistakenly deleted flashback log physically.

So, to fix this issue, the only solution is to disable the flashback mode and open the database.


SQL> select name,open_mode from v$database;

NAME      OPEN_MODE
--------- --------------------
DB12CR2   MOUNTED

SQL> alter database flashback off;

Database altered.

SQL> alter database open;

Database altered.

ORA-00392: Log 7 Of Thread 1 Is Being Cleared, Operation Not Allowed

$
0
0
ORA-00392: Log 7 Of Thread 1 Is Being Cleared, Operation Not Allowed

PROBLEM:


While cloning a database from rman backup . After completion of cloning, when I did RESETLOG it failed with ORA-00392 error.

RMAN> alter database open resetlogs;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql statement command at 06/25/2017 16:05:27
ORA-00392: log 7 of thread 1 is being cleared, operation not allowed
ORA-00312: online log 7 thread 1: ‘/archive/CLONEDB/redo7a.log’
ORA-00312: online log 7 thread 1: ‘/archive/CLONEDB/redo7b.log’

SOLUTION:

First, check the status of REDO LOGS

RMAN> select group#,thread#,status from v$log;

    GROUP#    THREAD# STATUS
---------- ---------- ----------------
         5          1 CLEARING
         6          1 CLEARING
         7          1 CLEARING_CURRENT   ---------->>>
         8          1 CLEARING
         9          2 CLEARING_CURRENT   --------->>>>>
        10          2 CLEARING
        11          2 CLEARING
        12          2 CLEARING


Group 7 and 9 have status CLEARING_CURRENT. So clear them manually.

RMAN> alter database clear logfile group 7;

Statement processed

RMAN> alter database clear logfile group 9;

Statement processed

RMAN> select group#,thread#,status from v$log;

    GROUP#    THREAD# STATUS
---------- ---------- ----------------
         5          1 CLEARING
         6          1 CLEARING
         7          1 CURRENT
         8          1 CLEARING
         9          2 CURRENT
        10          2 CLEARING
        11          2 CLEARING
        12          2 CLEARING

8 rows selected


 Now no group is in clearing_current mode. Lets do resetlog again.



RMAN> alter database open resetlogs;

Database altered

ORA-01623: Log 3 Is Current Log For Instance Cannot Drop

$
0
0
ORA-01623: Log 3 Is Current Log For Instance Cannot Drop

PROBLEM:

While dropping a redolog group, got below error.

SQL> alter database drop logfile group 3;
alter database drop logfile group 3
*
ERROR at line 1:
ORA-01623: log 3 is current log for instance CLONEDB (thread 1) - cannot drop
ORA-00312: online log 3 thread 1: '/archive/CLONEDB/redo03.log'

SOLUTION:

First, check the status of the redolog group.


select l.group#, l.thread#,
f.member,
l.archived,
l.status,
(bytes/1024/1024) fsize
from
v$log l, v$logfile f
where f.group# = l.group#
order by 1,2

GROUP# THREAD# MEMBER                                                       ARCHIVED   STATUS     Size (MB)
------ ------- ---------------------------------------------------------------------- ---------- ---------- ---------
     2       1 /archive/CLONEDB/redo02.log                                  YES        ACTIVE            50
     3       1 /archive/CLONEDB/redo03.log                                  NO         CURRENT           50  ---- >>>>
     4       1 /archive/CLONEDB/redo04.log                                  YES        UNUSED            50


 Here the status of the redolog group, which are trying to drop is CURRENT. i.e This implies that the redo log is active. The redo log could be open or closed.

So we need to make the status of the redolog to INACTIVE. Switch logfile multiple times, till the status becomes INACTIVE.


SQL> alter system switch logfile;

SQL>  @log_member

GROUP# THREAD# MEMBER                                                        ARCHIVED   STATUS     Size (MB)
------ ------- ---------------------------------------------------------------------- ---------- ---------- ---------
     2       1 /archive/CLONEDB/redo02.log                                  YES        INACTIVE          50
     3       1 /archive/CLONEDB/redo03.log                                  YES        ACTIVE            50
     4       1 /archive/CLONEDB/redo04.log                                  NO         CURRENT           50

SQL> alter system switch logfile;

SQL>  @log_member

GROUP# THREAD# MEMBER                                                        ARCHIVED   STATUS     Size (MB)
------ ------- ---------------------------------------------------------------------- ---------- ---------- ---------
     2       1 /archive/CLONEDB/redo02.log                                  NO         CURRENT           50
     3       1 /archive/CLONEDB/redo03.log                                  YES        INACTIVE          50 ---->>>>>>>>>>>>>
     4       1 /archive/CLONEDB/redo04.log                                  YES        INACTIVE          50


As the status is INACTIVE now, we can drop it.


SQL> alter database drop logfile group 3;

SQL>  @log_member

GROUP# THREAD# MEMBER                                                        ARCHIVED   STATUS     Size (MB)
------ ------- ---------------------------------------------------------------------- ---------- ---------- ---------
     2       1 /archive/CLONEDB/redo02.log                                  NO         CURRENT           50
     4       1 /archive/CLONEDB/redo04.log                                  YES        INACTIVE          50

Script to List RMAN Backup Set

$
0
0
SELECT  bs.recid, DECODE(backup_type, 'L', 'Archived Logs', 'D', 'Datafile Full', 'I', 'Incremental') backup_type,
device_type "type", DECODE(bs.controlfile_included, 'NO', null, bs.controlfile_included) controlfile,
sp.spfile_included spfile, bs.incremental_level L,TO_CHAR(bs.start_time, 'dd/mm/yyyy HH24:MI:SS') start_time
  , TO_CHAR(bs.completion_time, 'dd/mm/yyyy HH24:MI:SS')  completion_time, bs.elapsed_seconds "ELAPSED", bp.tag, bs.block_size "BLOCK"
  FROM  v$backup_set  bs, (select distinct set_stamp, set_count, tag, device_type from v$backup_piece where status in ('A', 'X'))  bp,
   (select distinct set_stamp, set_count, 'YES' spfile_included from v$backup_spfile) sp
WHERE completion_time > sysdate -1
  AND bs.set_stamp = bp.set_stamp
  AND bs.set_count = bp.set_count
  AND bs.set_stamp = sp.set_stamp (+)
  AND bs.set_count = sp.set_count (+)
ORDER BY  completion_time desc, bs.recid;

Recovery of OCR in 11g

$
0
0
Step #1 Stop cluster on each node (Root user).

# crsctl stop crs -f

Step #2 we are starting the cluster in the excusive mode (Root user)

As root start GI in exclusive mode on one node only:

In 11201 RAC, we have to use below option to start the cluster in the exclusive mode.

# crsctl start crs -excl

In 11202 RAC, we have to use below option to start the cluster in the exclusive mode.

# crsctl start crs -excl -nocrs

Note: A new option ‘-nocrs‘ has been introduced with  11.2.0.2, which prevents the start of the ora.crsd resource. It is vital that this option is specified; otherwise the failure to start the ora.crsd resource will tear down ora.cluster_interconnect.haip, which in turn will cause ASM to crash.

Step #3 Restoring OCR

To Know the OCR Location on the cluster environment
$ cat /etc/oracle/ocr.loc  — In Linux

To Check whether ocrcheck is corrupted or not

# ocrcheck

Check whether ocrcheck is able to complete it successfully

OCR CHECK Ex
# ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          3
         Total space (kbytes)     :     262120
         Used space (kbytes)      :       4404
         Available space (kbytes) :     257716
         ID                       : 1306201859
         Device/File Name         :  +DG01
                                    Device/File integrity check succeeded
                                    Device/File not configured
                                    Device/File not configured
                                    Device/File not configured
                                    Device/File not configured
         Cluster registry integrity check succeeded

         Logical corruption check succeeded
     

Note: 1) Check whether cluster registry integrity check is successful.
          2) When you run as root user, logical corruption check will be bypassed.
If you run as oracle user, you can see this line end of the “ocrcheck” output.
“Logical corruption check bypassed due to non-privileged user”


To Know the OCR Location on the cluster environment
$ cat /etc/oracle/ocr.loc  — In Linux
If the OCR DISK corrupted, then perform the below steps

Locate OCR LOG file location
$ORACLE_HOME /log/<hostname>/client/ocrcheck_<pid>.log
Locate the latest automatic OCR backup
$GRID_HOME\bin\ocrconfig –showbackup

Restore the latest OCR backup(root user)
# ocrconfig -restore $ORACLE_HOME/cdata/testdbrac1/backup00.ocr

Article 3

$
0
0
frmbld: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory

Forms Builder Does not Launch on Linux RHEL5 :

When attempting to launch Forms Builder using the command frmbld.sh in $ORACLE_INSTANCE/bin/, the following error message is displayed:

$ORACLE_HOME/bin/frmbld: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory

SOLUTION :

As a workaround, create a symlink named libXm.so.3 to libXm.so.4 in ORACLE_INSTANCE/bin/xm and add it to the LD_LIBRARY_PATH. Or install OpenMotif package using the command rpm -i  openmotif22-2.2.3-18.i386.rpm

REFERENCE :

https://docs.oracle.com/cd/E23943_01/relnotes.1111/e10133/forms.htm
Viewing all 1640 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>