Some more: http://sites.google.com/site/kanitkarvinit/

Google sites - kanitkarvinit

How to backup current adpatch, start another patch then restore your previous adpatch

Reference: Metalink Note: 175485.1

Using the adctrl utility, shutdown the workers.
a. adctrl
b. Select option 3 “Tell worker to shutdown/quit”

c. Backup tables
sqlplus applsys/
create table FND_INSTALL_PROCESSES_3480000
as select * from FND_INSTALL_PROCESSES;
create table AD_DEFERRED_JOBS_3480000
as select * from AD_DEFERRED_JOBS;
drop table FND_INSTALL_PROCESSES;
drop table AD_DEFERRED_JOBS;

d.From OS:
cd $APPL_TOP/admin/
mv restart restart_
mkdir restart

d.Apply the new patch.
Once patch completed.
cd $APPL_TOP/admin/
mv restart restart_
mv restart_ restart

e. recreate the tablessqlplus applsys/
create table FND_INSTALL_PROCESSES
as select * from FND_INSTALL_PROCESSES_3480000;
create table AD_DEFERRED_JOBS
as select * from AD_DEFERRED_JOBS_3480000;
create synonym AD_DEFERRED_JOBS for APPLSYS.AD_DEFERRED_JOBS;
create synonym FND_INSTALL_PROCESSES FOR APPLSYS.FND_INSTALL_PROCESSES;

Now Restart adpatch, it will resume where it stopped previously

Oracle Listener 11g

Listener Commands
LSNRCTL> help
LSNRCTL> change_password
LSNRCTL> save_config #Create new updated listner.ora file
LSNRCTL> quit
LSNRCTL> reload #reread the listener.ora file

Set the configuration
LSNRCTL> set current_listener uwlistener
LSNRCTL> set inound_connect_timeout 0
LSNRCTL> set password
LSNRCTL> set inbound_connect_timeout
LSNRCTL> set trc_level 0 #Set Trace Level
Value Description
0 - 1 off
2 - 3 err
4 - 5 user
6 - 14 admin
15 dev
16 - 99 support

Show the configuration
LSNRCTL> show current_listener
LSNRCTL> show inbound_connect_timeout
LSNRCTL> show startup_waittime
LSNRCTL> show trc_level #Shows the Trace Level
LSNRCTL> show log_status

==>To Prevent remote modification of listener.ora using lsnrctl commands
ADMIN_RESTRICTIONS_[listener_name]=

==>Force the database to register, or reregister, with the listener
ALTER SYSTEM REGISTER;

for more: http://psoug.org/reference/listener.html

SSH Without a Password

Client
Steps: For SSH Without a Password

On the client run the following commands:
$ mkdir -p $HOME/.ssh
$ chmod 0700 $HOME/.ssh
$ ssh-keygen -t dsa -f $HOME/.ssh/id_dsa -P ''

This should result in two files,
$HOME/.ssh/id_dsa (private key) & $HOME/.ssh/id_dsa.pub (public key).
Copy $HOME/.ssh/id_dsa.pub to the server.

Server:
On the server run the following commands:
$ mkdir -p $HOME/.ssh
$ cat id_dsa.pub >> $HOME/.ssh/authorized_keys2
$ chmod 0600 $HOME/.ssh/authorized_keys2

Depending on the version of OpenSSH the following commands may also be required:
$ cat id_dsa.pub >> $HOME/.ssh/authorized_keys
$ chmod 0600 $HOME/.ssh/authorized_keys

An alternative is to create a link from authorized_keys2 to authorized_keys:
$ cd $HOME/.ssh && ln -s authorized_keys2 authorized_keys

On the client test the results by ssh'ing to the server:
$ ssh -i $HOME/.ssh/id_dsa server

(Optional) Add the following $HOME/.ssh/config on the client:
Host server
IdentityFile ~/.ssh/id_dsa
This allows ssh access to the server without having to specify the path to the id_dsa file as an argument to ssh each time.

R12: Oracle responsibility not visible

From 12.1.1 you do not have to run the Synchronize WF Local Tables any more - all of the user roles and changes via the functional process - is processed by a business event in WF Java Deferred. The Workflow Agent listeners process them and all of the user role information is stored in the Workflow Directory Services tables now.
Execute the concurrent program “Workflow Directory Services User/Role Validation” with below parameters:
p_BatchSize – 10000 (Default Value 10000)
p_Check_Dangling – Yes (Default value No)
Add missing user/role assignments – Yes (Default Value No)
Update WHO columns in WF tables – No (Default Value No)
This concurrent program syncs all the user and role related WF tables with latest information viz., WF_LOCAL_ROLES, WF_LOCAL_USER_ROLES, WF_USER_ROLE_ASSIGNMENTS etc..
If after that the problem is not solved yet, then it’s possible to use the System Administrator responsibility: Workflow -> Oracle Applications Manager -> Workflow Manager
Selecting ‘Service Components’ and starting the following listeners:- Workflow Deferred Notification Agent Listener
- Workflow Error Agent Listener
- Workflow Java Deferred Agent Listener
- Workflow Java Error Agent Listener

Fater copy accross unix/ Linux servers

While doing a clone or other activies you all use a tar+scp+untar.
You can get it done in one command and much fater:
tar cvf - >source< | ssh user@server "cd >destination<; tar xvf -"

where:
>source< is the directory/ file to be scp'ed
>destination< is the directory/ path on the destination server where contents are to be copied

HR Trace in Apps HRMS

Setup & Instructions to Run - PYUPIP HR Trace in the Applications (Trace File and DBMS_PIPE) and PYUPIP Against Packages



1a.
Check to see if HR TRACE is already setup as an option off of the Toolbar.

Navigate from within your HR responsibility to the screen which is throwing your error.
Once in the screen ... go to ...

Tools> HR Trace

If the 'HR Trace' function is NOT there, continue with steps 1b - 1c
else, you are done with 'STEP ONE'


1b.
Create a function with the name of HR_DEBUG_TOOLS

As System Administrator responsibility navigate to
Application > Function


from the 'Description' Tab :
Function = HR_DEBUG_TOOLS
User Function Name = HR_DEBUG_TOOLS
Description = PYUPIP function


from the 'Properties' Tab :
Type = SUBFUNCTION
Maintenance Mode Support = None
Context Dependence = Responsibility


Add nothing to the other Tabs: ie Form, Web HTML, Web Host, Region

save your changes



1c.
Add the 'HR_DEBUG_TOOLS' function to the navigation menu.


First find the defined Menu associated with the responsibility that the user
is using by navigating through the following steps:

As System Administrator responsibility navigate to
Security > Responsibility > Define > query the users responsibility


In the middle left of the Responsibilities form, make a note of the MENU being
called by this responsibility.


Once you know the Menu associated with the responsibility, then,
as System Administrator responsibility navigate to
Application > Menu

Query the menu that is tied to the responsibility.

Go to the last Seq (sequence) and add a new Seq (sequence) number.
Make sure you make the new Seq number much larger than the last Seq number
as HR Trace ( function HR_DEBUG_TOOLS ) should always be the last Seq number
for the menu.


Seq = your last Seq value + 200 (this should be a large enough gap)
Prompt = HR Trace
Function = HR_DEBUG_TOOLS
Description = PYUPIP

save your changes




---------------------------------------------------------------------------
STEP TWO - Running HR Trace / Trace File from within the applications
---------------------------------------------------------------------------

2a.
Change responsibilities and navigate to screen where error occurs ...
and before making 'any' changes to the data ... go to ...

Tools > HR Trace > and select the following options:

HR Trace = Trace File
PL/SQL Trace = None
Bind Variable Trace = yes ( check the 'Bind Variable Trace' box )

click OK




2b.
Perform the action on the screen that throws the error, answer OK to the error,
and then stop



2c.
Go to ...
Tools > HR Trace >
click on 'Write Info' button and make note of the trace file name



2d.
The trace file should have been written to the user_dump_dest location
defined in your database.

To find your user_dump_dest location run the following script in sqlplus.


set pagesize 1000
col name for a30
col value for a42
select name, value
from v$parameter
where UPPER(name) = UPPER('user_dump_dest')
order by name;


Go to user_dump_dest location, pull the trace file
and upload the PYUPIP trace file to the tar in metalink.



The step prior to the error thrown in this trace should be the package being run
when the error occured.
The output you read will be in the format of the 'proper name' of the package.
To find the 'sql' name for the package run the following script.


Example:
If the 'proper name' of the package read from the PYUPIP trace is
' per_accrual_calc_functions.Get_Carry_Over '
then you need to know the 'sql' name for the package 'per_accrual_calc_functions'.
To find the 'sql' name, run the following script from sqlplus.
When prompted, enter the 'proper name' of the package, in this case 'per_accrual_calc_functions'.



set pagesize 1000
select name, text
from all_source
where UPPER(name) like UPPER('%&NAME%')
and owner = 'APPS'
and text like '%$Header%'
order by name;



( example of script use )


SQL> set pagesize 1000
SQL> select name, text
2 from all_source
3 where UPPER(name) like UPPER('%&NAME%')
4 and owner = 'APPS'
5 and text like '%$Header%'
6 order by name;
Enter value for name: per_accrual_calc_functions
old 3: where UPPER(name) like UPPER('%&NAME%')
new 3: where UPPER(name) like UPPER('%per_accrual_calc_functions%')

NAME
------------------------------
TEXT
----------------------------------------------------------------------
PER_ACCRUAL_CALC_FUNCTIONS
/* $Header: peaclcal.pkh 115.10 2003/01/28 16:14:05 ptitoren ship $ */

PER_ACCRUAL_CALC_FUNCTIONS
/* $Header: peaclcal.pkb 115.35 2004/02/22 23:42:08 kjagadee ship $ */




Hence, the package body throwing the error would have been peaclcal.pkb
and we would want to run a PYUPIP trace against package peaclcal.pkb
to see what part of the code was throwing the error.





---------------------------------------------------------------------------
STEP THREE - Running PYUPIP against a package
---------------------------------------------------------------------------

3a. From UNIX - cd to where the package that is being executed is stored.
Such as the PTO Carry Over Process - $PAY_TOP/patch/110/sql>pyusptoa.pkb

Make a back up of the package using the 'cp' Unix command
cp pyusptoa.pkb pyusptoa.old



3b. After the first BEGIN statement add:

hr_utility.trace_on (null, 'enter a name')

Example
hr_utility.trace_on (null, 'ORACLE')

Compile and save the package

To compile the package, execute the package from sqlplus and commit such as
SQL> @pyusptoa.pkb

SQL> commit;



3c. From UNIX - $PAY_TOP/bin (this is where the PYUPIP utility is stored) run PYUPIP

To run PYUPIP from Unix execute the following string
PYUPIP >

Example
PYUPIP apps/apps ORACLE > PTOPYUPIP



3d. Execute whatever process that runs your package either from the application
or from sqlplus.

Watch the unix screen and you will see the package being executed




3e. Be sure to turn PYUPIP off after you complete your trace OR
it will bring your database to its knees.

To turn off PYUPIP from sqlplus run the following

SQL> execute hr_utility.trace_off




3f. 'ctrl C' from the Unix prompt to kill your PYUPIP session




3g. Delete the modified PYUPIP package, rename the saved package back to the original name,
and recompile the old backed up package back to the database,
which will recompile the package with the PYUPIP trace statement now gone!!

a. delete the modified package with PYUPIP trace 'turned on' using the 'rm' command:
rm pyusptoa.pkb

b. rename your backed up package back to the original name using the 'cp' command:
cp pyusptoa.old pyusptoa.pkb

c. recompile the original package, with the PYUPIP trace statement gone, through sqlplus,
and commit:

SQL> @pyusptoa.pkb
SQL> commit;





Your PYUPIP trace output file ( from step 3c )should now tell you what section of the package code is
throwing the error, and this is what needs to be looked at.




---------------------------------------------------------------------------
STEP FOUR - Running HR Trace / DBMS_PIPE from within the applications
---------------------------------------------------------------------------


4a. Enter the form you are working with.
Perform the steps necessary to cause the error, but do not do the last step
that actually causes the error.

From the Toolbar select Tools > HR Trace

Select the DBMS_PIPE button under HR Trace.
In the Pipe field, is displayed a value like PIDxx.
Make a note of the PIDxx number.

Select OK to exit the Trace form. PYUPIP is now running on this form.


4b. Open a UNIX session and from your Home Directory execute the PYUPIP command.
$PAY_TOP/bin/PYUPIP apps/ PIDXXX > output.file

Where PIDxx is the PID number recorded and output.file is whatever name you want
for the log file to be named

example:
PYUPIP apps/apps PID87 > PID87_01.txt



4c. Go back to the application and execute the error.


4d. Turn off HR Trace.
From the Tools Menu, select the HR Trace option.
Click the None button under HR Trace.
Click OK to turn off PYUPIP.


4e. Review log file to see where the error is occurring.
-------------------------------------------