g:\prints\issuse\Accidently issued alter command for apps schema.

txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Accidently issued alter user command to change apps password

Sol 1:
APPS User Locks After Manually Altering Password [ID 566127.1] for 12.0.4

To implement the solution, please execute the following steps:

1. Backup the FND_USER, FND_ORACLE_USERID tables

2. Change the password in the following sequence.

SQL> alter user applsys identified by apps;

SQL> alter user apps identified by apps;

SQL> alter user apps account unlock;

Sol 2:
APP-FND-01496 Error After Changing Apps And Applsys Users Using Alter User [ID
445153.1] for Release: 11.5.10 to 11.5.10 1.
Restore the FND_ORACLE_USERID and FND_USER tables from a backup.
2. Then run FNDCPASS to change the APPLSYS password.
FNDCPASS apps/apps 0 Y system/ SYSTEM APPLSYS WELCOME

Troubleshooting Guide For Login and Changing Applications Passwords [ID 1306938.1]

g:\prints\issuse\adpatch issue.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Applications System Names Between Appl_Top And Database Are Different (Doc ID
274196.1)

Adpatch Fails : 'The Applications System names per the APPL_TOP and the database
are different.' (Doc ID 213339.1)
Unable to Patch a Cloned Environment Because of Wrong Applications System Names
(Doc ID 202483.1)

We recently faced an issue after development instance cloned from production.

adPatch Failed with the below errors.

The Applications System names per the APPL_TOP and the database are different.
Applications System name per the APPL_TOP: EBSDEV
Applications System name per the database: EBSOLTP
If you continue, the Applications System name per the APPL_TOP will be ignored.

Do you wish to continue [No] ?

Cause *:-- The APPLICATIONS_SYSTEM_NAME field in the FND_PRODUCT_GROUPS table was

still filled with the value of the old environment.

NOTE * ;-
When we run FND_CONC_CLONE.SETUP_CLEAN it will clean FND_PRODUCT_GROUPS table and
really not sure why the name of the production
instance appear in the table.

SQL> select APPLICATIONS_SYSTEM_NAME from FND_PRODUCT_GROUPS;

APPLICATIONS_SYSTEM_NAME
����������
EBSOLTP

Solution *:--

update FND_PRODUCT_GROUPS set APPLICATIONS_SYSTEM_NAME =�EBSDEV' ;

commit;

Then we restarted adpatch and it got succeeded.

g:\prints\issuse\AlertErrors.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Alertlog Errors:
++++++++++++++++

1) opiodr aborting process unknown ospid (28342) as a result of ORA-28

or
ORA-28 : opiodr aborting process unknown ospid (21016_3086862016)

Error:
opiodr aborting process unknown ospid (28342) as a result of ORA-28
or
ORA-28 : opiodr aborting process unknown ospid (21016_3086862016)

Solution:

This is an informational message only. The intention of the message is to ensure

that the alert captures information about processes that exit unusually. The
message was added in 11g.

The sample message above, with the ORA-28, is normally reported when a privileged
user has killed the session.

Here is a breakdown of the sample message: "opiodr aborting process unknown ospid
(28342) as a result of ORA-28"

"unknown" => means that the Oracle process name (Shadow, background) could not be
determined.
"ospid (28342)" => this is the OS pid of the process which opiodr is aborting
"as a result of" => this precedes the error message which is the reason for opiodr
to kill the process
"ORA-28" => this is the reason that opiodr killed the process. In this case, it is
ora-28.

Here is the error text for ORA-28:

Error: ORA 28
Text: your session has been killed
-------------------------------------------------------------------------------
Cause: A privileged user killed the session and it is no longer logged in to the
database.
Action: Contact the database administrator.
The administrator may be attempting to perform an operation that requires users to
be logged out.
When the database administrator announces that the database is available, log in
and resume work.

The "opiodr aborting process" message can occur with different causes than ORA-28.
In that case the "opiodr aborting process" message will have the relevant error
instead of the ORA-28.

Note: In 11.1, the ORA-28 message is more cryptic, for example:

ORA-28 : opiodr aborting process unknown ospid (21016_3086862016)

Reference metalink Doc ID 1230858.1

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++

2) WARNING: inbound connection timed out (ORA-3136)

Troubleshooting Guide ORA-3136: WARNING Inbound Connection Timed Out (Doc ID
465043.1)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++

3) ORA-00060: Deadlock detected. More info in file

/u01/oracle/PROD/db/tech_st/11.1.0/admin/PROD_proddb/diag/rdbms/prod/PROD/trace/PRO
D_ora_2889.trc.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++

Error:

ERROR at line 1:
ORA-01119: error in creating database file
'u03/oracle/APRCLN/u01/PROD/db/apps_st/data/spdata.dbf'
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory

Solution:

O/S-Error: (OS 3) The system cannot find the path specified.

The location over which you are trying to create your data file is either incorrect
or not writable. Check the path and permissions for the same.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++

Stopping background process CJQ0

Error:

The following messages are frequently logged in alert log

Tue Dec 1 21:30:48 2009

Starting background process CJQ0
.
Wed Dec 2 06:13:22 2009
Stopping background process CJQ0

Cause:

If there is a DBMS_SCHEDULER job to be executed then this is expected behavior if

JOB_QUEUE_PROCESSES is either set to 0 or not set at all.
The job queue coordinator will be started when the scheduled job needs executed and
the job queue coordinator is stopped again as soon as the job finishes.

Solution:

1. Check how many Scheduler jobs are setup in your database.

select count(*) from dba_scheduler_jobs;

select owner, job_name FROM dba_scheduler_jobs; # for a list of all the jobs.

Let's say, there are 14 jobs.

2. Now, check the value of job_queue_processes parameter:

SQL> show parameter JOB_QUEUE_PROCESSES;

job_queue_processes integer 10

3. Change the value of JOB_QUEUE_PROCESSES equal to or hiher than the total number
of jobs (found in step 1 above).

ALTER SYSTEM SET job_queue_processes = 15 SCOPE= SPFILE;

or

Ignore these messages or set JOB_QUEUE_PROCESSES to a non-zero value.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++

g:\prints\issuse\cm issues_03.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

REP-3000: Internal Error Starting Oracle Toolkit .

++++++++++++++++++++++++++++++++++++++++++++++++++
DISPLAY=<hostname>:<display_number>.0 ; export DISPLAY

ICM is creating zero bytes of log file.

tns issues

i have done with my clone and when i am trying to start the concurrent manager
getting error saying
no FNDLIBR.

FNDLIBR ==> Got deleted.

ICM Not Starting: Node Name not Registered [ID 602942.1]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Cause
++++++++
wrong host name defined

solution:
+++++++
This node name value can be changed by running the UNIX command setuname or the
hostname command. An example of this would be:
setuname -n newnodename

Concurrent Processing - The Concurrent Manager Fails to Start on GSM Enabled Due to
DBMS_LOCK.Request ResultCall Failed to Establish ICM [ID 245563.1]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

cause: Database Locking issue

symptom: Routine FND_DCP.REQUEST_SESSION_LOCK received a result code of 1

from the call to DBMS_LOCK.Request

fix:

1. Stop all services and concurrent managers

2. Stop and restart the database
3. Restart the services and concurrent managers
4. Verify if the issue remains

Cause: FDPRRC failed due to ORA-01654: unable to extend index

APPLSYS.FND_CONCURRENT_REQUESTS_N4 by 16 in tablespace APPS_TS_TX_IDX
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
Cause:There is not enough space in tablespace APPS_TS_TX_DATA
Tablespace is 100%

Users are complaining there requests are not completing.

work shifts are not define.
++++++++++++++++++++++++++++++

+++++++++++++++++++++++++
OS ISSUES
+++++++++++++++++++++++++
File system issue ==> unable to see the mount point.
Unix users login issues ==> like mailer user password is not working.
Connection timed out error ==> unable to login to unix box/Host.
Mount point mounted on wrong physical box.
Space is not getting released from the mount point.

++++++++++++++++
DB ISSUES
+++++++++++++++

Lets discuss the very basics of Concurrent Managers, again the very basics for the
beginners that read http://getappstraining.blogspot.com
Two things are obvious:-
1. Concurrent Manager is related to Concurrent Programs
2. Concurrent manager manages the concurrent(oops I mean parallel) execution of
concurrent programs.

So what's left to explain?.....Well nothing much, but I gave a commitment to one of

my readers that I shall write something about concurrent managers today. And now
when I begin to write, I realize it is worth writing something in plain English on
this topic.

Question:
Answer: There is something known as Concurrent Manager that runs in the background
all the time. This background process, called Concurrent Manager ideally will be
running 24x7.
As the name suggests, purpose of a concurrent manager is to manage the submitted
concurrent programs.

Question: When I submit a concurrent program( or call it concurrent request), how

does concurrent manager pick this up?
Answer: Concurrent manager will be running in the background waiting for a
concurrent program to be submitted. As soon as a concurrent program is submitted,
it then gets put in an execution queue by concurrent manager.

Question: Why does the Concurrent manager put a concurrent program into a queue?
Why doesn't the manager simply let the program run?
Answer: Because at any given point in time a concurrent manager can run no more
than say 10 programs concurrently. This figure of 10 is configurable of course.
First the manager puts a submitted program into a queue, next the manager checks if
there is a slot available (i.e. Less than 10 programs are currently running). If a
slot is found available, the concurrent manager then runs the program, or else it
keeps the concurrent program in a queue with status Pending.

Question: If we have two concurrent programs, that must never run in parallel(oops
I mean concurrently)....can concurrent manager manage such scenarios?
Answer: Of course it can. When you define a concurrent program, you can specify if
there are any incompatible programs. If incompatible concurrent programs exist,
then concurrent manager will wait for the incompatible program to complete.

++++++++++++++++
Patching issues
+++++++++++++++
1)
worker is trying to change the column width but failing it.
This is standard table.
i try to do it manually and it is again failing
we raised a SR with oracle they have given patch and we applied.
Now column width got changed.

2)I was applying an application patch but that patch is not able copy the files to
pa top and i thought
issue with permision and i provided the full permision but the patch got failed
again.
Cause: i manuall copy the files to the desire location and commented in the driver
file and the patch got success.

g:\prints\issuse\Concurrent Manager Issues.txt

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Issue.1:

Concurrent Program �Pending Standby� status...

There are instances when we run a concurrent program & it goes to �Pending Standby�
status.

Sometimes this status would change after few minutes but, there are instances that
this remains in same status forever.

Please carry out following steps to solve this issue:

Login to System Administrator Responsibility;

---> System Administrator
-------->Concurrent manager
--------------> Administrator
Look for Concurrent Manager Name "Conflict Resolution Manager"

See whether the Conflict Resolution manager is running, if is it not, activate it

and it shall solve the standby status issue.

If the Conflict Resolution manager is running Click �Verify� button.

Once completed with the verification, resubmit the previous hanging request, and it
should run without any problem.

Issue.2:

Concurrent Requests Remain in Status Pending Normal For a Long Period Before
Running [ID 749176.1]
When submitting concurrent requests they are taking a long time to start running
pahse , they remain in the pending normal status for a long time before running to
completion.

Changes

No specific changes , Most likely a fresh installation.

Cause

The cause of this problem has been identified as a large number of processes has
been defined for the standard manager or a large sleep time assigned .
Solution

Verify the number of Processes and Sleep seconds assigned to the Standard Manager :
a- As System Administrator navigate to :

Concurrent > Managers >>Define, then query the Standard Manager, select Workshifts

b- Adjust the number of processes and the sleep seconds accordingly.

This will depend on the business needs and performance you require.

Note:

If you defined for example 10 processes, and specified a sleep time of 3, this
means that each of these 10 processes will verify every 3 seconds if there is
anything to process.

Issue.3:

All concurrent requests go into pending with status of standby.

Cause
���-
System Profile Option: Concurrent Active Requests set to 0.

Solution
����

To fix the issue, lease do this:

1. Log into Oracle Applications as SYSADMIN.

2. Select System Administrator responsibility.
3. Navigate to PROFILE �> SYSTEM.
4. Query for %CONC%ACTIVE%.
5. Change the profile option for Concurrent: Active Request Limit to Null (blank).
6. Exit Oracle Applications and log in again for the change to take affect.
7. Run a new concurrent request

Issue.4

1. Concurrent request status is PENDING STANDBY status?

Pending Standby - Phase Pending and Status Standby means Program to run request is
incompatible with other program(s) currently running.
I have submitted one concurrent request at 19:00 Hrs (Day1) and this request is to
be run by a concurrent manager which has work shift of 00:00 Hrs to 08:00 Hrs (Day
2). The moment when I submit this concurrent request it�s status will be �Inactive
No Manager� until this manager goes active. Suppose I have many requests pending
with this concurrent and this request couldn�t start.
Now what will be status of this request after 08:00 Hrs (Day 2) when it�s manager
goes down? Here in my case it is still �Inactive No Manager� though I think it
should be �Pending Standby�
This could be for different reasons (other pending requests, no place for new
requests, ...etc).
Solving Concurrent Program �Pending Standby� status (Oracle EBS 11i)
There are instances when we run the Concurrent Program, it goes to �Pending
Standby� status. Sometimes we can see this status get changed after few minutes
but,
there are instances it will be in the same status forever. This means the request
is not progressing and will not be completed ever.
To make that request to progress again, the following steps need to be carried out;
Go to System Administrator Responsibility;
��>>System Administrator
����>Concurrent manager
�������>Conflict Resolution Manager
See whether the Conflict Resolution manager is running, if is it not, activate it
and it will solve the standby status issue.
If the Conflict Resolution manager is running
��->Click �Verify� button
Once completed with the verification, resubmit the previous hanging request, and it
should run without any problem.

g:\prints\issuse\db issues.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ORA-01502 index or partition of such index is in unusable state
ERROR:-
-----
ORA-01502: index "owner.index_name" or partition of such index is in unusable state

SOLUTION:-
--------
REBUILD UNUSABLE INDEXES in Oracle Database

$sqlplus "/as sysdba"

select owner,index_name,table_name,status from dba_indexes where

index_name='&index_name';
OWNER INDEX_NAME TABLE_NAME STATUS
----- ---------- ---------- ------
owner index_name table_name INVALID

select owner,segment_name,sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where

segment_name='&segment_name';
OWNER SEGMENT_NAME SIZE IN MB
----- ------------ ----------
owner index_name 3000

alter session set current_schema='&schema_name';

Session altered.

alter index <index_name> rebuild;

Index altered.

select owner,index_name,table_name,status from dba_indexes where

index_name='&index_name';
OWNER INDEX_NAME TABLE_NAME STATUS
----- ---------- ---------- ------
owner index_name table_name VALID

select owner,segment_name,sum(bytes)/1024/1024 "SIZE in MB" from dba_segments where

segment_name='&segment_name';
OWNER SEGMENT_NAME SIZE IN MB
----- ------------ ----------
owner index_name 800

------------------------------------ OR
------------------------------------------------------

SELECT 'ALTER INDEX '||OWNER||'.'||INDEX_NAME||' REBUILD;' FROM DBA_INDEXES WHERE

STATUS = 'UNUSABLE';

This will output statements for all "unusable" indexes. Run them, so that the
indexes can be "usable" again.

ORA-02297: cannot disable constraint (SCHEMANAME.PK_TABLENAME) - dependencies exist

ISSUE:
ORA-02297: cannot disable constraint (SCHEMANAME.PK_TABLENAME) - dependencies exist

Restore TABLE backup

Schema Status
-------------
select username from dba_users where username=upper('&username');

Table Status
------------
select count(*) from SCHEMANAME.TABLENAME;

TRUNCATE TABLE
---------------------------
spool TARGET_TABLENAME_TRUNCATE.log
set echo on term on feed on timing on

truncate table SCHEMANAME.TABLENAME;

truncate table SCHEMANAME.TABLENAME
*
ERROR at line 1:
ORA-02266: unique/primary keys in table referenced by enabled foreign keys

select CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME,status from dba_constraints where

TABLE_NAME='&TABLE_NAME';

CONSTRAINT_NAME C TABLE_NAME STATUS

------------------------------ - ------------------------------ -------
SYS_CONSTRAINT1 C TABLENAME ENABLED
PK_TABLENAME P TABLENAME ENABLED

alter table SCHEMANAME.TABLENAME DISABLE constraint SYS_CONSTRAINT1;

alter table SCHEMANAME.TABLENAME DISABLE constraint PK_TABLENAME;

ERROR at line 1:
ORA-02297: cannot disable constraint (SCHEMANAME.PK_TABLENAME) -
dependencies exist

SOLUTION:

alter table SCHEMANAME.TABLENAME DISABLE constraint PK_TABLENAME cascade;

Table altered.

select CONSTRAINT_NAME,CONSTRAINT_TYPE,TABLE_NAME,status from dba_constraints where

TABLE_NAME='TABLE_NAME';

1008 TRACE file

ISSUE:-
-----
Below error received when trying to run the code having bind variables.
But,same code works correctly in other datadases maintained at same version.

Oracle Database Version: 11.2.0.2.0 - 64 bit (SQL>SELECT BANNER FROM v$version;)

PL/SQL : 11.2.0.2.0
OS Version : Linux x86_64 ($uname -ms)

OS Version
----------
$uname -ms
Linux x86_64

ERROR:
-----
ERROR at line 1:
ORA-01008:not all variables bound
ORA-06512:at line 77

Running in to Bug 14458214 (5/rdbms/partitioning) Unexpected ORA-01008 from select

on composite partitioned table.

The workaround mentioned in Bug 14458214 is as follows:

Try executing this from the sqlplus session before you execute the anonymous block.

alter session set "_and_pruning_enabled"=false;

alter session set "_subquery_pruning_enabled"=false;
alter session set "_optimizer_table_expansion"=false;
--execute the anonymous PL/SQL block which fails, here

How to Generate 1008 TRACE file from Oracle Database

----------------------------------------------------
Set an 1008 ERRORSTACK event to confirm the stack.

Database Details
----------------
sqlplus "/as sysdba"

set pages 50000 lines 32767

col OPEN_MODE for a10
col HOST_NAME for a20
select name DB_NAME, INSTANCE_NAME, HOST_NAME, DATABASE_ROLE,
OPEN_MODE, version DB_VERSION, LOGINS,
to_char(STARTUP_TIME,'DD-MON-YYYY HH24:MI:SS') "DB UP TIME"
from v$database,gv$instance;

Generate 1008 TRACE file at session level

-----------------------------------------
alter session set timed_statistics=true;
alter session set statistics_level=all;
alter session set max_dump_file_size=unlimited;
alter session set tracefile_identifier='TEST1008';

alter session set events '1008 trace name ERRORSTACK level 4';
--execute the statement which fails, here
alter session set events '1008 trace name context off';

Trace File Location

-------------------
set pages 50000 lines 32767
col NAME for a30
col VALUE for a100
select * from v$diag_info where name like '%Diag Trace'; -------------- 11G

INST_ID NAME VALUE

------- ---------- ---------
Diag Trace /trace/file/location/

exit

Listing Trace Files

-------------------
cd /trace/file/location/
ls -lrt | grep -i TEST1008

Error 1031 received logging on to the standby

ISSUE

Error 1031 received logging on to the standby

ORA-01031: insufficient privileges
PING[ARC0]: Heartbeat failed to connect to standby 'dgp'. Error is 1031.

PRIMARY
=======
Primary database Alert log error:
--------------------------------
Error 1031 received logging on to the standby
ORA-01031: insufficient privileges
PING[ARC0]: Heartbeat failed to connect to standby 'dgp'. Error is 1031.

Chech DR sync and see the difference.

THREAD PR-ARCHIVED STBY-ARCHIVED STBY-APPLIED SHIPPING GAP(PR -> STBY) APPLIED

GAP(STBY -> STBY)
------ ----------- ------------- ------------ ------------------------
-------------------------

set pages 999 lines 999

col MESSAGE for a100

select to_char(timestamp,'YYYY-MON-DD HH24:MI:SS')||' '||message||severity from
gv$dataguard_status where severity in ('Error','Fatal') order by timestamp;

show parameter log_archive_dest_state_2;

LISTNER VERIFICATION FROM PRIMATY DB

------------------------------------
select dest_id,status,error from v$archive_dest where
dest_name='LOG_ARCHIVE_DEST_2';

FIND GAP
--------
select thread#,low_sequence#,high_sequence# from gv$archive_log;

ps -ef |grep tns

lsnrctl status
DR
==
DR database Alert log error:
----------------------------
Error 1031 received logging on to the standby

set pages 999 lines 999

col MESSAGE for a100

select to_char(timestamp,'YYYY-MON-DD HH24:MI:SS')||' '||message||severity from
gv$dataguard_status where severity in ('Error','Fatal') order by timestamp;

select inst_id,process,status,thread#,sequence#,block#,blocks from

gv$managed_standby;

PROCESS STATUS
------- ------------
RFS IDLE
RFS IDLE
RFS IDLE
MRP0 WAIT_FOR_LOG

checking log transfer and apply

-------------------------------
SELECT SEQUENCE#,FIRST_TIME,NEXT_TIME,APPLIED FROM gV$ARCHIVED_LOG ORDER BY
SEQUENCE#;
select count(*) from GV$ARCHIVED_LOG where applied='NO';

Redo transfer was not happening. When we checked in the

v$managed_process data dictionary view, we could see that RFS was not starting.

Here,
ora-01031 usually appears when some sysdba session failes to authenticate
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.

1.The RFS process was not started in the standby which indicates that standby is
not receiving any redo information from the primary.

2.In the primary alert log file we could see the errors indicating that the primary
is not able to communicate with the standby instance. The error observed was "Error
1031 received logging on to the standby".

3.The time stamp of the password file on the primary and the standby was different.
This indicated the possibility of having the wrong password file in the standby.

SOLUTION:
=========
For the redo transfer to take place efficiently, the password file on standby
should be a copy from the primary and renamed standby.We can use v$pwd_file_users
data dictionary view to check if the password file is used

1.copy the password file from the primary to the standby and renamed the password
file in the following format ie orapw<sid> .

2.Restar the media recovery process on the standby.

Once the above steps are completed we could see that redo shipping and redo apply
is taking place.

Copy the latest Password file from available PRIMARY Node to rest of PRIMARY and
STANDBY nodes:
-----------------------------------------------------------------------------------
-----------
Primary (Node 1)
----------------
cd $ORACLE_HOME/dbs
ls -lrt
scp orapw<sid> oracle@PROD_NODE_2_hostname:/oracle/home/dbs
scp orapw<sid> oracle@DR_NODE_1_hostname:/oracle/home/dbs
scp orapw<sid> oracle@DR_NODE_2_hostname:/oracle/home/dbs

or

DR
==
select * from gv$pwfile_users;

we have to check sec_case_sensitive_logon parameter on primary and standby.

SQL> show parameter sec_case_sensitive_logon;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon boolean FALSE
SQL>

We have to recreate the passwd file or copy Primary server to Standby server.

In cause sec_case_sensitive_logon parameter value is true, we have to use below

orapwd command.
orapwd file=$ORACLE_HOME/dbs/orapwPROD password=password123 entries=10 ignorecase=y

In cause sec_case_sensitive_logon parameter value is false, we have to use below

orapwd command.
orapwd file=$ORACLE_HOME/dbs/orapwPROD password=password123 entries=10

DR
==
cancelling mrp process:
alter database recover managed standby database cancel;

starting mrp process:

alter database recover managed standby database disconnect from session;

select inst_id,process,status,thread#,sequence#,block#,blocks from

gv$managed_standby;

Chech DR sync and see the difference.

How to Find Locks on Objects

ISSUE:
-----
ORA-00054: resource busy and acquire with NOWAIT specified

Locked sessions on Oracle Database Objects :-

-----------------------------------------------
Query 1:
-------
set pages 50000 lines 32767

SELECT s.inst_id,s.sid || ',' || s.serial# sess_id,

oracle_username || ' (' || s.osuser || ')' os_username,
owner || '.' || object_name,object_type,object_id,
DECODE (l.block, 0, 'Not Blocking', 1, 'Blocking', 2, 'Global') STATUS,
DECODE (v.locked_mode,
0, 'None',
1, 'Null',
2, 'Row-S (SS)',
3, 'Row-X (SX)',
4, 'Share',
5, 'S/Row-X (SSX)',
6, 'Exclusive',
TO_CHAR (lmode)) LOCK_MODE,
a.sql_text
FROM gv$locked_object v,
dba_objects d,
gv$lock l,
gv$session s
gv$sqlarea a
WHERE v.object_id = d.object_id
AND v.object_id = l.id1
AND v.session_id = s.sid
ORDER BY oracle_username, session_id;

Query 2: (More Information)

-------
set pages 50000 lines 32767

select
vlo.object_id, vlo.session_id, vlo.oracle_username, vlo.process
, DECODE(vlo.LOCKED_MODE,
0,'NONE',
1,'NULL',
2,'ROW SHARE',
3,'ROW EXCLUSIVE',
4,'SHARE',
5,'SHARE ROW EXCLUSIVE',
6,'EXCLUSIVE', NULL) LOCK_MODE,
do.owner, do.object_name, do.object_type
, vs.saddr, vs.serial#, vs.paddr, vs.username, vs.ownerid, vs.status, vs.server,
vs.schemaname, vs.osuser, vs.machine, vs.program, vs.type, vs.logon_time,
vs.last_call_et, vs.blocking_session_status,
vs.event#, vs.event, vs.wait_class#, vs.wait_class, vs.wait_time,
vs.seconds_in_wait, vs.state
from gv$locked_object vlo
inner join dba_objects do on (vlo.object_id = do.object_id)
left outer join gv$session vs on (vlo.session_id = vs.sid);

Query 3:
-------
set pages 50000 lines 32767

SELECT
b.inst_id,a.session_id,b.serial#,b.STATUS,b.machine,a.ORACLE_USERNAME,a.OS_USER_NAM
E,a.LOCKED_MODE,
c.owner,c.object_name,c.object_type,c.object_id,d.sql_text
FROM
gv$locked_object a,
gv$session b,
dba_objects c,
gv$sqlarea d
WHERE b.sid = a.session_id
AND a.object_id = c.object_id
ORDER BY a.oracle_username, a.session_id;

Query 4:
-------
set pages 50000 lines 32767

SELECT s.inst_id,OS_USER_NAME, ORACLE_USERNAME, s.sid, o.object_name,o.object_type,

s.serial#, a.sql_text
FROM gv$locked_object l, dba_objects o, gv$session s, gv$sqlarea a
WHERE l.object_id = o.object_id
AND s.SQL_ADDRESS = a.address
AND l.SESSION_ID = s.sid;

Command to kill the session:

---------------------------
ALTER SYSTEM KILL SESSION 'sid, serial#';
ALTER SYSTEM KILL SESSION 'sid, serial#,@<instance_id>'; (RAC)

Script to Kill all the locks

----------------------------
set pages 50000 lines 32767

SELECT 'ALTER SYSTEM KILL SESSION "'||TO_CHAR(s.sid)||','||TO_CHAR(s.serial#)||"';'

AS "Statement to kill"
FROM gv$locked_object l, dba_objects o, gv$session s
WHERE l.object_id = o.object_id
AND l.SESSION_ID = s.sid;

ORA-00257: archiver error. Connect internal only, until freed.

ISSUE:
ORA-00257: archiver error. Connect internal only, until freed
ARCHIVE DESTINATION FULL ORA-00257

ps -ef|grep pmon

ORACLE_SID=`ps -ef | grep asm_smon | grep -v 'grep' | grep -v 'sed' | awk '{printf
$8}' | awk 'BEGIN{FS="_"} {printf $3}'`

ASM Tablespace Utilization Scripts

show parameter recovery;

1. DB_RECOVERY_FILE_DEST_SIZE (Specifies max space to use for FRA)

2. DB_RECOVERY_FILE_DEST (Location of FRA)
The DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST.

col name format a40

select
name,
to_char(space_limit, '999,999,999,999') as space_limit,
to_char(space_limit - space_used + space_reclaimable,
 '999,999,999,999') as space_available,
round((space_used - space_reclaimable)/space_limit * 100, 1) as pct_full
from
v$recovery_file_dest;

select * from V$FLASH_RECOVERY_AREA_USAGE;(see what kind of files are available in

the Flash Recovery Area)
select * from V$RECOVERY_FILE_DEST; (determine actual values)

ALTER SYSTEM SET db_recovery_file_dest_size=10G scope=both;

ALTER SYSTEM SET db_recovery_file_dest='/oradata/FRA';

For example, If FRA is in an Automatic Storage Management (ASM) disk group

ALTER SYSTEM SET db_recovery_file_dest='+FLASH� scope=both;

RAC
ALTER SYSTEM set db_recovery_file_dest_size=60G scope=both sid='*' ;
ALTER SYSTEM SET db_recovery_file_dest='+FLASH' sid='*';
In a RAC database, all instances must have the same values for these parameters.
Even though there are multiple nodes they all share the same controlfiles.

Here,if there is no space available. DBA can take the archive backup to free the
space.

ls -ltr *.cmd

nohup rman target / cmdfile=archivebackup.cmd log=archivebackup_dbname_DDMONYY.log

&
nohup: appending output to `nohup.out'
tail -f archivebackup_dbname_DDMONYY.log

archivebackup.cmd
-----------------
run {
DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-1' BACKED UP 1 TIMES TO SBT_TAPE;
allocate channel ch1 type 'sbt_tape';
allocate channel ch2 type 'sbt_tape';
allocate channel ch3 type 'sbt_tape';
allocate channel ch4 type 'sbt_tape';
BACKUP ARCHIVELOG ALL FILESPERSET 10 DELETE INPUT;
}

ps -ef| grep rman

col name format a40

select
name,
to_char(space_limit, '999,999,999,999') as space_limit,
to_char(space_limit - space_used + space_reclaimable,
'999,999,999,999') as space_available,
round((space_used - space_reclaimable)/space_limit * 100, 1) as pct_full
from
v$recovery_file_dest;

select * from V$FLASH_RECOVERY_AREA_USAGE;(see what kind of files are available in

the Flash Recovery Area)
select * from V$RECOVERY_FILE_DEST; (determine actual values)

NOTE:
In order to solve the above error the solutions are

1) Increase the free space where archiver archives the archivelog. The location
where archiver archives the log is determined by parameter file pfile or spfile.
This can be determined by loging into sqlplus and issuing

SQL> show parameter log_archive_dest

2) In case it is not possible to increase free space at the same location but if
free space is available at other location then the parameter log_archive_dest (or
log_archive_dest_1 in some cases) can be changed so that the new archives are
produced at new location specified which has free space.

this can be done by modify init.ora file or using alter system if spfile is present

SQL> alter system set log_archive_dest_1=�

3) We can use following steps for this

1.find the location of Archive destination by
show parameter archive_dest

lets say it provide LOCATION=/u10/oradata/mydb/arch

2.move some files to some other location using os command

cd /u10/oradata/mydb/arch
mv /u10/oradata/mydb/arch/* /u11/oradata/mydb/arch-bkp/

4) The option which is often used is to take a backup of the archives from the
existing place and delete those archives from that place so that new archives can
generated at that place .
the backup can be OS level backup and OS level del;etion but the recommended method
which is compulsory to be used with ASM in place is taking any RMAN backup and
delete using RMAN. as shown

rman target sys/sys

RMAN> backup archive log all device type disk format �/oracle/arch_%U�;
RMAN> delete archive until time �trunc(sysdate)�;

This will delete all the archive logs until today and space will freed and the
archiver will start archiving redo logs

The views v$recovery_file_dest and v$flash_recovery_area_usage does not always give

the true picture of exact space used due to BUG Bug 4911954 in Oracle 10g and the
versions which is confirmed to be affected is 10.2.0.2. (Reference Metalink Doc Id
4911954.8 ).
V$FLASH_RECOVERY_AREA_USAGE provides information about the flash recovery area disk
space usage. Following is its main columns:
FILE_TYPE - the type of the file and can have any of the following values:
controlfile, onlinelog, archivelog, backuppiece, imagecopy, flashbacklog
PERCENT_SPACE_USED - This represents the disk space used by the file type, in
percentage.
PERCENT_SPACE_RECLAIMABLE - this represents the percentage of disk space
reclaimable from the file type after deleting any obsolete or redundant files, and
files backed up to a tertiary device.
OTN Notes that you can see the actual space used by joining into
v$recovery_file_dest:
A new view, V$FLASH_RECOVERY_AREA_USAGE, shows what's available in the flashback
area.
g:\prints\issuse\Issues & Fixes.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Issues & Fixes
===============:

Applications System Names Between Appl_Top And Database Are Different (Doc ID
274196.1)

Adpatch Fails : 'The Applications System names per the APPL_TOP and the database
are different.' (Doc ID 213339.1)
Unable to Patch a Cloned Environment Because of Wrong Applications System Names
(Doc ID 202483.1)
We recently faced an issue after development instance cloned from production.
adPatch Failed with the below errors.

The Applications System names per the APPL_TOP and the database are different.
Applications System name per the APPL_TOP: EBSDEV
Applications System name per the database: EBSOLTP
If you continue, the Applications System name per the APPL_TOP will be ignored.

Do you wish to continue [No] ?

Cause *:-- The APPLICATIONS_SYSTEM_NAME field in the FND_PRODUCT_GROUPS table was

still filled with the value of the old environment.

NOTE * ;-
When we run FND_CONC_CLONE.SETUP_CLEAN it will clean FND_PRODUCT_GROUPS table and
really not sure why the name of the production
instance appear in the table.

SQL> select APPLICATIONS_SYSTEM_NAME from FND_PRODUCT_GROUPS;

APPLICATIONS_SYSTEM_NAME
����������
EBSOLTP

Solution *:--
update FND_PRODUCT_GROUPS set APPLICATIONS_SYSTEM_NAME =�EBSDEV' ;
commit;
Then we restarted adpatch and it got succeeded.

Clearing Cachec In Oracle E-Business Suite

===========================================:

Apache / iAS Cache clear for 11.5.9 or 11.5.10.x

-------------------------------------------------

- shutdown iAS server

- go to $OA_HTML (for 11.5.9) or $COMMON_TOP (for 11.5.10.x) directory
- backup the directory _pages and delete its contents by running for instance:

rm -rf $COMMON_TOP/_pages/*

- for modplsql caches remove contents of $IAS_ORACLE_HOME/Apache/modplsql/cache

directory
- restart iAS server
Cache clear on middle tier for R12
-----------------------------------

Note: Clearing _pages directory is no longer a recommended solution.

Clearing the _pages in R12 creates blank login page issue, as in R12 the jsp files
does not get compiled automatically.

From Forntend
--------------
- go to "Functional Administrator" responsibility
- select Core Services => Caching Framework => Global Configuration => Clear cache

From backend
------------
- adopmnctl.sh stopall
- rm -fr $INST_TOP/ora/10.1.3/j2ee/oacore/persistence/*
- rm -fr $INST_TOP/ora/10.1.3/j2ee/oafm/persistence/*
- rm -fr $INST_TOP/ora/10.1.3/j2ee/forms/persistence/*
- adopmnctl.sh startall

Cabo
-----
Images and style sheets can be corrupted or out of sync in the cabo caches,you may
need to clear the related directories after backup:

- $OA_HTML/cabo/images/cache
- $OA_HTML/cabo/styles/cache

Time drifts can result in an unexpected behavior such as time-outs. Please check
trace file for more details.
===================================================================================
===========================:

Cause
This problem is due to the Bug 11837095 - "TIME DRIFT DETECTED" APPEARS
INTERMITTENTLY IN ALERT LOG"

Solution
Time drift" error is a " message which can be ignored, to remove the "Warning: VKTM
detected set event 10795 or Apply patch 11837095

SQL> alter system set event="10795 trace name context forever, level 2"
scope=spfile;

Then bounce the DB instances to implement the event/change.

Meaning and technical Impact of the error:

If the time drifts occurs less than 1sec and 5 sec for forward and backward
respectively, then it is permissible and OK.
If the traces are emitting time drifts of amount beyond these ranges, then it needs
to be analyzed.
Most of the times, during high loads, there would be issues with underlying OS due
to virtual memory, network time protocol improper configuration etc.

In general VKTM process need to be scheduled in every 10ms, if due to above reasons
this is not happening, occurs less than 1sec and 5 sec then it is permissible.
Eventually, this probably would cause the resource manager to take improper
decisions and can lead to a hang in worst case.

Time Drift Detected. Please Check VKTM Trace File for More Details (Doc ID
1347586.1)

1.Blank EBS R12 Login page

===========================:

Solution:

- The first thing you need to check always is DB and listener is running fine.
- In case you are are not aware then I must tell you, its better to check if "apps"
user is working fine.
- check is the Alert Log, as there may be issues related to Database.

Later comes the Apache logs. Location is "$LOG_HOME/ora/10.1.3/Apache".

The files are
error_log
access_log,

check the latest ones.

Following the steps to resolve the above issue:

1- Stop all application services

$INST_TOP/admin/scripts/adstpall.sh

2- Remove any lock files from following folders:

$INST_TOP/ora/10.1.3/j2ee/oacore/persistence/oacore_default_group_1
$INST_TOP/ora/10.1.3/j2ee/oafm/persistence/oafm_default_group_1
$INST_TOP/ora/10.1.3/j2ee/forms/persistence/forms_default_group_1

3- Compile the JSP files with the following command

cd $FND_TOP/patch/115/bin
perl ojspCompile.pl --compile --flush -p 2

4 -Run Autoconfig first on the DB Tier, and then on APPS Tier

5 -Start appl services

$ADMIN_SCRIPTS_HOME/adstrtall.sh

2. Concurrent Manager not starting after Cloning

=================================================:

Solution:

- Shutdown the apps services

EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;
EXIT;

- Ran AutoConfig on all tiers, firstly on the DB tier and then the APPS tiers.
- Start the application services
Actually FND_CONC_CLONE.SETUP_CLEAN clears up the tables with nodes information and
when we run autoconfig, it repopulates these tables with correct node information.

3.Concurrent manager trouble shooting

======================================:

1. First check the CM is up or not by using below any one procedure.

i. ps �ef|grep FNDLIBR
ii. adcmctl.sh status apps/appsPWD
iii. Login as system administrator responsibilities go to the below navigation
Concurrent -> manager -> Administer -> see the Actual and target for all the
managers

2. If CM in down check the internal manager Logfile in $APPLCSF/APPLLOG location

for errors.
3. If any errors related to FNDFS then check the Application listener STATUS , if
it is not running start it.
4. If CM is up/running then log file and output file are not able see the user from
the front end then check the Application listener is status if it is not running
then start it.

4.If User Complain For Long Running Request's, Do The Following.

================================================================:

- Check the long requests from front-end

system administrator > OAM > Concurrent Request --- choose phase=running and
status=normal and select long running requests.
- Check the Statistics,History Runs of that program & Based on this timelines we
need to decide the long running Request.
- Check The load on DB node to ensure that High Resource Usage is not the Main
cause.i troubleshoot
- Check DB locks in The Databse To Ensure that This Session is not blocked by any
other session.
- Check the CM status and ICM status.
- Check any Locks on DB particularly related to that program.
- Check any INVALID objects related to that program.
- Check any incompatible requests/programs are running for that program.
Login as system administrator responsibility and query the long running request
/program. Navigate to concurrent program define query that long running request in
the same form select incompatible requests .
If any incompatible request is running then find the user name who is running that
program inform them regarding the incompatibilities

Archiving Error
=================:
ERROR: ORA-00257: archiver error. Connect internal only, until freed.

Cause: The archiver process received an error while trying to archive a redo log.
If the problem is not resolved soon, the database will stop executing transactions.
The most likely cause of this message is the destination device is out of space to
store the redo log file.

Action: Check archiver trace file for a detailed description of the problem. Also
verify that the device specified in the initialization parameter ARCHIVE_LOG_DEST
is set up properly for archiving.alter database flashback on
There is two possible way to solution.
1. without increasing DB_RECOVERY_FILE_DEST_SIZE.
2. by increasing DB_RECOVERY_FILE_DEST_SIZE.

Without increasing DB_RECOVERY_FILE_DEST_SIZE.

1. Check whether the database is in archive log mode and automatic archiving is
enabled.

SQL> archive log list;

Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 29
Next log sequence to archive 31
Current log sequence 31

2. If archive destination is defined by USE_DB_RECOVERY_FILE_DEST, find the archive

destination by:

SQL> show parameter db_recovery_file_dest;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
C:\oracle\product\10.2.0/flash_recovery_area
db_recovery_file_dest_size big integer 2G
Check what the value for db_recovery_file_dest_size.

3. Find the space used in flash recovery area by using following SQL:

col ROUND(SPACE_LIMIT/1048576) heading �Space Allocated (MB)� format 999999

col round(space_used/1048576) heading �Space Used (MB)� format 99999
col name format a40
select name, round(space_limit/1048576) As space_limit,round(space_used/1048576) As
space_used
from v$RECOVERY_FILE_DEST;
4. if SPACE_USED is equal to SPACE_LIMIT of db_recovery_file_dest, move the archive
logs to different destination.

5. Archive all the log files

SQL> alter system archive log all;

6. Just switch the logs to verify

SQL> alter system switch logfile;

7. DB_RECOVERY_FILE_DEST_SIZE is to delete (archive log) files from
DB_RECOVERY_FILE_DEST if you are sure you have backups and the archived logs are no
longer necessary.

$rman target /
RMAN>delete archivelog until time 'SYSDATE-1';
or,
RMAN>delete archivelog all;
By increasing DB_RECOVERY_FILE_DEST_SIZE.
1. See the path of flash recovery area.

SQL> show parameter db_recovery_file_dest;

2. Increase the Flash Recovery Area

SQL> ALTER SYSTEM SET db_recovery_file_dest_size='10G' SCOPE=BOTH;

Sytem Altered.

Troubleshooting guide for "ORA-3136 WARNING inbound connection timed out" seen in
the alert log.
===================================================================================
===============:

Troubleshooting Tips:

The "WARNING: inbound connection timed out (ORA-3136)" in the alert log indicates
that the client was not able to complete the authentication process within the
period of time specified by the parameter SQLNET.INBOUND_CONNECT_TIMEOUT.

You might also see the errors ORA-12170 or TNS-12535 in the sqlnet.log that is
generated on the server.
Check $ORACLE_HOME/network/log for this file. This entry should contain client
address from which the timeout originated and may be helpful in determining how to
troubleshoot the issue. Some applications or JDBC thin driver applications may not
have these details. The sqlnet.log file is not generated by default in 11g and
newer.

From 10.2.0.1 onwards the default setting for the parameter

SQLNET.INBOUND_CONNECT_TIMEOUT is 60 seconds. If the client is not able to
authenticate within 60 seconds, the warning would appear in the alert log and the
client connection will be terminated.

Note: This timeout restriction was introduced to combat Denial of Service (DoS)
attack whereby malicious clients attempt to flood database servers with connect
requests that consumes resources.

The following are the most likely reasons for this error -

-Server gets a connection request from a malicious client which is not supposed to
connect to the database. In this case the error thrown would be the expected and
desirable behavior. You can get the client address for which the error was thrown
in the sqlnet.log file that is local to the database.
-The server receives a valid client connection request but the client takes a long
time to authenticate more than the default 60 seconds.
-The DB server is heavily loaded due to which it cannot finish the client logon
within the timeout specified.

To understand what is causing this issue, following checks can be done:

The default value of 60 seconds is good enough in most conditions for the database
server to authenticate a client connection. If it is taking longer, then it's worth
checking the following items before implementing the workaround:

1.Check whether local connection on the database server is successful & quick.
2.If local connections are quick ,then check for underlying network delay with the
help of your network administrator.
3.Check whether your Database performance has degraded in anyway.
4.Check alert log for any critical errors for eg, ORA-600 or ORA-7445 and get them
resolved first.
These critical errors might have triggered the slowness of the database server.

It is often necessary to increase the values for INBOUND CONNECT TIMEOUT at both
the listener and the database in order to resolve this issue. It is usually
advisable to set the database (sqlnet.ora) value slightly higher than the listener
(listener.ora). The authentication process is more demanding for the database
than the listener.

To set these parameters to use values higher than the default of 60 seconds, follow
these instructions and restart the listener.There is no need to restart Oracle:

Edit the server side sqlnet.ora file and add this parameter:

SQLNET.INBOUND_CONNECT_TIMEOUT=<n> Where <n> is the value in seconds.

E.g.:
SQLNET.INBOUND_CONNECT_TIMEOUT = 120

Edit the listener.ora file and add this parameter:

INBOUND_CONNECT_TIMEOUT_<listenername> = <n> Again, where <n> is the timeout value

in seconds.
For example if the listener name is LISTENER then use:
INBOUND_CONNECT_TIMEOUT_LISTENER = 110

From Oracle version 10.2.0.1 onwards the default value of

INBOUND_CONNECT_TIMEOUT_<listenername> is 60 seconds. For previous releases it is
zero or OFF by default.

How to check whether inbound timeout is active for the listener and database
server:

For example, INBOUND_CONNECT_TIMEOUT_<listener_name> =110

You can check whether the parameter is active or not by simply doing telnet to the
listener port.
$ telnet <database server IP> <listener port>
for eg.

$ telnet 123.23.23.23 1521

The telnet session should disconnect after 110 seconds which indicates that the
inbound connection timeout for the listener is active.
Alternatively, check at the LSNRCTL prompt using:

LSNRCTL>set current_listener <listener_name>

LSNRCTL>show inbound_connect_timeout

To check whether database server SQLNET.INBOUND_CONNECT_TIMEOUT is active:

Eg.

SQLNET.INBOUND_CONNECT_TIMEOUT=120

a. For Dedicated server setup, enable the support level sqlnet server tracing will
show the timeout value as below:
niotns: Enabling CTO, value=120000 (milliseconds) <== 120 seconds
niotns: Not enabling dead connection detection.
niotns: listener bequeathed shadow coming to life...

b. For shared Server setup,

$ telnet <database server IP> <dispatcher port>
Example.

$ telnet 123.23.23.23 51658

The telnet session should disconnect after 120 seconds which indicates that the
sqlnet.inbound_connect_timeout is active.
Reference metalink Doc ID 465043.1

We are bouncing the oacores after deploying oaf changes with below command but
sometimes developers complain that changes are not reflecting? Do we also need to
bounce the apache?
==================================================:

Ans)

admanagedsrvctl.sh stop oacore_server1

admanagedsrvctl.sh stop oacore_server2

admanagedsrvctl.sh start oacore_server1

admanagedsrvctl.sh start oacore_server2

WEBLOGIC MANAGED SERVER STATUS STRUCK IN STARTING

==================================================:

We faced the issue while starting the weblogic managed server, the status of the
server struck in STARTING.

W could not able to find a valid error messages in the log files
Managed Server Log File:
<30-Oct-2013 11:13:29 o'clock GMT> <Notice> <WebLogicServer> <BEA-000365> <Server
state changed to STARTING>

No logs are getting printed after this.

Node Manager Log File:

<30-Oct-2013 11:09:44> <INFO> <SOACoreDomain> <MS1> <Server failed during startup

so will not be restarted>
<30-Oct-2013 11:09:44> <WARNING> <Exception while starting server 'MS1'>
java.io.IOException: Server failed to start up. See server output log for more
details.
at
weblogic.nodemanager.server.AbstractServerManager.start(AbstractServerManager.java:
200)
at weblogic.nodemanager.server.ServerManager.start(ServerManager.java:23)
at weblogic.nodemanager.server.Handler.handleStart(Handler.java:604)
at weblogic.nodemanager.server.Handler.handleCommand(Handler.java:121)
at weblogic.nodemanager.server.Handler.run(Handler.java:71)
at java.lang.Thread.run(Thread.java:662)

Cause:

The root cause of this issue is somehow the ldap directory of the server got
corrupted.

Solution:

To resolve this issue:

Kill the managed server
Remove the ldap folder from the following location
<<DOMAIN_HOME>>/servers/<<Managed Server>>, this file will be auto generated while
restarting the server.
Restart the server

12.2 Patch Edition Auto config error

======================================:

12.2 Patch Edition Auto config error.

Oracle 12.2.4 EBS
File system: PATCH
jtfictx.sh INSTE8_PRF 1
okladmprf.sh INSTE8_PRF 1
txkJavaMailerCfg.sh INSTE8_PRF 1
txkWebServicescfg.sh INSTE8_PRF 1

[APPLY PHASE]
AutoConfig could not successfully execute the following scripts:
Directory: /app/dev/appldev/SID/fs1/FMW_Home/webtier/perl/bin/perl -I
/app/dev/appldev/SID/fs1/FMW_Home/webtier/perl/lib/5.10.0 -I
/app/dev/appldev/SID/fs1/FMW_Home/webtier/perl/lib/site_perl/5.10.0 -I
/app/dev/appldev/SID/fs1/EBSapps/appl/au/12.0.0/perl -I
/app/dev/appldev/SID/fs1/FMW_Home/webtier/ohs/mod_perl
/lib/site_perl/5.10.0/sun4-solaris-thread-multi-64
/app/dev/appldev/SID/fs1/inst/apps/SID_CONTEXTNAME/admin/install
txkGenADOPWrapper.pl INSTE8_APPLY 1

AutoConfig is exiting with status 28

AutoConfig execution completed on Sat Jan 10 12:16:44 2017
Time taken for AutoConfig execution to complete : 2 mins 51 secs

Solution:
To run Autoconfig from the patch file system
you must disable trigger ebs_login prior to running autoconfig
Disable the ebs_login trigger for patch file system

"alter trigger ebs_logon disable" - Ensure you are logged in as the system user
Now run autoconfig with the patch env sourced
Make sure Autoconfig completes ok

Enable the login trigger

"alter trigger ebs_logon enable"
EBSapps.env as Patch option
connect database using system or system/equivalent privileged user

-------------STEPS--------------------------------------------------
sqlplus system/<password>

SQL>alter trigger ebs_logon disable;

Trigger altered.

Then Run Auto config with in patch env

ensure that autconfig completed successfully

and

SQL> alter trigger ebs_logon enable;

-----------------------------------------------------
If you want to restart a failed patch from where it left off, you use restart=yes
==================================================================================:

adop phase=apply patches=1234 restart=yes

If you want to ignore a previously failed patch and apply a different one, you use
abandon=yes
adop phase=apply patches=3456 abandon=yes

So, if you gonna apply the patch in downtime, your syntax is correct

ORA-01092 ORA-00604 ORA-04024 While trying to Open the database

================================================================:

Symptoms:

You are trying to open the database read only or read write , but the following
errors occur:

SQL> alter database open read only;

alter database open read only
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00604: error occurred at recursive SQL level 1
ORA-04024: self-deadlock detected while trying to mutex pin cursor 0x7C92EC118
Process ID: 14520
Session ID: 1423 Serial number: 25044
Logs are shipping and applying ok

Changes:

Database was upgraded from 11.2.0.4 to 12.1.0.2

Cause:

The issue is caused due to Unpublished Bug 21799609 - ORA-04024 DEADLOCK ON STARTUP
ON SYS.ECOL$ ON LOAD HISTOGRAMS which has been closed as duplicate of BUG 19469538
- LOADING OF DATA IN ECOL$ TABLE IS NON-OPTIMAL FOR QUERIES

Fixed Version : 12.2.0.1

Solution:

Option 1

In the database, implement the workaround from Bug 21799609 :

SQL> alter system set "_fix_control"='9550277:ON';
Once set try to Open the database
SQL>alter database open read only;
Or
SQL>alter database open ;
Or

Option 2

Check for availability of one off Patch using Patch 19469538 for your Platform and
apply the permanent fix for this issue
Reference metalink Doc ID 2073899.1

ORA-28000: the account is locked

=================================:

Issue: On login to the database use gets "ORA-28000: the account is locked" error
like below.

[oracle@database orcl]$ sqlplus scott/tiger

SQL*Plus: Release 11.2.0.2.0 Production on Mon Feb 11 22:24:23 2013
Copyright (c) 1982, 2010, Oracle. All rights reserved.
ERROR:
ORA-28000: the account is locked

Solution:

There are two situations when your account could be locked.

1. New Database Creation: When you create a new database all default accounts are
"EXPIRED & LOCKED" except SYS and SYSTEM. So, you need to unlock and change
password to use them.

SQL> select username,account_status from dba_users;

USERNAME ACCOUNT_STATUS
------------------------------ --------------------------------
SYS OPEN
SYSTEM OPEN
SCOTT EXPIRED & LOCKED
OUTLN EXPIRED & LOCKED
MGMT_VIEW EXPIRED & LOCKED

-----------------------------------------------------------------
30 rows selected.

2. Failed Login Attempts: Default profile in oracle Database Management Software

has 10 failed login attempts and after that it locks the user account. So, need to
unlock this.

SQL> select * from dba_profiles where resource_name like 'FAILED_LOGIN_ATTEMPTS%';

PROFILE RESOURCE_NAME RESOURCE

LIMIT
------------------------------ -------------------------------- --------
----------------------------------------
DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10
MONITORING_PROFILE FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED

Connect as sysdba user and unlock the account using below commands

[oracle@database orcl]$ sqlplus sys as sysdba

SQL> alter user scott identified by tiger account unlock;
User altered.

Now, Try to reconnect using locked user

SQL> connect scott/tiger

Connected.
SQL>
Account is unlock and ready to use.

Error 'PLS-00801: internal error [1401]' received when recompiling packages

============================================================================:

Error:

SQL> alter package OE_DEFAULT_LINE_PATTR compile body;

Warning: Package Body altered with compilation errors.

SQL> show errors

Errors for PACKAGE BODY OE_DEFAULT_LINE_PATTR:

LINE/COL ERROR
-------------------------------------
0/0 PLS-00801: internal error [1401]
0/0 PLS-00801: internal error [1401]
0/0 PLS-00801: internal error [1401]
0/0 PLS-00801: internal error [1401]
0/0 PLS-00801: internal error [1401]
1604/17 PL/SQL: Statement ignored
-- Steps To Reproduce:
1. Open database SQL*Plus session
2. Run the below command to recompile package

alter package OE_DEFAULT_LINE_PATTR compile body;

Cause:

This issue is caused by inconsistencies in underlying application codelines and

binaries as a result of recent patching and (potential) database upgrades.

Solution:

To implement the solution, please execute the following steps:

1. Review the comments in the 2 scripts below:

$ORACLE_HOME/rdbms/admin/utlirp.sql
$ORACLE_HOME/rdbms/admin/utlrp.sql

NOTE: Please note the requirements under "USAGE"to restart the database in UPGADE-
mode before running script.

NAME
utlirp.sql - UTiLity script to Invalidate Pl/sql modules

DESCRIPTION
This script can be used to invalidate and all pl/sql modules
(procedures, functions, packages, types, triggers, views)
in a database.

This script must be run when it is necessary to regenerate the

compiled code because the PL/SQL code format is inconsistent with
the Oracle executable (e.g., when migrating a 32 bit database to
a 64 bit database or vice-versa).
Please note that this script does not recompile invalid objects
automatically. You must restart the database and explicitly invoke
utlrp.sql to recompile invalid objects.

USAGE
To use this script, execute the following sequence of actions:
1. Shut down the database and restart in UPGRADE mode
(using STARTUP UPGRADE or ALTER DATABASE OPEN UPGRADE)
2. Run this script
3. Shut down the database and restart in normal mode
4. Run utlrp.sql to recompile invalid objects. This script does
not automatically recompile invalid objects.

NOTES
* This script must be run using SQL*PLUS.
* You must be connected AS SYSDBA to run this script.
* This script expects the following files to be available in the
current directory:
standard.sql
dbmsstdx.sql
* There should be no other DDL on the database while running the
script. Not following this recommendation may lead to deadlocks.

NAME
utlrp.sql - Recompile invalid objects

DESCRIPTION
This script recompiles invalid objects in the database.

When run as one of the last steps during upgrade or downgrade,

this script will validate all remaining invalid objects. It will
also run a component validation procedure for each component in
the database. See the README notes for your current release and
the Oracle Database Upgrade book for more information about
using utlrp.sql

Although invalid objects are automatically re-validated when used,

it is useful to run this script after an upgrade or downgrade and
after applying a patch. This minimizes latencies caused by
on-demand recompilation. Oracle strongly recommends running this
script after upgrades, downgrades and patches.

2. Run these scripts using SQL*Plus as SYSDBA

3. Review your invalid listing for resolution

Reference metalink Doc ID 949222.1

Processes are Not Starting Due To ORA-00020

Symptoms:

We are unable to start all the ASAP servers and following error messages appeared
in CTRL diag file:

085230.889:84: LOW:ASC_cprpcexec() :1219:ctlib.c

RPC(install_exit_handler) Complete in 0ms, First Result in 0ms
>> 085230.890:84:PROG:System Event :1074:process.c
ASAP System Event: APP_STRT
Successful Local Startup of Server SRP_JAMD (Generic SRP_JAMD), Pid 10902
>> 085230.896:84: LOW:ASC_cpalloc :1573:ctlib.c
CS_MAX_CONNECT property set to [25] max connections per context
>> 085231.023:84:PROG:checkerr :1830:ocilib.c
Error - ORA-00020: maximum number of processes (%s) exceeded
errcode[20]
>> 085231.023:84:SANE:DBLogon_oci8 :1635:ocilib.c
Error: Failed OCISessionBegin,status[0]
>> 085231.024:84:PROG:System Event :83 :ocilib.c
ASAP System Event: SYS_ERR
Error: Unable to open OCI connection
>> 085231.024:84:PROG:System Event :309 :ctlib.c
ASAP System Event: SYS_ERR
Error: Unable to open OCI connection'>>>>>>>>>>>>

Cause:

This is an Oracle resource issue. An operation requested a resource that was

unavailable. The system has reached the maximum number of processes the database is
allowed to create.

CTRL diag file shows: "Error - ORA-00020: maximum number of processes (%s) exceeded
errcode[20]"

Solution:

To implement the solution, please execute the following steps:

1. Stop ASAP
2. Ask DBA to increase Oracle configuration parameter called 'processes'
3. Re-start Database
4. Re-start ASAP

Reference metalink Doc ID 834153.1

Apps Issue
==========:

R12 E-Business Suite Users Report Responsibilities Are Missing From The EBS Home
Page, After Login The Responsibility Page Is Blank

Symptoms:

-Intermittently responsibilities are missing from the Personal Home Page, or after
user login the responsibilities homepage is blank.
(or)
-Missing responsibilities for a user in the navigator page during logon.
-After upgrading and patching, the System Administrator responsibility no longer
appears in the Navigator.
-Some users cannot see/receive their open notifications due to missing
responsibilities.
-Some users get notification e-mails even though their responsibilities are end-
dated
-If a user is end-dated, a user's responsibility creates duplicate row
-Newly added responsibility is not displayed until Apache is bounced
-Intermitent issue: After resetting user passwords using the "Login Assistance " >
"Forgot Password" link, users do not see their responsibilities in home page and
get the following message:
"There are no active responsibilities available for this user"
"System Administrator" responsibility missing
Cause:

Workflow Roles are out of sync.

Solution:

To resolve the issue test the following steps in a development instance and then
migrate accordingly:

1. Run the sync responsibility data into the workflow tables concurrent request via
the following steps:

a. Navigate -> System Administrator > Concurrent > Request: Submit a New Request
b. Select request "Sync responsibility role data into the WF table"

2. Retest the user login and confirm the responsibilities now appear as expected.

3. If the issue still occurs, test the following set of additional steps to see if
the problem is resolved:

a. Run request -> "Compile Security" - For parameter Everything, select Yes
b. Run request -> "Workflow Directory Services User/Role Validation" with: 'Fix
dangling user/roles', 'Add missing user/role assignments' and Update WHO columns in
WF tables set to "yes"
c. Run request -> "Synchronize WF LOCAL tables"
d. Run request -> "Create FND_RESP WF ROLES"
e. Run request -> "Sync responsibility role data into the WF table."
f. Follow MOS Doc ID 759038.1 How To Clear The Cache Using Functional
Administrator.

4. Retest the user login and confirm the responsibilities now appear.

Reference metalink Doc ID 2259375.1

NodeManager Issue
==================:

Node Manager startup fails in Oracle SOA 12C

=============================================:

The Node Manager failed to start in Oracle SOA Suite 12C with the following error.

[Sat Nov 09 01:29:46 2013] [I] [RunJavaApp] Invoking main class

<Nov 9, 2013 1:29:47 AM GMT> <INFO> <Loading domains file:
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\nodemanager
\nodemanager.domains>
<Nov 9, 2013 1:29:50 AM GMT> <INFO> <Loading identity key store:
FileName=C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\nodeman
ager\security\DemoIdentity.jks, Type=jks, PassPhraseUsed=true>
<Nov 9, 2013 1:29:50 AM GMT> <SEVERE> <Fatal error in NodeManager server>
weblogic.nodemanager.common.ConfigException: Identity key store file not found:
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\nodemanager\secu
rity\DemoIdentity.jks
at weblogic.nodemanager.server.SSLConfig.loadKeyStoreConfig(SSLConfig.java:170)

The actual root cause of the problem is the jks file is not configured properly for
nodemanager.
To fix the issue:-

Copy the file <domainhome>\security\DemoIdentity.jks to

<domainhome>\nodemanager\security\DemoIdentity.jks

Fatal error in NodeManager server while starting Weblogic server

=================================================================:

SOLUTION:
Error:-

<Jun 10, 2015 3:51:45 AM PDT> <SEVERE> <Fatal error in NodeManager server>
weblogic.nodemanager.common.ConfigException: Identity key store file not found:
/u01/app/Middleware12c/oracle_common/common/nodemanager/security/DemoIdentity.jks
at
weblogic.nodemanager.server.SSLConfig.loadKeyStoreConfig(SSLConfig.java:170)
at weblogic.nodemanager.server.SSLConfig.access$000(SSLConfig.java:32)
at weblogic.nodemanager.server.SSLConfig$1.run(SSLConfig.java:111)
at java.security.AccessController.doPrivileged(Native Method)
at weblogic.nodemanager.server.SSLConfig.<init>(SSLConfig.java:108)
at weblogic.nodemanager.server.NMServer.<init>(NMServer.java:121)
at weblogic.nodemanager.server.NMServer.main(NMServer.java:383)
at weblogic.NodeManager.main(NodeManager.java:31)

Solution:

The DemoIdentity.jks file is not available in the

/u01/app/Middleware12c/oracle_common/common/nodemanager/security

We have copied DemoIdentity.jks file in the above mentioned directory and its
worked properly.
starup issue

=============:

BEA-000362 Server failed. Reason: [Management:141268]Parsing Failure in config.xml

<Sep 6, 2015 4:21:30 PM IST> <Info> <Management> <BEA-141107> <Version: WebLogic

Server 10.3.5.0 Fri Apr 1 20:20:06 PDT 2011 1398638 >
<Sep 6, 2015 4:21:30 PM IST> <Critical> <WebLogicServer> <BEA-000362> <Server
failed. Reason: [Management:141268]Parsing Failure in config.xml on line 1, column
1: Content is not allowed in prolog.>
<Sep 6, 2015 4:21:30 PM IST> <Notice> <WebLogicServer> <BEA-000365> <Server state
changed to FAILED>
<Sep 6, 2015 4:21:30 PM IST> <Error> <WebLogicServer> <BEA-000383> <A critical
service failed. The server will shut itself down>
<Sep 6, 2015 4:21:30 PM IST> <Notice> <WebLogicServer> <BEA-000365> <Server state
changed to FORCE_SHUTTING_DOWN>

Process exited.

If you are getting above error means, Jdeveloper is not closed properly. And
config.xml is corrupted.
Deleting DefaultDomain folder or config.xml file will resolve this error.

Deleting either of the one will create new weblogic domain fresh.
Config.xml file path:
C:\Users\dileep\AppData\Roaming\JDeveloper\system11.1.2.4.39.64.36.1\DefaultDomain\
config

weblogic startup issue

=======================:

Failed Not Restartable in WebLogic Managed Server

FAILED_NOT_RESTARTABLE _STATE

Reasons of this error

WebLogic Server which you are trying to start is already running.
WebLogic Server which you are trying to start did not stop cleanly.

By default when weblogic server starts, it creates two lock files

DOMAIN_HOME/servers/Maganged_server_name/tmp/servermame.lok
DOMAIN_HOME/servers/Maganged_server_name/data/ldap/ldapfiles/EmbeddedLDAP.lok

When WebLogic server stops, it removes these two files. If you not stop server
properly these lock files remains on that location and creating a problem when you
attempt to start a server again and after more than one attempt your server goes in
FAILED_NOT_RESTARTABLE state.

Note: There could be other process using this port

How you can identify which port is configured for weblogic server?
To identify port configured for weblogic server open weblogic configuration file
DOMAIN_HOME/config/config.xml and search for listen-port
You should see entry like
<listen-port>7003</listen-port>

Solution:-
If server is not running then you can safely remove these lok files under WebLogic
server. And if server is running then trying to stop it from console, backend or by
killing the process id of the particular server then remove the .lok files.

Note: If this is weblogic managed server (not Admin Server) then you can safely
remove entire managed server directory (including sub directories)
DOMAIN_HOME/servers/serverName or rename it as a backup. When you start managed
server again, Admin Server will create these directories.

g:\prints\issuse\ora 19802 error.txt

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ORA-19802 Error: "Cannot Use Db_recovery_file_dest Without
DB_RECOVERY_FILE_DEST_SIZE

Error:
ORA-19802 error: "cannot use DB_RECOVERY_FILE_DEST without
DB_RECOVERY_FILE_DEST_SIZE."

Cause:

The problem is caused by the fact that these two settings are interdependent and
they must both be set to valid values.

Solution:
Ensure both parameters are properly set.

Use:
ALTER SYSTEM set DB_RECOVERY_FILE_DEST_SIZE
and/or
ALTER SYSTEM set DB_RECOVERY_FILE_DEST

Reference metalink (Doc ID 749595.1)

g:\prints\issuse\patch errors1.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following Oracle Forms objects did not generate successfully:

ont forms/US OEXOEBVR.fmx

po forms/US POXPOEPO.fmx
wip forms/US WIPTXCFM.fmx

patch_101to125

Error loading seed data for FND_COLUMN: APPLICATION_SHORT_NAME = PN,

BUILDING_BLOCK_NAME = TABLES,
TABLE_NAME = PN_VAR_CONSTRAINTS_ALL, COLUMN_NAME = CONSTR_CAT_CODE, ORA-12899:
value too large for
column "APPLSYS"."FND_COLUMNS"."DESCRIPTION" (actual: 246, maximum: 240)
Error loading seed data for FND_COLUMN: APPLICATION_SHORT_NAME = PN,
BUILDING_BLOCK_NAME = TABLES,
TABLE_NAME = PN_VAR_DEDUCTIONS_ALL, COLUMN_NAME = DEDUCTION_TYPE_CODE, ORA-12899:
value too large for
column "APPLSYS"."FND_COLUMNS"."DESCRIPTION" (actual: 246, maximum: 240)

sol:

PN Error When Applying PF_FIN_G (Doc ID 1051923.1)

download the patch 9085442 unzip it.
copy ldt file from patch to current location
$Header pntabreg.ldt 115.23 2005/02/09 11:36:11 (before file version)

cp /backup/stage/extended/9085442/pn/patch/115/import/US/pntabreg.ldt
/prod/dev/appstier/appltop/pn/11.5.0
/patch/115/import/US/.

adident Header
/prod/dev/appstier/appltop/pn/11.5.0/patch/115/import/US/pntabreg.ldt
$Header pntabreg.ldt 115.24 2009/10/28 11:52:02 vgovvala ship

The following Oracle Forms objects did not generaGte successfully:

au resource PNTSPACE.pll
au resource PNSULOCN.pll

patch 126to150

FAILED: file iexscore.ldt on worker 3.

FAILED: file iexsctyp.ldt on worker 4.

Calling FNDLOAD function

The values of input parameters are:argc=[7],
argv[0]=APPS/*****, argv[1]=0, argv[2]=Y, argv[3]=UPLOAD_PARTIAL,
argv[4]=@IEX:patch/115/import/iexscore.lct,
argv[5]=@IEX:patch/115/import/US/iexsctyp.ldt, argv[6]=IEX_SCORE_COMP_TYPES,
dn_inslog=[/prod/dev/appstier/appltop/admin/dev/log]

Returned from function FNDLOAD function

The values of output parameters are:status=[-1073778600]

Log file: /prod/dev/appstier/appltop/admin/dev/log/US_iexsctyp_ldt.log

Error calling FNDLOAD function

Dumping from LCT/LDT files

(/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/iexscore.lct(115.18.11510.6
), /prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/US/iexscore.ldt) to
staging tables
Dumping LCT file
/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/iexscore.lct(115.18.11510.6)
into FND_SEED_STAGE_CONFIG
Dumping LDT file
/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/US/iexscore.ldt into
FND_SEED_STAGE_ENTITY
A syntax error occurred at line 81 in file
/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/US/iexscore.ldt
No data found for upload

Calling FNDLOAD function

The values of input parameters are:argc=[7],
argv[0]=APPS/*****, argv[1]=0, argv[2]=Y, argv[3]=UPLOAD_PARTIAL,
argv[4]=@IEX:patch/115/import/iexscore.lct,
argv[5]=@IEX:patch/115/import/US/iexscore.ldt, argv[6]=IEX_SCORES,
dn_inslog=[/prod/dev/appstier/appltop/admin/dev/log]

Returned from function FNDLOAD function

The values of output parameters are:status=[-1073778600]

Log file: /prod/dev/appstier/appltop/admin/dev/log/US_iexscore_ldt.log

Error calling FNDLOAD function

Dumping from LCT/LDT files

(/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/iexscore.lct(115.18.11510.6
), /prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/US/iexsctyp.ldt) to
staging tables
Dumping LCT file
/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/iexscore.lct(115.18.11510.6)
into FND_SEED_STAGE_CONFIG
Dumping LDT file
/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/US/iexsctyp.ldt into
FND_SEED_STAGE_ENTITY
A syntax error occurred at line 237 in file
/prod/dev/appstier/appltop/iex/11.5.0/patch/115/import/US/iexsctyp.ldt
No data found for upload

Adctrl Option 8 Does Not Skip Failed Worker (Doc ID 946320.1)

apply patch 8721245

stop the present patch and apply the patch.(take bkp of rf9 and
fnd_install_processes,ad_deferred_jobs)
after applying the patch rerun the previous one. (restore rf9 and
fnd_install_processes,ad_deferred_jobs)
and skip the failed jobs

FAILED: file iexstst.ldt on worker 1.

FAILED: file iexxmlqry.ldt on worker 2.
FAILED: file iexstst1.ldt on worker 3.
logfiles are in /prod/dev/appstier/appltop/admin/dev/log/backuplog

The following Oracle Forms objects did not generate successfully:

au resource IEXAGTAB.pll
au resource IEXCRHLD.pll
au resource IEXDISLB.pll
au resource IEXFBALI.pll
au resource IEXFULFL.pll
au resource IEXHIPAD.pll
au resource IEXRCINT.pll
au resource IEXRCALL.pll
au resource IEXTRLIB.pll
au resource IEXPYPRS.pll

The following Oracle Forms objects did not generate successfully:

iex forms/US IEXFBALI.fmx

iex forms/US IEXHIPRO.fmx
iex forms/US IEXHIOVW.fmx
iex forms/US IEXLSGEN.fmx
iex forms/US IEXRCALL.fmx

patch 151to175

ORA-00955: name is already used by an existing object

occurred while executing the SQL statement:

CREATE INDEX AP.AP_CREDIT_CARD_TRXNS_N5 ON AP.AP_CREDIT_CARD_TRXNS_ALL (

VALIDATE_CODE, TRANSACTION_DATE, CARD_PROGRAM_ID ) LOGGING STORAGE (
INITIAL 4K NEXT 256K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0
FREELIST GROUPS 4 FREELISTS 4 ) PCTFREE 10 INITRANS 11 MAXTRANS 255
COMPUTE STATISTICS

Error occurred in file

/prod/dev/appstier/appltop/ap/11.5.0/patch/115/sql/b5594117.sql

The following Oracle Forms objects did not generate successfully:

au resource RCVGMLCR.pll

The following Oracle Forms objects did not generate successfully:

iex forms/US IEXHIOVW.fmx

iex forms/US IEXRCALL.fmx

timings:

merged-pre patch 6:30min

44449345 2:30min
merged_76_100 30min
merged_101_125 2hrs
merged_126_150 1:45min
8721245 20min
merged_151_175 5:30min
merged_176_183 1:35min
3999182 1:35min
3756428 40min
total ----------
22:55min

The following Oracle Forms objects did not generate successfully:

sol:

601453.1
Invalid Objects After Applying IEX RUP 4: IEXRCINT_PKG, IEXFULFL_CONTROL (Doc ID
601453.1)

au resource RCVGMLCR.pll
sol:
Compilation Errors On PO_GML_RCV_COMMON When Applying Patch 5058455 (Doc ID
464446.1)

[applmgr@devapp resource]$ pwd

/prod/dev/appstier/appltop/au/11.5.0/resource
[applmgr@devapp resource]$ f60gen module=PNSULOCN.pll userid=apps/apps
module_type=library

invalid obj compile:

=====================

alter package APPS.AP_WEB_MANAGEMENT_REPORTS_PKG compile body;

show error

INE/COL ERROR
-------- -----------------------------------------------------------------
418/10 PL/SQL: SQL Statement ignored
475/47 PL/SQL: ORA-00904: "AERV"."REPORT_LINE_ID": invalid identifier
487/7 PL/SQL: SQL Statement ignored
536/44 PL/SQL: ORA-00904: "AERV"."REPORT_LINE_ID": invalid identifier
712/13 PL/SQL: Statement ignored
712/58 PLS-00364: loop index variable 'VIOLREC' use is invalid
715/13 PL/SQL: Statement ignored
715/62 PLS-00364: loop index variable 'VIOLREC' use is invalid
765/13 PL/SQL: Statement ignored
765/68 PLS-00364: loop index variable 'MAXVIOLREC' use is invalid
1014/10 PL/SQL: SQL Statement ignored

Several AP objects Are Invalid After Patching (Doc ID 1392051.1)--> we follow this
one.

AP_WEB_MANAGEMENT_REPORTS_PKG Package remains Invalid after recompile (Doc ID

1265912.1)
sol: cd /prod/dev/appstier/appltop/ap/11.5.0/patch/115/odf/

adodfcmp mode=views priv_schema=system/manager userid=ap/ap touser=apps/apps

odffile=apoer.odf changedb=yes

g:\prints\issuse\shutdown error.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ORA-01097

Today we face an issue on Oracle 11.1.0.7.0 While testing something completely

different, I noticed that you cannot close a database from a session which has an
uncommitted transaction:

SQL> show user

USER is "SYS"

SQL> shutdown
ORA-01097: cannot shutdown while in a transaction - commit or rollback first
SQL> commit
2 /

Commit complete.

SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>....

g:\prints\issuse\wls starting issue.txt

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
You will need to use the solution below.

Solution 200965611 - WebLogic 8.1 Loss of Administrator Password

Issue:
Administrator password was changed and no one knows what it is.

Solution:
As there is no procedure to override the userid's password, you have to create a
new administrator userid and use it to start WebLogic.

Following are the steps to recover an admin user when you have lost an
administrator's password.
For example create a userid "adminuser" with a password "weblogic"

1. From a DOS or UNIX prompt cd to the WebLogic domain directory and in weblogi c 9
version run setWLSEnv.cmd/setWLSEnv.sh
In weblogic 8 setEnv.cmd/setEnv.sh
Make sure your environment gets set correctly, check that WL_HOME is set. If not
trying running setWLSEnv.sh like this:
. ./setWLSEnv.sh (there is a dot "." then a space then ./setEnv.sh)
In weblogic 8 . ./setEnv.sh
Create an initialization file for the default authenticator
java weblogic.security.utils.AdminAccount adminuser weblogic .
Don't forget to add the "." it is needed.
This should produce a DefaultAuthenticatorInit.ldift in the domains directory.
F:\bea9\weblogic91\server\bin
2. Delete the DefaultAuthenticatormyrealmInit.initialized from
bea9\user_projects\domains\windomain\servers\AdminServer\data\ldap
3. Once you delete this file and try to start the admin server it gets recreated
using the DefaultAuthenticatorInit.ldift file as a template.
4. Rename the boot.properties file.
5. Edit the setWLSEnv.cmd/setEnv.sh file and change:
WLS_USER=adminuser
WLS_PW=web logic
6. Reboot the admin server. If running as a single server, then use the startPIA
command.
7. Put the boot.properties file back to it's original name and change so it looks
like the one below:
username=adminuser
password=we blogic
8. Restart the admin server and those values will then get encrypted.
9. You can now go into the console and fix the system password if you wish or keep
using the adminuser account. To fix the system password from the console, logon as
adminuser and navigate to:
Security / Realms / myrealm / users - Click on system, Next to Password click on
Change. Enter the new password and click apply.