Tuesday, August 12, 2008

Staging Area activity for R12 (12.0.4)

Contents:
Start Disk 1 Disk
RDBMS 1 Disk
Database 8 Disk
Tools 1 Disk
Appl_top 2 Disk

Operating System

Red Hat Enterprise Linux 5 (2.6.18-53.el5xen)

Memory Configuration

RAM 16 GB
HDD 146 GB

Stage Path

/media/R1204start/Disk1/rapidwiz/adautostg.pl

Steps to be followed while creating Staging Area

1) Login as root user
2) Verify the Perl version (perl –version)
3) Make sure that sufficient space is available in the particular mount point where you want to create staging area.
4) Copy all the contents in Start Disk to local HDD and start executing the perl script.
5) After executing the perl script it prompts you to give a directory where the media is to be staged (for example: To create stage area at /u01/StageR12 enter /u01) : /u01
6) The stage area will be created at /u01/StageR12
7) Do you use AutoMount to mount/umount the media y/n [y] : n
8) Enter the entire mount command [mount –t iso9660 /dev/cdrom /mnt/cdrom] : (just press enter)
9) Enter the umount command [umount /mnt/cdrom] : (just press enter)
10) Choose the components you want to stage (for example : 1,2,3,4,5)
Press 1 (complete Oracle Applications 10g, Database, 10.1.2, 10.1.3, APPL & COMN)
11) Insert the valid labeled DVD as and when it prompts you.
12) By doing so Staging Area will be created.
13) The top-level staged directory will look like StageR12, with sub-directories startCD, oraApps, oraDB, oraAS, and oraAppDB.

Tips:

1) After completion of Disk 1 in appl_top, it prompts you to insert the second Disk at that time just press enter (in your keyboard) the staging process will be continued. Later it asks for Dis2 then insert the Disk which is labeled as Appl_top Disk 2. Staging area will continue as it was doing.
2) Total Space used for Staging is 36 GB.
3) Total time taken is 1 and half hour.
4) After creating Staging Area, move all the contents into an external HDD so that it will be stored permanently to avoid data loss on local HDD.

Monday, August 4, 2008

Error: Ora-12560

ErroR: Ora-12560 TNS Protocol Adapter error...
Cause: This could happen when some one modifies the tnsnames.ora file ($TNS_ADMIN)
Action: 1) Check the connect descriptor
2) Check the host file name
3) See the service_name is correct specified is correct or not
4) See whether all the parameters are aligned in same way
Example of sample tnsnames.ora:
testdb =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = custprod)(PORT = 1521
(CONNECT_DATA = (SERVICE_NAME = testdb.world) ) )

Hot Backup for Windows

set ORACLE_SID=test
set ORACLE_HOME=D:\oracle\product\10.2.0\db_1
set PATH=D:\oracle\product\10.2.0\db_1\bin;%PATH%
(Local Drive)H:
cd test\hot-backup
mkdir _bkp_%date:~7,2%-%date:~4,2%-%date:~10,4%
(Local Drive)D:
cd ORACLE_HOME
sqlplus sys/password@test as sysdba @ D:(location of yoursqlscript)backupscripts\hot_test.sql echo "end of hot backup "
-----hot_test.sql
alter database begin backup;
host copy D:oracle\product\10.2.0\oradata\test\ H:test\hot-backup\_bkp_%date:~7,2%-%date:~4,2%-%date:~10,4%
alter database backup controlfile to trace;
alter database end backup;
exit

Full Database Backup:Export Utility

set ORACLE_SID= test
set ORACLE_HOME=D:\oracle\product\10.2.0\db_1
exp system/welcome@test file=\exp_full_test_%date:~7,2%-%date:~4,2%-% date:~10,4%.dmp log\exp_full_test_%date:~7,2%-%date:~4,2%-%date:~10,4%.log full=y

Top Ten List of Oracle Performance Mistakes

1) Bad connection Management:
The application connects and disconnects for each database interaction. This is common problem with stateless middlewarein application servers. This mistake has two orders of magnitude impact on performance, and it is totally unscalable.
2) Bad use of Cursors and Shared Pool:
Not using cursors results in repeated parses. If bind variables are not used, then hard parsing occurs of all SQL statements. This has an order of magnitude impact in performance, and it is totally unscalable. Use of cursors with bind variables that open the cursor and re-execute it many times.
3) Getting Database I/O wrong:
Many sites lay out their database poorly over the available disks. Other sites specify the number of disks incorrectly, because they configure disks by disk space and not I/O bandwidth.
4) Redo Log Setup Problems:
Many sites run with too few redo logs which are too small. Small redo logs cause system checkpoints to continuously put a high load on the buffer cache and I/O system. If there are too few redo logs, then the active cannot keep up, and the database stalls.
5) Serialization of data blocks in the buffer cache due to lack of free lists, free list groups, transaction slots (INITRANS), or shortage of rollback segments:
This is particularly common on INSERT heavy applications, in applications that have raised the block size to 8K to 16K, or in applications with large numbers of active users and few rollback segments.
6) Long Full Table Scans:
Long full table scans for high volume or interactive online operations could indicate poor transaction design, missing indexes, or poor SQL optimization. Long table scans, by nature, are I/O intensive and unscalable.
7) In disk Sorting:
In disk sorts for online operations could indicate poor transaction design, missing indexes, or poor SQL optimization. In disk sorts, by nature, are I/O intensive and unscalable.
8) High amounts of Recursive (SYS) SQL:
Large amounts of recursive SQL executed by SYS could indicate space management activities, such as extent allocations, taking place. This is unscalable and impacts user response time. Recursive SQL executed user another user ID is probably SQL and PL/SQL and this is not a problem.
9) Schema Errors and Optimizer Problems:
In many cases, an application uses too many resources because the schema owning the tables has not been successfully migrated from the development environment or from an older implementation. Examples of this are missing indexes or incorrect stats. These errors can lead to sub-optimal execution plans and poor interactive user performance.
10) Use of Nonstandard Initialization Parameters:
These might have been implemented based on poor advice or incorrect assumption. In particular, parameters associated with spin count on latches and undocumented optimizer features can cause a great deal of problems that can require considerable investigation.

Sample DB Script

connect sys/oracle as sysdba
startup nomount pfile=/dbs/inittest.ora
create database "test"datafile '/oradata/system01.dbf' size 200M
sysaux datafile '/oradata/sysaux.dbf' size 100M
logfile '/oradata/redo01.log' size 100M,'/oradata/redo01.log' size 100M
character set "WE8ISO8859P1"
national character set "UTF8"
extent management
localundo tablespace undotbs1 datafile '/oradata/undotbs1.dbf' size 100M
default temporary tablespace temp tempfile '/oradata/temp01.dbf' size 100M;
Running Data Dictionary Scripts:
1) catalog.sql (ORACLE_HOME/rdbms/admin)
--- Needed for all normal data dictionary views
2) catproc.sql (ORACLE_HOME/rdbms/admin)
--- Needed to load the initial PL/SQL environment
3) pupbld.sql (ORACLE_HOME/sqlplus/admin)
--- Script to install the SQL*Plus PRODUCT_USER_PROFILE tables