Relevant Tables for ORACLE dataguard

View	Database	Description
DBA_LOGSTDBY_EVENTS	Logical only	Contains information about the activity of a logical standby database. It can be used to determine the cause of failures that occur when SQL Apply is applying redo to a logical standby database.
DBA_LOGSTDBY_HISTORY	Logical only	Displays the history of switchovers and failovers for logical standby databases in a Data Guard configuration. It does this by showing the complete sequence of redo log streams processed or created on the local system, across all role transitions. (After a role transition, a new log stream is started and the log stream sequence number is incremented by the new primary database.)
DBA_LOGSTDBY_LOG	Logical only	Shows the log files registered for logical standby databases.
DBA_LOGSTDBY_NOT_UNIQUE	Logical only	Identifies tables that have no primary and no non-null unique indexes.
DBA_LOGSTDBY_PARAMETERS	Logical only	Contains the list of parameters used by SQL Apply.
DBA_LOGSTDBY_SKIP	Logical only	Lists the tables that will be skipped by SQL Apply.
DBA_LOGSTDBY_SKIP_TRANSACTION	Logical only	Lists the skip settings chosen.
DBA_LOGSTDBY_UNSUPPORTED	Logical only	Identifies the schemas and tables (and columns in those tables) that contain unsupported data types. Use this view when you are preparing to create a logical standby database.
V$ARCHIVE_DEST	Primary, physical, and logical	Describes all of the destinations in the Data Guard configuration, including each destination's current value, mode, and status. Note: The information in this view does not persist across an instance shutdown.
V$ARCHIVE_DEST_STATUS	Primary, physical, and logical	Displays runtime and configuration information for the archived redo log destinations. Note: The information in this view does not persist across an instance shutdown.
V$ARCHIVE_GAP	Physical and logical	Displays information to help you identify a gap in the archived redo log files.
V$ARCHIVED_LOG	Primary, physical, and logical	Displays archive redo log information from the control file, including names of the archived redo log files.
V$DATABASE	Primary, physical, and logical	Provides database information from the control file. Includes information about fast-start failover (available only with the Data Guard broker).
V$DATABASE_INCARNATION	Primary, physical, and logical	Displays information about all database incarnations. Oracle Database creates a new incarnation whenever a database is opened with the RESETLOGSoption. Records about the current and the previous incarnation are also contained in the V$DATABASEview.
V$DATAFILE	Primary, physical, and logical	Provides datafile information from the control file.
V$DATAGUARD_CONFIG	Primary, physical, and logical	Lists the unique database names defined with the DB_UNIQUE_NAMEand LOG_ARCHIVE_CONFIGinitialization parameters.
V$DATAGUARD_STATS	Primary, physical, and logical	Displays how much redo data generated by the primary database is not yet available on the standby database, showing how much redo data could be lost if the primary database were to crash at the time you queried this view. You can query this view on any instance of a standby database in a Data Guard configuration. If you query this view on a primary database, then the column values are cleared.
V$DATAGUARD_STATUS	Primary, physical, and logical	Displays and records events that would typically be triggered by any message to the alert log or server process trace files.
V$LOG	Primary, physical, and logical	Contains log file information from the online redo log files.
V$LOGFILE	Primary, physical, and logical	Contains information about the online redo log files and standby redo log files.
V$LOG_HISTORY	Primary, physical, and logical	Contains log history information from the control file.
V$LOGSTDBY_PROCESS	Logical only	Provides dynamic information about what is happening with SQL Apply. This view is very helpful when you are diagnosing performance problems during SQL Apply on the logical standby database, and it can be helpful for other problems.
V$LOGSTDBY_PROGRESS	Logical only	Displays the progress of SQL Apply on the logical standby database.
V$LOGSTDBY_STATE	Logical only	Consolidates information from the V$LOGSTDBY_PROCESS and V$LOGSTDBY_STATS views about the running state of SQL Apply and the logical standby database.
V$LOGSTDBY_STATS	Logical only	Displays LogMiner statistics, current state, and status information for a logical standby database during SQL Apply. If SQL Apply is not running, the values for the statistics are cleared.
V$LOGSTDBY_TRANSACTION	Logical only	Displays information about all active transactions being processed by SQL Apply on the logical standby database.
V$MANAGED_STANDBY	Physical only	Displays current status information for Oracle database processes related to physical standby databases. Note: The information in this view does not persist across an instance shutdown.
V$STANDBY_LOG	Physical and logical	Contains log file information from the standby redo log files.

How do you know if you are using spfile or pfile

This shows database was started by spfile

SQL> show parameter spfile;

NAME    TYPE    VALUE
----    ----   ----------------------------------------------------------
spfile  string /root/apps/oracle/10g/dbs/spfile<DB_NAME>.ora

No values returned means its started by pfile

How to Check Oracle Fusion Middleware 11g and WebLogic Component Versions

For Weblogic

cat $FMW_HOME/wlserver_10.3/.product.properties | grep WLS_PRODUCT_VERSION

For Fusion Middleware 

 $ORACLE_HOME/OPatch/opatch lsinventory -detail

EBS + Remove Personalize Table Layout

I have this annoying problem where our page would look like this.

Normally the highlighted areas should not be there. If like me you want to turn it off then go ahead and follow this navigation.

System Administrator > Profile > System > 

Type "FND: Personalization Region Link Enabled"  and then update it to "No".

Logout and then Login. 

It should be back to normal.

How to Check if a Patch has been applied

To check if  patch 22246751 has been applied

select ad_patch.is_patch_applied('R12',-1,22246751) from dual;

Error txkADOPValidation during adop phase=fs_clone

I was going to apply a patch on our EBS R12 and the first step was to run ' adop phase=fs_clone' to sync the run files system with the patch file system.

I got this error

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

Inside getAbandonedNodes()...

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

SQL Command: SELECT AD_ZD_ADOP.GET_ABANDONED_NODES('ABANDONED')||',' FROM DUAL

tempAbandonedNodes:

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

Inside _eliminateAbandonNodes()...

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

 Node            Status

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

 miasma                  PATCH context file is missing

ERROR:

Nodes with context files in the FND_OAM_CONTEXT_FILES table on both run and patch file systems: NONE

Nodes without context files in the FND_OAM_CONTEXT_FILES table on either/or run and patch file systems: miasma

Corrective Action:

- If the run file system context file for a node is missing, run AutoConfig on the run file system of that node to sync with the value with the database.

- If the patch file system context file of a node is missing, run AutoConfig on the patch file system of that node with the -syncctx option as follows to sync with the value with the database.

On UNIX:

 sh <AD_TOP>/bin/adconfig.sh contextfile=<CONTEXT_FILE> -syncctx

On Windows:

 <AD_TOP>\bin\adconfig.cmd contextfile=<CONTEXT_FILE> -syncctx

Exiting validations as further tests will break.

From this log file we see that it reports that the context file for the patch file system is missing.

Although when I checked at the OS level it is there.

SOLUTION:

My environment

E-Business Suite Environment Information

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

  RUN File System           : /upgrade/R12_R12D1/fs2/EBSapps/appl

  PATCH File System         : /upgrade/R12_R12D1/fs1/EBSapps/appl

  Non-Editioned File System : /upgrade/R12_R12D1/fs_ne

1. source the patch file system by doing "/upgrade/R12_R12D1/EBSapps.env patch"

2. get your contextfile by echo $CONTEXT_FILE

3. The contextfile you need is for patch system. For example my $CONTEX_FILE is

$ echo $CONTEXT_FILE

/upgrade/R12_R12D1/fs2/inst/apps/R12D1_miasma/appl/admin/R12D1_miasma.xml

so I will replace fs2 with fs1 so the context file I will put in would be

/upgrade/R12_R12D1/fs1/inst/apps/R12D1_miasma/appl/admin/R12D1_miasma.xml

4. Then run $AD_TOP/bin/adconfig.sh contextfile=/upgrade/R12_R12D1/fs1/inst/apps/R12D1_miasma/appl/admin/R12D1_miasma.xml -syncctx

5. Retry the adop phase=fs_clone.

YOU DONE IT!!

==================================
Inside _eliminateAbandonNodes()...
==================================


 Node            Status
 ----------------------------------------------

 miasma                  RUN and PATCH context file entries are valid
Nodes with context files in the FND_OAM_CONTEXT_FILES table on both run and patc                                             h file systems: miasma
Nodes without context files in the FND_OAM_CONTEXT_FILES table on either/or run                                              and patch file systems: NONE

================================
Inside _validateJDKTop()...
================================

How To Source Run or Patch Filesystem on EBS 12.2.*

/upgrade/R12_R12D1/EBSapps.env run

/upgrade/R12_R12D1/EBSapps.env patch

txkSetConfig.pl

When autoconfig on EBS keeps on failing

******FATAL ERROR*******
PROGRAM : (/orastg/orastg3/oracle/fs2/EBSapps/appl/fnd/12.0.0/patch/115/bin/txkSetConfig.pl)
TIME    : Wed Oct 15 13:30:02 2014
FUNCTION:  [ Level 1 ]
ERRORMSG: *******FATAL ERROR*******
PROGRAM : (/orastg/orastg3/oracle/fs2/EBSapps/appl/fnd/12.0.0/patch/115/bin/txkSetConfig.pl)
TIME    : Wed Oct 15 13:30:02 2014
FUNCTION: TXK::Process::run [ Level 3 ]
MESSAGES:


Solution:
Register ORACLE_HOME's in the central inventory
$FMW_HOME/oracle_common/oui/bin/attachHome.sh
$FMW_HOME/webtier/oui/bin/attachHome.sh
$FMW_HOME/Oracle_EBS-app1/oui/bin/attachHome.sh
$FMW_HOME/Oracle_OAMWebGate1/oui/bin/attachHome.sh - might fail without OAM/SSO
$IAS_ORACLE_HOME/oui/bin/attachHome.sh
$ORACLE_HOME/oui/bin/attachHome.sh

How to change passwords in EBS R12

One of the main duties of an App DBA is cloning EBS from Prod to Dev. It is recommended that we change the passwords  of a user on a DEV environment so that they would not be able to access the PROD.

DO NOT Change passwords on the DB level. Instead use FNDCPASS.

In this example we would change the FNDCPASS of SYSADMIN on our newly cloned EBS.

Steps

1. Login to your Application Server as applmgr
2. FNDCPASS apps/<appspassword> 0 Y system/<dbsystempassword> user SYSADMIN <newpassword>clear
3. Try it now.