shivenracdba

1.create these files :-  forward.zone,reverse.zone and named.rfc1912.zones into /var/named/chroot/var/named 2.content of forward.zone :- $TTL 86400 @          IN     SOA    rac.  rac. (                          42 ; serial (d. adams)                          3H ; refresh                         15M ; retry                          1W ; expiry                          1D ) ; minimum @          IN   NS     rac. rac       IN   A      192.168.72.128 localhost                   ...

To resolve the direct path reads wait event :- Please check the below views :- V$SESSION_EVENT ->  to identify sessions with high numbers of waits V$SESSTAT ->  to identify sessions with high "physical reads direct" (statistic only present in newer Oracle releases) V$FILESTAT ->  to see where the IO is occurring V$SQLAREA ->  for statements with SORTS and high DISK_READS (which may or may not be due to direct reads) Solution approcah :- If the file indicates a temporary tablespace check for unexpected disk sort operations. Ensure Parameter DISK_ASYNCH_IO -> is TRUE . Ensure the OS asynchronous IO is configured correctly. Check for IO heavy sessions / SQL and see if the amount of IO can be reduced.Better approach will be to look at the sql query that need to be tuned and need to run in parallel . Please check with ASH reports to see the all the queries which have this particular wait event . Ensure no disks are IO bound. And in t...

There will be  Significant Virtual Memory Paging on Linux When None is Occurring in ADDM Reports. There may be following message in the ADDM report: From  the ADDM report FINDING 1: 100% impact (48628 seconds) -------------------------------------- Significant virtual memory paging was detected on the host operating system. RECOMMENDATION 1: Host Configuration, 100% benefit (32719 seconds) ACTION: Host operating system was experiencing significant paging but no particular root cause could be detected. Investigate processes that do not belong to this instance running on the host that are consuming significant amount of virtual memory. Also consider adding more physical memory to the host. First, review the following bugs which incorrectly show large swapping statistics that may cause incorrect ADDM message as per above message.  And if applicable, apply the bugs. For 10.2.0.5,  for Linux: Note:12347332.8 Bug 12347332 - V$OSSTAT / ADDM incor...

This problem occurred due to resource allocation on the db side . Here is the solution approach :- 1.check the kernel parameter and see if it configured at optimum level. 2.Check the swap space and their usage and re-config them if it is needed . 3.It may be your JOB_QUEUE_PROCESSES is too low comparison to processes parameter , increase it upto     32 and decrease the  processes parameter upto 800 for now . 4.Check the session,transaction and process parameter and tune the session and process parameter. 5.monitor the PROCESSES usage at the database level using the V$RESOURCE_LIMIT view and increase it if is    needed .

[oracle@linux251 ~]$ export ORACLE_SID=dwh02 [oracle@linux251 ~]$ sqlplus sys/sys as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Fri Nov 29 11:27:07 2013 Copyright (c) 1982, 2011, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> alter tablespace TEST_TABLESPACE_2 read only; Tablespace altered. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@linux251 ~]$ expdp  transportable=always directory=bkp dumpfile=part_part.dmp tables=SCOTT.PART_PART:P0032,SCOTT.PART_PART:P0033,SCOTT.PART_PART:P0034,SCOTT.PART_PART:P0035,SCOTT.PART_PART:P0036,SCOTT.PART_PART:P0037,SCOTT.PART_PART:P0038,SCOTT.PART_PART:P0039,SCOTT.PART_PART:P0040,SCOTT.PART_PART:P0041,SCOTT.PART_PA...

If you found errors  in the log file as:- Errors in file /data1/test/diag/diag/rdbms/art02/art02/trace/art02_ora_29254.trc  (incident=8785): ORA-00600: internal error code, arguments: [2730], [331], [1], [4], [110], [110], [512], [512], [], [], [], [] Incident details in: /data1/test/diag/diag/rdbms/art02/art02/incident/incdir_8785/art02_ora_29254_i8785.trc RCA :- This happens due to Unmatched compatibility setup on the primary and the standby.The value of compatible parameter in primary and standby is different. Solution :- 1. Change the value of the compatible parameter on standby SQL> ALTER SYSTEM SET COMPATIBLE= <same as value of primary> SCOPE=SPFILE; If you are using pfile then edit pfile and change the value of the parameter *. COMPATIBLE= <same as value of primary> 2. Shutdown and Restart the standby database in mount stage 3. Restart Managed recovery process.

The error appears in the ALRET log file AS :-  Check that the primary and standby are using a password file and remote_login_passwordfile is set to SHARED or EXCLUSIVE, and that the SYS password is same in the password files. returning error ORA-16191 ORA-16191 -Primary log shipping client not logged on standby  Solution :-  1.Defer the remote archival destination (log_archive_dest_state_n) parameter in primary. In case of RAC defer LOG_ARCHIVE_DEST_STATE_n in all nodes. 2.check parameter REMOTE_PASSWORDFILE is set to either EXCLUSIVE or SHARED on the both database . 3.Delete the old password file and create the new one for both the DBs.In case of RAC shutdown all instance of standby before recreating the password file by below command :- orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=sys entries=5 force=y ignorecase=Y  4. set the parameter SEC_CASE_SENSITIVE_LOGON=FALSE on both DBs. 5.Enable the remote archival destination (log_archive_dest_st...