Wednesday, July 22, 2015

DB12c Concepts

    Multitenant Overview
  • Container Database (CDB) : On the surface this seems very similar to a conventional Oracle database, as it contains most of the working parts you will be already familiar with (controlfiles, datafiles, undo, tempfiles, redo logs etc.). It also houses the data dictionary for those objects that are owned by the root container and those that are visible to all PDBs.
  • Pluggable Database (PDB) : Since the CDB contains most of the working parts for the database, the PDB only needs to contain information specific to itself. It does not need to worry about controlfiles, redo logs and undo etc. Instead it is just made up of datafiles and tempfiles to handle it's own objects. This includes it's own data dictionary, containing information about only those objects that are specific to the PDB.








Views

The introduction of the multitenant option brings with it an extra layer of data dictionary views, allowing reporting across the root container and the pluggable databases (PDBs). Ignoring editions for the moment, prior releases had the following hierarchy.
DBA_ : All objects in the database.
|
--ALL_ : Objects accessible by the current user, including those owned by the current user.
  |
  --USER_ : Objects owned by the current user.
With Oracle 12c, an extra layer is added to the hierarchy.
CDB_ : All objects in all containers (root and all PDBs).
|
--DBA_ : All objects in the current container (root or PDB).
  |
  --ALL_ : Objects accessible by the current user in the current container (root or PDB), including those owned by the current user.
    |
    --USER_ : Objects owned by the current user in the current container (root or PDB).

Wednesday, July 8, 2015

Checking RAC status

1. Cluster status
 $crs_stat -t
$crsctl check crs


2. Check status of individual nodes and all the necessary applications

$srvctl status nodeapps -n host<n>
 
3.   check the status of the ASM on both nodes
 
$srvctl status asm -n host<n>
 
4. Check database status
 
$srvctl status database -d <dbname> 

5.Querying the RAC

SQL> select instance_name, host_name, archiver, thread#, status
  2  from gv$instance
  3  /
 
SQL> select file_name, bytes/1024/1024
  2  from dba_data_files
  3  /
 
SQL> select group#, type, member, is_recovery_dest_file
  2  from v$logfile
  3  order by group#
  4  /
 
SQL> select group_number, name,allocation_unit_size alloc_unit_size,state,type,total_mb,usable_file_mb
from v$asm_diskgroup; 

SQL> select name, path, header_status, total_mb free_mb, trunc(bytes_read/1024/1024) read_mb, trunc(bytes_written/1024/1024) write_mb
from v$asm_disk;
 
SQL> select name from v$datafile
  2  union
  3  select name from v$controlfile
  4  union
  5  select name from v$tempfile
  6  union
  7  select member from v$logfile
  8  /
 
SQL> select tablespace_name, file_name
  2  from dba_data_files
  3  union
  4  select tablespace_name, file_name
  5  from dba_temp_files
  6  /
 
SQL> select group_number, file_number, bytes/1024/1024/1024 GB, type, striped, modification_date
  2   from v$asm_file
  3  where TYPE != 'ARCHIVELOG'
  4  / 

SQL> select group_number, file_number, compound_index, incarnation, block_size, bytes/1024/1024/1024 GB, type, striped,
  2  creation_date, modification_date
  3  from v$asm_file
  4  where TYPE != 'ARCHIVELOG'
  5  /

Tuesday, July 7, 2015

How to Start 11g R2 RAC Cluster

There are 2 methods.
Method 1:
1).Start the HAS (High Availability Service) on each node.
$ crsctl start has
2).To Start the Cluster on both the nodes.
$ crsctl start cluster –all
If OHASD is already running, you can start the Clusterware stack on any node from local node
Method 2:
1).Run the below command on each node. Starts both HAS and CRS
$ crsctl start crs

Wednesday, May 20, 2015

adop concepts

  • What is Online Patching?
    Online patching is a new patching mechanism that allows the application of patches while the system is up and running, and the users are working as normal.
  • Which Oracle E-Business Suite releases can Online Patching be used with?
    Online patching is used with Oracle E-Business Suite 12.2 and higher.
  • What types of patch are applied online?
    All Oracle E-Business Suite Release 12.2 patches are applied online. This includes one-off patches, patch rollups, consolidated updates and security patches.
  • What is the Online Patching cycle?
    The Online Patching cycle is a sequence of inter-related steps (phases) used to apply patches to an Oracle E-Business Suite system.
  • What tool is used to apply online patches?
    The AD Online Patching (adop) command-line utility is used to manage the Online Patching cycle.
  • Is there any downtime in Online Patching?
    There is a short period of downtime when the application tier services are shut down and restarted. The database remains open all the time. For more details of these topics, see the Online Patching Concepts section below.
  • Do I upgrade to Release 12.2 with Online Patching?
    No. After you upgrade to Oracle E-Business Suite Release 12.2, you will enable Online Patching.
  • Once I upgrade to Release 12.2, can I still apply patches in the traditional way?
    No. All patches for Release 12.2 will be online patches. The traditional, pre-12.2 method of applying patches will not work.
  • Can I still use adpatch in the Release 12.2 Online Patching environment?
    No. While the Oracle tools may internally invoke the adpatch utility, direct user invocation of adpatch is not allowed.
  • Are there any plans to make Online Patching available with pre-12.2 releases?
    No. Online patching can only be used with Release 12.2.
  • What is the Online Patching infrastructure?
    The Online Patching infrastructure is the Oracle E-Business Suite Release 12.2 mechanism that allows Oracle E-Business Suite patches to be applied online, while the system is running and users are working as normal. This infrastructure includes database objects and file system components.
  • Does Online Patching require the 11gR2 Oracle Database Edition Based Redefinition (EBR) feature?
    Yes. Online patching depends on the Edition Based Redefinition (EBR) feature that was introduced in the Oracle 11gR2 Database. Most notably, EBR allows editioning of code objects in the database. To do this, it provides new object types such as editions, editioning views, and cross-edition triggers, all of which are part of the Online Patching infrastructure.
  • What are the phases that make up the Online Patching cycle?
    The Online Patching cycle consists of the following phases:
    1. Prepare a virtual copy (patch edition) of the running application (run edition).
    2. Apply patches to the patch edition of the application.
    3. Finalize the system in readiness for the cutover phase.
    4. Cutover to the patch edition and make it the new run edition.
    5. Cleanup obsolete definitions or data to recover space.
  • What downtime is required during an Online Patching cycle?
    The cutover phase requires a short period of downtime (typically a few minutes) for transition tasks such as a restart of the application tier services.
  • Is any downtime required for the database tier?
    No. In fact, the database needs to be up and running during each phase of the Online Patching cycle. However, non-Oracle E-Business Suite delivered database clients need to re-establish their database connection after the Online Patching cutover phase is performed. This includes connections from ODI Agent and Discoverer Server, as well as connection pools from Oracle SOA Suite and any other third party software connected to the Oracle E-Business Suite database.
  • How does Online Patching work on the application tier?
    During Release 12.2 installation, Rapid Install will lay down two copies of the application tier file system. One of the copies will be labeled as the run file system, and the other as the patch file system. Subsequently, when a patch is applied, adop will:
      1. Synchronize the contents of the run file system to the patch file system. This happens during the prepare phase.
      2. Perform patching actions on the patch file system. This happens during the apply phase.
      3. Finally, during the cutover phase, the adop utility restarts the application tier services. The patch file system is then promoted to be the new run file system, and the old run file system becomes the patch file system for the next patching cycle.
Note that a third file system, the non-editioned file system (fs_ne), is created to store files containing data that is needed across all file systems,such as log files.
  • How do I apply Oracle Fusion Middleware patches in Oracle E-Business Suite Release 12.2?
    During the apply phase of an Online Patching cycle, you apply Oracle Fusion Middleware patches to the Oracle homes of the patch edition file system. Then, after the cutover phase is complete, you synchronize the file systems by performing an fs_clone operation. (Also see My Oracle Support Knowledge Document 1355068.1, as listed in Appendix A.)
  • Is it possible to apply patches in advance of the downtime period required by cutover?
    Yes, you can apply online patches at any time in advance of a suitable cutover point, and then run in that state (with cutover pending) for as long as you need to.
  • Is Online Patching used in a test environment?
    Yes. It is required in all Oracle E-Business Suite environments.
  • Can I use the patch edition for testing purposes?
    As a specialized component of the Online Patching infrastructure, the patch edition is not supported for use as a test environment. You should continue to employ a separate, dedicated test environment.
  • Does the hotpatch option still exist in an Online Patching environment?
    Yes. However, the hotpatch option can only be used to apply patches specifically designed to support it. You should avoid using hotpatch mode unless the patch readme explicitly states it is supported, or an Oracle representative instructs you to use it.
  • Can Online Patching be used with database technologies such as Active Dataguard and Flashback?
    Yes. Online patching can be used alongside Active Dataguard and Flashback.
What are the key differences between the DBA_OBJECTS, DBA_OBJECTS_AE, and AD_OBJECTS tables?
  • DBA_OBJECTS shows object information for the current edition, but the STATUS column in this view may show the object as VALID even if the object actually needs to be compiled before use. This is a side effect of how the database handles objects in old editions that have been inherited into the current edition. The issue is tracked in database Bug 17777718.
  • DBA_OBJECTS_AE is similar to DBA_OBJECTS, but shows object information across all editions. This has the drawback of showing objects in old editions that are no longer accessible to the application.
  • AD_OBJECTS is the Oracle E-Business Suite workaround to the unreliable STATUS column in DBA_OBJECTS. AD_OBJECTS shows the correct status for each object visible in the current edition. It also shows whether the object is “actual” (a real object) in the current edition, or a "stub" object (the object definition was inherited from a previous edition). You can query AD_OBJECTS to locate objects that need to be recompiled before use: </span>
SQL>select owner, object_name, object_type
from ad_objects
where status = 'INVALID'
order by 1,2,3
/

The same logic can be applied by running the script: SQL>sqlplus apps/apps @$AD_TOP/sql/ADZDSHOWINVALID

adop Phases

Adop phases

1) prepare  - Starts a new patching cycle.
          Usage:  adop phase=prepare

2) Apply - Used to apply a patch to the patch file system (online mode)
         Usage:  adop phase= apply  patches = <>
      
    Optional parameters during apply phase
              
          --> input file : adop accepts parameters in a input file
              adop phase=apply input_file=
       
             Input file can contain the following parameter:
             workers=
              patches=:.drv, :.drv ...
             adop phase=apply input_file=input_file
             patches
             phase
             patchtop
             merge
             defaultsfile
             abandon
             restart
             workers

Note : Always specify the full path to the input file


        --> restart  --  used to resume a failed patch
           adop phase=apply patches=<> restart=yes

       --> abandon  -- starts the failed patch from scratch
           adop phase=apply patches=<>  abandon=yes

       --> apply_mode 
             adop phase=apply patches=<>  apply_mode=downtime

      Use apply_mode=downtime to apply the patch in downtime mode ( in this case,patch is applied on run file system)

  --> apply=(yes/no)
      To run the patch test mode, specify apply = no

  --> analytics 
  adop phase=apply analytics=yes

           Specifying this option will cause adop to run the following scripts and generate the associated output files (reports):

ADZDCMPED.sql - This script is used to display the differences between the run and patch editions, including new and changed objects.
The output file location is: /u01/R122_EBS/fs_ne/EBSapps/log/adop////adzdcmped.out.

ADZDSHOWED.sql - This script is used to display the editions in the system.
The output file location is: /u01/R122_EBS/fs_ne/EBSapps/log/adop///adzdshowed.out.

ADZDSHOWOBJS.sql - This script is used to display the summary of editioned objects per edition.
The output file location is: /u01/R122_EBS/fs_ne/EBSapps/log/adop///adzdshowobjs.out

ADZDSHOWSM.sql - This script is used to display the status report for the seed data manager.
The output file location is: /u01/R122_EBS/fs_ne/EBSapps/log/adop///adzdshowsm.out



3) Finalize :  Performs any final steps required to make the system ready for cutover..     invalid objects are compiled in this phase
 
   Usage: adop phase=finalize
   finalize_mode=(full|quick)  


4) Cutover  : A new run file system is prepared from the existing patch file system.
   adop phase=cutover

   Optional parameters during cutover phase:

         -->mtrestart - With this parameter, cutover will complete without restarting the application tier services
     adop phase=cutover mtrestart=no

 -->cm_wait -  Can be used  to specify how long to wait for existing concurrent processes to finish running before shutting down the Internal Concurrent Manager.
           By default, adop will wait indefinitely for in-progress concurrent requests to finish.

5) CLEANUP  
cleanup_mode=(full|standard|quick)  [default: standard]


6) FS_CLONE  : This phase syncs the patch file system with the run file system.
    Note : Prepare phase internally runs fs_clone if it is not run in the previous patching cycle

    Optional parameters during fs_clone phase:

i ) force - To start a failed fs_clone from scratch
adop phase=fs_clone force=yes  [default: no]

    ii ) Patch File System Backup Count ==> s_fs_backup_count  [default: 0 : No backup taken]
 Denotes the number of backups of the patch file system that are to be preserved by adop. The variable is used during the fs_clone phase,
 where the existing patch file system is backed up before it is recreated from the run file system.


7) Abort - used to abort the current patching cylce.
   abort can be run only before the cutover phase
    adop phase=abort 

Tuesday, May 12, 2015


Downloading Oracle Application Management Suite


Oracle Application Management Suite can be downloaded from Oracle Software Delivery Cloud by using following instructions:

  1. Go to the Oracle Software Delivery Cloud site.
  2. Choose a language and click Continue.
  3. Answer export validation questions.
  4. Select E-Business Suite from the list of product/media packs.
  5. Choose "Generic" and click Go.
  6. Select Oracle Application Management Suite 12c for Oracle E-Business Suite Media Pack 12.1.0.2.0 from the list and click on Continue.
  7. You will see the download page and click on the download button to download the software (Zip file).