Thursday, November 16, 2017

How to check If a patch is applied in R12.2

In eBusiness Suite (EBS) 12.2.x you cannot query the AD_BUGS table to check if patches have been applied.The AD_BUGS table may have entries for patches that were applied but later the patching cycle was aborted (not really applied).


To check whether a patch is really applied use the AD_PATCH.IS_PATCH_APPLIED pl/sql function.Using this API is an alternative method for users without access to Oracle Applications Manager's "Patching and Utilities" feature to determine if a certain patch is applied.



Query to Find in single app tier or shared application tier Environment:
select ad_patch.is_patch_applied('R12',-1,20034256) from dual;

Expected results:
EXPLICIT = applied
NOT APPLIED = not applied / aborted


To check Multiple patches,Please use below query:

SELECT adb.bug_number,ad_patch.is_patch_applied('R12',-1, adb.bug_number) FROM ad_bugs adb WHERE adb.bug_number in ('25820806','26720905',
'24591000','26482811','25828573','26400116','26720231','25994411');


To get output in human readable format:
set serveroutput on;
DECLARE
TYPE p_patch_array_type is varray(30) of varchar2(10);
p_patchlist p_patch_array_type;
p_patch_status varchar2(15);
p_appl_top_id number;
p_result varchar2(15);
p_instance varchar2(15);
procedure println(msg in varchar2)
is
begin
dbms_output.enable(1000000);
dbms_output.put_line(msg);
end;
BEGIN
p_patchlist:= p_patch_array_type('25820806','26720905','24591000','26482811','25828573','26400116','26720231','25994411','89989');
println('=============================');
for i in 1..p_patchlist.count
loop
p_patch_status := ad_patch.is_patch_applied('R12',-1,p_patchlist(i));
case p_patch_status
when 'EXPLICIT' then
p_result := 'APPLIED';
else
p_result := p_patch_status;
end case;
println('Patch ' || p_patchlist(i)|| ' - ' || ' - IS ' || p_result);
end loop;
println('.');
END;
/

Query to find patch information  for a specific node in a multinode environment (1045 is the APPL_TOP ID):
Syntax: select AD_PATCH.IS_PATCH_APPLIED(\'$release\',\'$appltop_id\',\'$patch_no\',\'$language\') from dual;

SELECT adb.bug_number,ad_patch.is_patch_applied('R12', 1045, adb.bug_number) FROM ad_bugs adb WHERE adb.bug_number in (20034256);

APPL_TOP_ID -->you cat gen  from ad_appl_tops table.

Wednesday, October 18, 2017

Virtual Box: Sharing Folders between Host and Virtual Server:

Install Guest Editions:
Devices-->Install Guest Editions-->Reboot the machine-->right click (Autorun)

If it errors out realted to kernel issue,Please  follow below steps.

yum remove kernel-headers
cd /etc/yum.repos.d/
Please check the linux version and enable yum for that version.
vi public-yum-ol6.repo
enable the latest yum repository [public_ol6_latest] & public_ol6_u7_base]
yum remove kernel-headers
yum -y install kernel-uek-devel-$(uname -r)

Oracle VirtualBox:

Devices-->Shared Folders-->Add New Shared Folder button-->Give  Folder Path & share name(Oracle_Apps_122_Linux64 )-->Click on Make permenent

Linux Guest:
Login as root
mount -t vboxsf  Oracle_Apps_122_Linux64  /shared

Wednesday, June 14, 2017

Install MONGODB 3.4 On LINUX 6

a)yum install cyrus-sasl cyrus-sasl-plain cyrus-sasl-gssapi krb5-libs libcurl libpcap net-snmp openldap openssl
b)Download Mongo DB  & Extract The TAR
cd $HOME
curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.4.4.tgz
cd /mongo/
tar -zxvf /home/mongo/mongodb-linux-x86_64-3.4.4.tgz
cp -R -n mongodb-linux-x86_64-3.4.4/ mongodb

c)Add the PATH in /home/mongo/.bash_profile
PATH=/mongo/mongodb/bin:$PATH

d) Create the datafile folder /mongo/data. If we dont specify dbpath ,it will try to  use the default value /data/db.

e)Start the Mongo DB.Run the mongod process at the system prompt.

mongod --dbpath /mongo/data --logpath /tmp/mongo.log --logappend --rest --fork

--dbpath -> Path to our datafiles.
--logpath -->Log file Path
--logappend --> Appending log content to the existing log.
--rest -->Which will enable http interface to the port 28017(default).We can  access it http://localhost:28017
--fork --> It will create the child process and run in background.

     
If we use above command ,datafile from all our databases will be under /mongo/data. If we want to split the datafiles based on database,we have to
specify the parameter  directoryperdb.It will create sub folder with dbname under dbpath.


Ex: mongod --dbpath /mongo/new_data --logpath /tmp/mongo.log --logappend --rest --directoryperdb


[mongo@r12 new_data]$ ls -ld *
drwxrwxr-x 2 mongo mongo  4096 Jun 10 12:38 admin
drwxrwxr-x 2 mongo mongo  4096 Jun 10 13:49 diagnostic.data
drwxrwxr-x 2 mongo mongo  4096 Jun 10 12:38 journal
drwxrwxr-x 2 mongo mongo  4096 Jun 10 12:38 local

Saturday, June 3, 2017

RMAN BASICS

Lets begin with RMAN overviews:
RMAN stands for Recovery Manager, this is client who performs not only backup and recovery for oracle database but also making DBA’s life easier in terms of automation, backup, restore and recovery of database. RMAN consist of some backup utilities and collaborated with your oracle database that combine play a role in database backup.


RMAN components:

Target Database:
Target database is the registered database with the RMAN, on which RMAN is performing backup and recovery operations. All operations performed and practiced ( i.e.metadata is also known as repository. ) by RMAN would be logged in database control file.

RMAN client:
RMAN client is nothing but the executable required to run RMAN and performers its desire task. RMAN client situated in ‘ORACLE_HOME/bin’. No extra efforts would be required to install this client, because this client installed automatically when oracle software being installed.


How RMAN Works Internally:

RMAN backup and recovery operation for a target database are managed by RMAN client. RMAN uses the target database control file to gather metadata about the target database and to store information about its own operations. The RMAN client itself does not perform backup, restore, or recovery operations. When you connect the RMAN client to a target database, RMAN allocates server sessions on the target instance and directs them to perform the operations.The work of backup and recovery is performed by server sessions running on the target database. A channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance.The channel reads data into memory, processes it, and writes it to the output device.

When you take a database backup using RMAN, you need to connect to the target database using RMAN Client.The RMAN client can use Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net. For backup you need to allocate explicit or implicit channel to the target database. An RMAN channel represents one stream of data to a device, and corresponds to one database server session. This session dynamically collect information of the files from the target database control file before taking the backup or while restoring.

For example If you give ‘ Backup database ‘ from RMAN, it will first get all the datafiles information from the controlfile. Then it will divide all the datafiles among the allocated channels. ( roughly equal size of work as per the datafile size ). Then it takes the backup in 2 steps. In the first step the channel will read all the Blocks of the entire datafile to find out all the formatted blocks to backup. Note : RMAN do not take backup of the un formatted blocks. In the second step it take backup of the formatted blocks. This is the best advantage of using RMAN as it only take backup of the required blocks. Lets say in a datafile of 100 MB size, there may be only 10 MB of use full data and rest 90 MB is free then RMAN will only take backup of those 10 MB

Tuesday, April 25, 2017

R12.2 Log file Locations

A change in Release 12.2 is that HTTP, Oracle WebLogic Server, and concurrent processing log files are not stored under $LOG_HOME as they were in previous releases:
  • HTTP log files are located under the native instance home.
  • Oracle WebLogic Server log files are located under the domain home.
  • Concurrent processing log files are located on the non-editioned file system (fs_ne)


Name
Location
OHS
$IAS_ORACLE_HOME/instances/EBS_web_${TWO_TASK}_OHS2/diagnostics/logs/OHS/EBS_web_${TWO_TASK}/EBS_web_${TWO_TASK}.log
Weblogic Managed Server logfile
$EBS_DOMAIN_HOME/servers/<managed_servername>/logs
Concurrent processing log files
$NE_BASE/inst/${CONTEXT_NAME}/logs/appl/conc/log
adop(patching logfile)
$NE_BASE/EBSapps/log/adop
Adadmin logs
$NE_BASE/EBSapps/log/adadmin/log
Autoconfig log
$INST_TOP/admin/log

Thursday, March 30, 2017

Which device is mapped Oracle ASM disk?

[root@rac2 ~]# oracleasm listdisks
CRSVOL1
DATAVOL1
FRAVOL1

[root@rac2 ~]# oracleasm querydisk -d  DATAVOL1
Disk "DATAVOL1" is a valid ASM disk on device [8,33]

[root@rac2 ~]# ls -ld /dev/*|grep "8,  33"
brw-rw----  1 root disk      8,  33 Mar 29 19:09 /dev/sdc1

Monday, March 20, 2017

R12.2 Upgrade Miscellaneous Stuffs

Autopatch Preinstall Mode:

Pre-install mode is generally used during the upgrade process to update AD utilities, apply pre-upgrade patches, or work around other patching issues. AutoPatch asks all startup questions except those relating to the database.

Note: Run AutoPatch in pre-install mode only if the patch readme instructs you to do so.
To run AutoPatch in pre-install mode, include preinstall=y on the AutoPatch command line. It performs the following actions:

  • Compares version numbers
  • Copies files
  • Relinks FND and AD executables
  • Saves patch information to the file system
Because AutoPatch does not read driver files in pre-install mode, it copies all product files in the patch to the APPL_TOP directory. Additionally, even if a file in the patch should be both in the APPL_TOP and in another directory (such as in $OA_HTML), AutoPatch copies the file only to the APPL_TOP.

Each patch run in pre-install mode will have its driver staged to a predetermined directory under the APPL_TOP. This allows AD Merge Patch to be run once for all pre-install updates, and merging with the upgrade driver only. See AD Merge Patch Enhancements for further details.

In preinstall mode, AutoPatch validates codelevels against the files Preinstall_Codelevel_AD.txt and Preinstall_Codelevel_MP.txt. These files are located in the $APPL_TOP/admin directory, and contain codelevel information about AD and other products registered in the database tables.

Since no database connection is available in pre-install mode, AutoPatch tries to validate whether the current patch should be applied based on the codelevel information in these two files, as follows:

  • If Preinstall_Codelevel_AD.txt is missing from the APPL_TOP, AutoPatch will apply the patch in pre-install mode without validating the patch for codelevel compatibility.
  • If Preinstall_Codelevel_MP.txt is missing from the APPL_TOP, AutoPatch will proceed with patch application without validating the patch for codelevel compatibility of the entities.
  • If both files are missing, AutoPatch will not validate codelevels in pre-install mode.


AD Merge Patch Enhancements:

-preinstall

This option is used to run AD Merge Patch in pre-install mode, where it will only merge the patch driver files present in the $APPL_TOP/admin/$TWO_TASK/preinstall directory. The -preinstall option implicitly enables the -driveronly option, and takes the source directory as $APPL_TOP/admin/$TWO_TASK/preinstall directory.

The -s option can be used in conjunction with the -preinstall option to specify the source directory and merge critical driver files. As pre-install upgrade driver files are copied to the pre-install directory when AutoPatch is used in pre-install mode, the combination of these options merges pre-install upgrade driver files with the master upgrade driver file.

The -preinstall option means that there are associated changes in how AutoPatch is used. These are described in Pre-Install Mode.

--master
This option is used to specify the master upgrade driver that is to be merged with the pre-install upgrade drivers. It is only valid with the -preinstall or -driveronly options.

-admode
AD Merge Patch is now restricted to merge either AD-only patches or non-AD patches. By default, AD Merge Patch will run in non-AD mode unless the –admode option is specified. In non-AD mode, AD Merge Patch will merge the non-AD patches present in either the source directory specified by the -s option, or the pre-install directory if -preinstall is specified.

Note: When merging patches, AD patches present in the source directory are ignored in non-AD mode.

Examples

Merging the non-AD patch driver files that are present under the patchtop:
admrgpch -s source -d dest -driveronly

Merging the non-AD patch driver files with the non-AD upgrade driver file found under upg:
admrgpch -s source -d dest -driveronly –master upg/upgrade.drv

Merging non-AD patch driver files present in the "preinstall" directory with non-AD upgrade driver files, in pre-install mode:
admrgpch -preinstall -d dest -master upg/upgrade.drv

Merging AD patch driver files with AD upgrade driver files in pre-install mode:
admrgpch -preinstall -d dest -master upgrade/upgrade.drv –admode 

How to Compile Forms , Reports & Custom.pll in R12.2

How to Compile Custom.pll   cd $AU_TOP/resource  cp CUSTOM.plx CUSTOM.plx_bkup  cp CUSTOM.pll CUSTOM.pll_bkup  frmcmp_batch module=CUSTOM.pl...