Sunday, January 11, 2015

Detailed and simple steps for Schema Migration using exp/imp,pipe,gz between two databases

Start of Migration
On the Source Database
==================
SQL> select name,open_mode from v$database;
NAME OPEN_MODE
--------- ----------
SOURCE READ WRITE
1. SQL> select owner,sum(bytes)/1024/1024 from dba_segments where owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5') group by owner;
2. SQL> select tablespace_name,sum(bytes)/1024/1024 from dba_segments where owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5') group by tablespace_name;
3. SQL> select default_tablespace,username from dba_users where username in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
4. SQL> select owner,status,object_type,count(*) from dba_objects where owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5') group by object_type,owner,status;

5. SQL> select object_type,count(*) from dba_objects where owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5') group by object_type;
6. SQL> select count(*),status from dba_objects where owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5') group by status;
7. SQL> select object_type,count(*),status from dba_objects where owner in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5') group by status,object_type;
8. SQL> select tablespace_name,sum(bytes)/1024/1024/1000 from dba_data_files where
tablespace_name in('TS1','TS2','TS3','TS4','TS5','TS6','TS7') group by tablespace_name;
9. Export Schemas:
vi exp_SOURCE_schemas.sh
#!/bin/ksh
export NLS_LANG=AMERICAN_AMERICA.UTF8
mknod /tmp/exp_pipe1 p
gzip -cNf SOURCE_schemas.dmp.gz &
exp system/sysmic32 file=/tmp/exp_pipe1 buffer=2097152 log=exp_SOURCE_schemas.log
statistics=none owner=SCHEMA1,SCHEMA2,SCHEMA3,SCHEMA4,SCHEMA5
rm -f /tmp/exp_pipe1
unset NLS_LANG
10. nohup ./exp_SOURCE_schemas.sh > exp_SOURCE_schemas.log 2>&1
11. Copy the SOURCE_schemas.dmp.gz to Target Database server.
scp -p SOURCE_schemas.dmp.gz ganesh@target_server:/oracle/export
On the Target Database
==================
SQL> select name,open_mode from v$database;
NAME OPEN_MODE
--------- ----------
TARGET READ WRITE
1. Create tablespaces as per the output from Step 7 you got on Source database
2. Create users on Target database
Run the following script on the source database and execute the resultant script on the
Target database

set linesize 300 set pagesize 300
spool create_users.sql
select 'create user '||username||' identified by values '''||password||''' default tablespace
'||default_tablespace||' temporary tablespace temp profile '||profile||';' from dba_users where
username in ('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
spool off

3. Grant Quotas on Target database
Run the following script on the source database and execute the resultant script on the
Target database

spool create_tablespace_quota.sql
select 'alter user '||username||' quota unlimited on '||tablespace_name||';' from dba_ts_quotas
where MAX_BYTES='-1' and username in ('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
select 'alter user '||username||' quota '||max_bytes||' on '||tablespace_name||';' from
dba_ts_quotas where MAX_BYTES!='-1' and username in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
spool off

4. Grant Roles on Target database
Run the following script on the source database and execute the resultant script on the
Target database
spool create_grant_roles.sql
select 'grant '||GRANTED_ROLE||' to '||GRANTEE||';' from dba_role_privs where ADMIN_OPTION='NO' and
grantee in ('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
select 'grant '||GRANTED_ROLE||' to '||GRANTEE||' with admin option;' from dba_role_privs where
ADMIN_OPTION='YES' and grantee in ('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
spool off

5. Grant System privs on Target database spool create_sys_privs.sql
Run the following script on the source database and execute the resultant script on the
Target database
select 'grant '||PRIVILEGE||' to '||GRANTEE||';' from dba_sys_privs where
ADMIN_OPTION='NO' and grantee in ('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
select 'grant '||PRIVILEGE||' to '||GRANTEE||' with admin option;' from dba_sys_privs
where ADMIN_OPTION='YES' and grantee in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
spool off
6. Import Schemas
vi imp_TARGET_schemas.sh
#!/bin/ksh
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
mknod /tmp/imp_pipe1 p
gunzip -c SOURCE_schemas.dmp.gz >/tmp/imp_pipe1 &
imp system/manager99 file=/tmp/imp_pipe1 buffer=20971520
log=imp_TARGET_schemas.log full=y
rm -f /tmp/imp_pipe1
unset NLS_LANG
7. Verify the logs
8. Do step 1 to step 7 that you have done on the source database.
9. Grant Table privs on the Target
Run the following script on the source database and execute the resultant script on the
Target database
spool create_tab_privs.sql
select 'grant '||privilege||' on '||owner||'.'||table_name||' to '||grantee||';' from
dba_tab_privs where GRANTABLE='NO' and grantee in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
select 'grant '||privilege||' on '||owner||'.'||table_name||' to '||grantee||' with grant
option;' from dba_tab_privs where GRANTABLE='YES' and grantee in
('SCHEMA1','SCHEMA2','SCHEMA3','SCHEMA4','SCHEMA5');
spool off
9. EXEC DBMS_UTILITY.COMPILE_SCHEMA ('SCHEMA1'); -> Do for all schemas that you have
imported
10. exec dbms_stats.gather_schema_stats('SCHEMA1', cascade=>TRUE); -> Do for all
schemas that you have imported
End of Migration

Where are the log files located in R12?


For DBA’s who mostly worked on 11i environments, finding the log files (Concurrent
manager log, apache log etc.,) on a R12 environment might pose a threat initially, because
these log files no longer reside in their old location ie., $APPLCSF/$APPLLOG or
$APACHE_TOP/Apache/logs.
In R12, the log files are located in $LOG_HOME (which translates to $INST_TOP/logs)
Concurrent Reqeust related logs
$LOG_HOME/appl/conc -> location for concurrent requests log and out files
$LOG_HOME/appl/admin -> location for mid tier startup scripts log files
Apache Logs (10.1.3 Oracle Home which is equivalent to iAS Oracle Home)
$LOG_HOME/ora/10.1.3/Apache -> Location for Apache Error and Access log files
$LOG_HOME/ora/10.1.3/j2ee -> location for j2ee related log files
$LOG_HOME/ora/10.1.3/opmn -> location for opmn related log files
Forms & Reports related logs (10.1.2 Oracle home which is equivalent to 806 Oracle Home)
$LOG_HOME/ora/10.1.2/forms
$LOG_HOME/ora/10.1.2/reports
Related metalink notes to enable additional debugging
419839.1 – How to enable Apache, OC4J and OPMN logging in Oracle Applications R12
422419.1 – R12 – How To Enable and Collect Debug for HTTP, OC4J and OPMN

Friday, December 19, 2014

ORACLE COMPLEX MAINTENANCE, REPAIR & OVERHAUL R12.1

SOLUTION HIGHLIGHTS


Oracle Complex Maintenance, Repair, and Overhaul R12.1 provides the most robust, reliable and effective means through which service poviders

and operators manage the entire maintenance lifecycle for complex assets. Specifically, Oracle cMRO R12.1 now supports:

  • Aircraft induction
  • Line maintenance
  • Heavy maintenance planning
  • Heavy maintenance execution
  • Engine and component overhaul
  • Marshalling

Today’s MROs use a variety of individual applications for each of their critical business processes; none of which are integrated nor provide any insight into combat readiness, asset availability, labor utilization/productivity, and maintenance profitability. As a result, multiple sources of the “truth” exist in various siloes, undermining the integrity of supply chain planning and execution, inventory levels, customer service and satisfaction, aircraft records and billing capabilities.

Wednesday, December 17, 2014

Oracle R12 Cloning One Node to Multi Node

Introduction

This document describes a step-by-step approach to clone an Oracle Applications R12 (which is autoconfig enabled) using Rapid Clone from one to two nodes, it includes Port Selection, Forms Server, Reports Server, Apache Server and Concurrent Processing, also all the scripts or programs, which are used to startup up and shutdown all the services. The cloning word means to do a functional copy of an existing environment. Simply copying the application directories doesn’t mean that our new environment will work properly, we need to do some additional steps or tasks to have a functional environment.

Some of the reasons to do a cloning are:
• To create a test environment from an existing production environment to test some patches or to reproduce any production issues.

Oracle Applications 11i Context/ Environment Files

Oracle Applications Context Files

During the Oracle Applications eBusiness Suite installation Rapid Install save the configuration parameters in 2 files (context files) named
<CONTEXT_NAME>.xml. The <CONTEXT_NAME> by default is <SID>_<hostname>. For instance if $ORACLE_SID is VIS and
$HOSTNAME is apps_svr.localdomain the context file will be VIS_apps_svr.xml. These context files are not used directly to configure the
Oracle Applications; the context files are only repositories which store the the configuration parameters.
The 2 context files are:
<RDBMS ORACLE_HOME>/appsutil/VIS_apps_svr.xml (for the database tier)
and
<APPL_TOP>/admin/VIS_apps_svr. xml (for each node of the the application tier)
The context files could be modified in 3 situations:
1. Apply a patch from Oracle that adds or changes the variables in VIS_apps_svr.xml, AutoConfig template files or AutoConfig driver files;
2. Using Context Editor (editcontext ) ( which is provided by the patch number 2873456);
3. Using Oracle Applications Manager (OAM) H or higher. OAM automatically stores the new values in the database and update the context files.
Oracle recommends using OAM; however if the OAM is not accessible the Context Editor must be used. The Context Editor is located at:

Application tier: <COMMON_TOP>/util/editcontext/

Database tier: <RDBMS ORACLE_HOME>/appsutil/editcontext/
The Context Editor executable file is editcontext (for UNIX) and EditContext.cmd (for Windows). The Context Editor contains 3 screens: 1st locate the context file and load it in the editor, the 2nd screen allows to edit the values in the context file and the 3rd screen allows you to save the changes to the context file.

Using Project Builder to implement a management strategy

In any development project, management tasks can be split roughly into two categories:
n Project management, which includes allocating the necessary equipment, budget, and person-hours of work necessary to complete the development of the application.
n Software configuration management, which includes assigning modules to developers, determining dependencies among modules, maintaining the code under development, and version control.
Project Builder, a component of both Forms Developer and Reports Developer, enables you to simplify your software configuration management tasks so you and your team can focus on your primary objectives: designing, coding, and testing applications.

About Project Builder

To help simplify your software management tasks, Project Builder provides the means for you to:
n Associate modules with an application or component of an application.
n Automate actions based on file types.
n Create dependencies between modules and indicate how changes cascade; in other words, show which modules need to be recompiled based on changes to other modules.
n Assign default connection strings to modules.
n Designate which modules are to be included in the final install set.
n Share projects and subprojects among team members and port them to different environments.
n Invoke other tools from the Project Builder user interface.
These features are described in detail in Section 1.1.3, "Exploring Project Builder benefits". If you’re unfamiliar with Project Builder terminology, however, it’s a good idea to read through Section 1.1.2.1, "Understanding Project Builder terminology" before proceeding. This section defines some basic terms which provide the context for a discussion of Project Builder’s features.

Oracle Forms Developer : The Software Development Lifecycle: An Overview

Application development typically occurs in four phases:
n Design. The initial specification for the application is developed. This specification can be based on a variety of sources: customer feedback, input of project management or development team members, requests for enhancement, necessary bug fixes, or systems analysis.
n Develop. Individual modules are created or modified, possibly incorporating a wide variety of languages, tools, or platforms.
n Test. The modules are tested. This generally occurs in two stages: unit test and system test. Unit test is testing at a modular or functional level; for example, testing UI
elements such as menus or buttons. System test tests the integration of major portions of the code; the backend with the UI, for example.
n Deploy. The modules are packaged together in an installable form and delivered to customers.


Figure 1–1 The phases of the development lifecycle: input and deliverables
As the application grows in size and complexity, the four phases are repeated iteratively, and the amount of information produced (actual code, bug reports, enhancement requests, etc.) grows. Yet all input and deliverables for all phases must be tracked and maintained to ensure the integrity of the final deliverable: the application your customer installs.

Monday, December 8, 2014

Install and Configure the Web Tier

Follow these steps to install the Oracle Web Tier on to Webhost1 and Webhost2
Install and Configure the First Oracle Web Tier on Webhost1
Install Oracle HTTP Server on Webhost1
Start the Oracle Universal Installer as follows:

On UNIX, issue this command: runInstaller
On Windows, double-click setup.exe