Wednesday, April 10, 2013

Problems and Solutions on CM

Problems: I hit the Restart button to start the Standard manager, but it still did not start? Solution: The ICM will start Standard Manager in the next process monitor session or the next time the ICM starts. Use Activate to start a manager immediately. When a manager is deactivated manually, the ICM will not restart it, you will need to set it to Restart, or activate it manually.
Problem: When you try to submit a request like Active users or Active responsibilities, request gets submitted. When we view the requests, you find that it is inactive / nomanager. Within 12 to 15 seconds, you refresh-it gets completed.
Solution: when this occurs where a request goes "inactive/no manager" and is then processed a short time later, the solution is to either increase the cache size for your Standard manger, or increase the actual number of Standard manager processes.
HELPFUL DIAGNOSTIC SCRIPTS
The following SQL scripts located under $FND_TOP/sql are useful when diagnosing concurrent manager problems:
afimchk.sql Tells the status of the ICM and PMON method
afcmstat.sql Lists active manager processes
afrqrun.sql Lists all the running, waiting and terminating requests
afrqwait.sql Lists requests that are constrained and waiting for the ICM to release them
afrqscm.sql Prints log file name of managers that can run a given request. It can be used to check for possible errors when a request stays in pending status. It requires a request id value.
afcmcreq.sql Prints the log file name of the manager that processed the request
afrqstat.sql Summary of completed concurrent requests grouped by completion status and execution type. It requires number of days prior to today on which to report parameter.
afimlock.sql Lists locks that the ICM is waiting to get
afcmrrq.sql Lists managers that currently are running a request

DR Sync or not

To check the DR Sync or not
**********************************************************************************************************************************************************************************************************************************************************
**********************************************************************************************************************************************************************************************************************************************************
login to primary db
run this query
select thread#, max(sequence#) from v$archived_log group by thread#;
select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
first one shows primary db last generated sequence
second one will give what is the last log applied in standby
if both are equal dr is sync
if no
we need to login to DR and check what is the issue
Exec below query at Physcial standby by(I am asuming it to be so)...
SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
If your DR is a Physical Standby, then check if ARCH, MRP0,RFS processes are running.
If any of the process is not running, either shipping or applying of log files will not happen.
Also check the archive Dest of Stdby. In case log files are available, but not gettting applied, you need to register them manually.


SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
RFS N/A 0 IDLE
MRP0 N/A 9999 WAIT_FOR_GAP


select switchover_status from v$database;


The SWITCHOVER_STATUS should have the value of TO STANDBY or SESSIONS ACTIVE. If not then redo transport is not functioning properly and you will not be able to perform the switchover.
If you received SESSIONS ACTIVE in the prior step you might have connections that may prevent the switchover. Verify the active connections by querying V$SESSION.

 

lost apps password

Best way is follow the below link it more helpfull.