1) Backup all your databases and valid the backup .

2) Add the new path (new disks from the new storage) to your asm_disktring to be recognized by ASM:

Example:

SQL> alter system set asm_disktring = ‘/dev/dellpowerc*’ , ‘/dev/dellpowerh*’;

Where: ‘/dev/dellpowerc*’ are the current disks.
Where: ‘/dev/dellpowerh*’ are the new disks.

3) Confirm that the new disks are being detected by ASM:

SQL> select path from v$asm_disk;

4) Add the new disks to your desired diskgroup:

SQL> alter diskgroup <diskgroup name> add disk
‘<new disk 1>’,
‘<new disk 2>’,
‘<new disk 3>’,
‘<new disk 4>’,
.
.
.
‘<new disk N>’;

5) Then wait until the rebalance operation completes:

SQL> select * from v$asm_operation;

6) Finally, remove the old disks:

SQL> alter diskgroup <diskgroup name> drop disk
<disk name A>,
<disk name B>,
<disk name D>,
<disk name E>,
.
.
.
<disk name X>;

7) Then wait until the rebalance operation completes:

SQL> select * from v$asm_operation;

Done, your ASM diskgroups and database have been migrated to the new storage.

Note: Alternatively, we can execute add disk & drop disk statements in one operation, in that way only one rebalance operation will be started as follow:

SQL> alter diskgroup <diskgroup name>
add disk ‘<new device physical name 1>’, .., ‘<new device physical name N>’
drop disk <old disk logical name 1>, <old disk logical name 2>, ..,<old disk logical name N>
rebalance <#>;

This is more efficient than separated commands (add disk & drop disk statements).

Wow …..

It  will be a great challenge for Oracle to swipe  IBM in Hardware Business.

And We can expect a Large improvements in Solaris and Sparc as Larry said.

Oracle Clusterware is the cross platform cluster software required to run the Real Application Clusters (RAC) option for Oracle Database.

It provides the basic clustering services at the operating system level that enable Oracle software to run in clustering mode. In earlier versions of  Oracle (version 9i and earlier), RAC required a vendor supplied clusterware like Sun Cluster or Veritas Cluster Server and with a seperate software for  Linux and Windows.

Oracle clusterware naming Evolution:

In 9i     - Third Party softwares  (Sun Cluster or Veritas Cluster Server)
In 10gR1-Cluster  Ready services (Oracle corporation)
In 10gR2- Oracle Clusterware     (Oracle corporation)

Oracle Clusterware stores configuration information in the Oracle Cluster Repository (OCR),
which must be located on shared storage available to all nodes. The Membership of the cluster is determined using a  file known as the voting disk, which must also be available to all nodes. Voting Disk  acts a tiebreaker during communication failures and  Consistent heartbeat information from all the nodes is sent to voting disk when the cluster is running .

Oracle Clusterware comprises a set of daemons(Background process).

1.Cluster Ready Services Daemon(crsd)

This component manages high availability operations within the cluster. Objects managed by CRS are known as resources and can include databases, instances, services, listeners, virtual IP addresses, and application processes. By default, CRS manages four application process resources: Oracle Net listeners, virtual IP addresses, the Global Services Daemon (GSD), and the Oracle Notification Service (ONS).

Configuration information about each resource is stored in the Oracle Cluster Repository
(OCR). When the status of a resource changes, CRS generates an event.

CRS monitors resources, such as instances and listeners. In the event of the failure of a resource, CRS will attempt to automatically restart the component.

2.Oracle Cluster Synchronization Service Daemon (OCSSD)

This component manages the cluster configuration by controlling which nodes are members of the cluster. When a node joins or leaves the cluster, CSS notifies the other nodes of the change in configuration.
If this process fails, then the cluster will be restarted.

3.Event Volume Manager Daemon (evmd)

The EVM component publishes events created by Oracle Clusterware. It will restart Automatically on failures and death of the evmd process does not halt the instance

4.Process Monitor Daemon (oprocd)

Oprocd provides the I/O Fencing solution for the Oracle Clusterware. It is the process monitor for the oracle clusterware and it uses the hang check timer or watchdog timer (depending on the implementation) for the cluster integrity.

Hi,

Platform: windows server 2003
Database : 10.2.0.4

Recently we have faced an problem with Gathering statistics which leads to
an oracle internal error (Ora-00600).

There is a  production database which has doing some  large transactions.

we usally gather the statistics for this database bettweeen the interval of two weeks .

we will gather the ststistics using the folowing method

exec dbms_stats.gather_schema_stats(ownname=>’user01′,estimate_percent=>dbms_stats.auto_sample_size,cascade=>true);

Last night we have gathered statistics for the a schema .
Suddenly  Only the next day morning Our users reported that some Oracle errors is
flashed  on one of our applications when accessing some particular form .

Then we tried to find the table on which that particular form is been accessing,
and we manually quried a simple statement on tht table:

SQL> select * from Tabular_data;
select * from Tabular_data
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [19004], [], [], [], [], [], [], []

After some search about the argument [19004] we finally understood that it is as a Bug .

This bug is due to the miscalculation of the Oracle’S Automatic Historgram collection on the table
columns .

since we dint mention any method_opt parameter on the above statement , it leads to its default value

method_opt=>’FOR ALL COLUMNS SIZE AUTO’ (Oracle 10g’s Default value)

So we decided to include the method_opt parameter with the size 1 which is the default value in
Oracle 9i.

method_opt=>’FOR ALL COLUMNS SIZE 1′ (Oracle 9i’s Default value)

This method will disable the collection of Histograms.

if we cant loose histograms , Ofcourse the Another way to escape from this error is to lock the

Statistics for that particular table and to proceed with the older approach .
SQL> exec dbms_stats.lock_table_stats(‘USER01′, ‘TABULAR_DATA’);

PL/SQL procedure successfully completed.

SQL> SELECT stattype_locked FROM dba_tab_statistics

WHERE table_name=’TABULAR_DATA’;

STATTYPE_LOCKED
——————–
ALL

So you cant able to gather statistics on the locked table.

Can we able to create an index with the same name as the table name ?

Yes . Because the table and index resides in the different namespaces.

A namespace defines a group of object types, within which all names must be uniquely identified—by schema and name. Objects in different namespaces can share the same name.

These object types all share the same namespace:
• Tables
• Views
• Sequences
• Private synonyms
• Stand-alone procedures
• Stand-alone stored functions
• Packages
• Materialized views
• User-defined types

So  it is impossible to create a view with the same name as a table; at least, it
is impossible if they are in the same schema.

These object types each have their own namespace:
• Indexes
• Constraints
• Clusters
• Database triggers
• Private database links
• Dimensions
Thus it is possible for an index to have the same name as a table, even within the
same schema.

SQL> select namespace from v$librarycache;

NAMESPACE
———————————————
SQL AREA
TABLE/PROCEDURE
BODY
TRIGGER
INDEX
CLUSTER
OBJECT
PIPE
JAVA SOURCE
JAVA RESOURCE
JAVA DATA

11 rows selected.

Here there is an small test:

SQL> create table t1 as select *  from user_objects;

Table created.

SQL> create index t1 on t1(object_id);

Index created.

SQL>  CREATE OR REPLACE package t1 as (ENO VARCHAR2);
2  /
CREATE OR REPLACE package t1 as (ENO VARCHAR2);
*
ERROR at line 1:
ORA-00955: name is already used by an existing object

Here we are getting the error because the packages and tables resides in the same namespace.

In a busy production environment with many active users, tracing a SQL session is time-consuming and complicated,
because processing SQL statements in any multitier system that uses a connection pool can span multiple processes,
or even different instances.

With Oracle Database 10g, Oracle rationalizes SQL tracing through a new built-in package, DBMS_MONITOR,
which encompasses the functionality of previously undocumented trace tools, such as the DBMS_SUPPORT package.
Now you can easily trace any user’s session from beginning to end—from client machine to middle tier to back end—and generate trace
files based on specific client ID, module, or action.

Now you can add your own reference to the trace file for your easy identification,

alter session set
tracefile_identifier =”webapp”;

Trace files generated by this command have the string value with “webapp”

The DBMS_MONITOR package has routines for enabling and disabling statistics aggregation as well as for tracing by session ID,
or tracing based upon a combination of service name, module name, and action name.

PL/SQL developers can embed calls into their applications by using the DBMS_APPLICATION_INFO package to set module and action names

The service name is determined by the connect string used to connect to a service. User sessions not associated with a specific service are handled by sys$users (sys$background is the default service for the background processes).
Since we have a service and a module name, we can turn on tracing for this module as follows:

SQL> exec dbms_monitor.serv_mod_act_trace_enable(service_name=>’test’, module_name=>’w3link’);

PL/SQL procedure successfully completed.

To Disable:

SQL>exec dbms_monitor.serv_mod_act_trace_disable(service_name=>’test’, module_name=>’w3link’);

PL/SQL procedure successfully completed.
Tracing For a particular session:
 
SQL> select sid, serial#, username
from v$session;

   SID     SERIAL#  USERNAME
     ——    ——-  ————
       103       4152  SYS
       107       2418  SYSMAN
       129         53  TEST
       130        561  HR
       141          4  DBSNMP
. . .
       168          1
       169          1
       170          1
15 rows selected.
SQL> exec dbms_monitor.session_trace_enable
(session_id=>129, serial_num=>53, waits=>true, binds=>TRUE);
PL/SQL procedure successfully completed.
SQL> exec dbms_monitor.session_trace_disable(129);
PL/SQL procedure successfully completed.

If the sql statement  is designed poorly, nothing much can be done by optimizer or indexes

Few are the well known rules

-Enabling indexes to eliminate the need for full table scans

-Avoid Cartesian joins

–Use UNION ALL instead of UNION – if possible

–Use EXIST clause instead of IN – (Wherever appropiate)

–Use order by when you really require it – Its very costly

–When joining 2 views that themselves select from other views, check that the 2 views that you are using do not join the same tables!

–Avoid NOT in or NOT = on indexed columns. They prevent the optimizer from using indexes. Use where amount > 0 instead of where amount != 0

- Avoid writing where is not null. nulls can prevent the optimizer from using an index

- Avoid calculations on indexed columns. Write WHERE amount > 26000/3 instead of WHERE approved_amt/3 > 26000

ASM is a powerful and portable storage manager designed to manage Oracle Database 10g and 11g database files. ASM simplifies storage management so that DBA’s worry less about Oracle Database file layout and management . ASM delivers lower total cost of ownership while increasing storage utilization, all without compromising performance or availability. With ASM, a fraction of the time is needed to manage your database files.

Some important ASM key features are:

· Volume Management
· Database File System with performance of RAW I/O
· Supports clustering (RAC) and single instance
· Automatic data distribution
· Online add/drop/resize disk with automated data relocation
· Automatic file management
· Flexible mirror protection

Basically, ASM is a storage manager designed to manage Oracle Database files with Volume Manager (1MB/128KB striping, Flexible mirroring and Online disk reconfigurations and automatic rebalancing), File System (Even data distribution with optimal performance) and Automatic file management using Oracle Managed Files (OMF).

Files supported by ASM

Only Oracle files are supported:

Data files
Control files
Online redo log files
Archived redo log files
Flash recovery area files
RMAN files (image copy and backup)

 Files not Supported:

ORACLE_BASE files( including alert log, trace files, etc)
CRS voting disk and OCR files
Output data from UTL_FILE
Any user or application specific files(e.g. XML or Java files)
Oracle 9i external table files

Yesterday, when I was reviewing AWR report of a busy OLTP database, I came across a dictionary related “Update” statement. This update statement was listed in top 10 SQL’s under “SQL ordered by Parse Calls” and “SQL ordered by Executions” sections of the AWR report and was parsed and executed 698 times during 30 minutes (A 30 minutes AWR report).

Here is the complete SQL Statement:

“update seq$ set increment$=:2, minvalue=:3, maxvalue=:4, cycle#=:5, order$=:6, cache=:7, highwater=:8, audit$=:9, flags=:10 where obj#=:1”

Immediately, I queried Oracle data dictionary for a list of sequences of one of our most important schema. Following is the query and its output:

sql>select sequence_name, cache_size, last_number from dba_sequences

where sequence_owner = ‘OM_TEST’;

SEQUENCE_NAME                  CACHE_SIZE       LAST_NUMBER

—————————— ———-                         ———–

SEQ_AUDIT_DETAILS             0                                     6728991
SEQ_MTR_LOG                             0                                    1
SEQ_TRANS_LOG                        20                                  991

Sequence “SEQ_AUDIT_DETAILS” seems to be a culprit here, it has been used for more than 6 Million times and is not cached.

Upon further investigation, it was revealed that this sequence is used by an audit detail table to generate unique serial.

I altered the sequence definition to cache 1000 values. Caching instructs Oracle to pre-allocate (in my case 1000) values in the memory for faster access.

SQL> alter sequence seq_audit_details cache 1000;

The above ALTER command did a magic and the UPDATE statement vanished from the AWR reports.

We need to cache sequences whenever possible to avoid extra physical I/O.

Oracle Version- 10.2.0.4

I Have taken an export of a particular user  which dump size is nearly to 14 gb.

While I am importing it  , i got an import error which says ,

illegal lob length marker 65279
bytesread = 00000000000
TABLE =cm_test
IMP-00098: INTERNAL ERROR: impgst2
IMP-00018: partial import of previous table completed: 2031183 rows imported
IMP-00008: unrecognized statement in the export file:
ÿþÿþÿþÿ
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:
IMP-00008: unrecognized statement in the export file:

All the  googles and forums mentioned that the export dump file is corrupted .

So  later i have taken an export once again with the large buffer size (buffer=300000000)

And then the export has been taken successfully ,

Later i try to import it by setting the same buffer parameter (buffer=300000000) and the import error message seems to be vanished .

This  same issue is been reported as a Bug by oracle support in 10.1.0.3, But this  bug has been fixed in 10.1.0.4 and Later.

Bug no: 3890213  IMP-98 possible importing zero length Lobs with CHUNKSIZE > 32767

Indexes are used to enhance expensive queries to run more quickly. They provide faster access path to table data. But, there is a trade-off using indexes, DML statements against the table would consume more time as all indexes on the table have to be updated during the DML.

Here is a small test I performed to see how index existence would affect the DML statements. For the test case, I create a small table without indexes, inserted 100,000 records and measure the time taken. I repeat the same test but this time with indexes on all columns. The difference in timing will show us, how much expensive are our indexes.

Test 1: Without Indexes

SQL> set serveroutput on
SQL> create table t(a number, b varchar2(30), c date);

Table created.

SQL> declare
2     x number;
3   begin
4     x := dbms_utility.get_time;
5     for i in 1..100000 loop
6       insert into t values(i, ‘value = ‘ || i, sysdate + mod(i,365));
7     end loop;
8   dbms_output.put_line(‘Time taken WITHOUT indexes : ‘ ||to_char(dbms_utility.get_time – x));
9  end;
10  /
Time taken WITHOUT indexes : 1200

PL/SQL procedure successfully completed.

Now, repeat the same test by creating indexes on all the three columns.

Test 2: With Indexes:

SQL> drop table t purge;

Table dropped.

SQL> create table t(a number, b varchar2(30), c date);

Table created.

SQL> create index t_idx1 on t(a);

Index created.

SQL> create index t_idx2 on t(b);

Index created.

SQL> create index t_idx3 on t(c);

Index created.

SQL>  declare
2   x number;
3   begin
4     x := dbms_utility.get_time;
5     for i in 1..100000 loop
6       insert into t values(i, ‘value = ‘ || i, sysdate + mod(i,365));
7     end loop;
8     dbms_output.put_line(‘Time taken WITH indexes : ‘ ||to_char(dbms_utility.get_time – x));
9   end;
10 /
Time taken WITH indexes : 4772

PL/SQL procedure successfully completed.

Well, it’s evident from the above tests that having too many indexes surely affects performance of DML statements. When I had three indexes, time taken to process 100,000 records was more than double compared to process the same number of records without indexes. Moral of the test is to create indexes when required and avoid over-creating them

There are two procedures in the DBMS_STATS package for gathering statistics on Oracle native objects:

GATHER_FIXED_OBJECT_STATS

GATHER_DICTIONARY_STATS
GATHER_FIXED_OBJECT_STATS collects statistics for fixed X$ and K$ objects. It needs to be run whenever any init.ora parameter is changed. Fixed objects are the magic tables that are not tables – they are not “dictionary” tables. The x$ tables would change size in response to init.ora setting changes generally. Setting processes higher will add rows to various x$ views for example.

So, they could be considered a one time thing unless you make a big change to your parameter
settings.

GATHER_DICTIONARY_STATS collects statistics for SYS schema. It needs to be run whenever you do “big things” to the dictionary (loaded a schema – not put data into the schema, but rather did things in the schema that affect the dictionary like creating and dropping objects…) – you would consider gathering statistics.

Look at last_analyzed for the sys tables to see when the dictionary was gathered against. Metalink Note 281793.1 states that the DBA_OPTSTAT_OPERATIONS view may be used to determine the start and end time of all DBMS_STATS operations executed at the schema and database level.

One of the uses of materialized views is replication. Mviews can be used to replicate a table to another database to prevent users from accessing several databases through database links. This can improve the performance of queries which frequently access that table by removing the latency of the database link.

Today the refresh job of one of the mviews we use for this purpose started getting “ORA-00001 unique constraint violated” error. This was an mview with a unique index on it. After a simple search in Metalink I have found the reason of this behavior.

I will provide a simple test case to reproduce the problem.

SQL> select * from v$version;

BANNER
—————————————————————-
Oracle9i Enterprise Edition Release 9.2.0.8.0 – 64bit Production
PL/SQL Release 9.2.0.8.0 – Production
CORE    9.2.0.8.0       Production
TNS for Solaris: Version 9.2.0.8.0 – Production
NLSRTL Version 9.2.0.8.0 – Production

SQL> create table master as select rownum r,’ROW’||rownum line from all_objects where rownum<=5;
Table created.

SQL> alter table master add primary key(r);

Table altered.

SQL> create unique index master_ind on master(line);

Index created.

SQL> create materialized view log on master with primary key;

Materialized view log created.

SQL> create materialized view snap refresh fast with primary key as select * from master;

Materialized view created.

SQL> create unique index snap_ind on snap(line);

Index created.

SQL> select * from master;

R LINE
———- ——————————————-
1 ROW1
2 ROW2
3 ROW3
4 ROW4
5 ROW5

After these steps we have now one master table, an mview log on it and a fast refreshable mview of the master table. Now we make some updates to the master table to switch the LINE column’s data of two rows.

SQL> update master set line=’DUMMY’ where r=1;

1 row updated.

SQL> update master set line=’ROW1′ where r=2;

1 row updated.

SQL> update master set line=’ROW2′ where r=1;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from master;

R LINE
———- ——————————————-
1 ROW2
2 ROW1
3 ROW3
4 ROW4
5 ROW5

Now when we try to refresh the mview we get the error.

SQL> exec dbms_mview.refresh(‘SNAP’);
BEGIN dbms_mview.refresh(‘SNAP’); END;

*
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (YAS.SNAP_IND) violated
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 820
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 877
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 858
ORA-06512: at line 1

If we drop the unique index and recreate it as nonunique we can refresh the mview without errors.

SQL> drop index snap_ind;

Index dropped.

SQL> create index snap_ind on snap(line);

Index created.

SQL> exec dbms_mview.refresh(‘SNAP’);

PL/SQL procedure successfully completed.

SQL> select * from snap;

R LINE
———- ——————————————-
1 ROW2
2 ROW1
3 ROW3
4 ROW4
5 ROW5

The reason of this error is explained in Metalink note 284101.1. According to that note the refresh mechanism may temporarily leave the data in an inconsistent state during the refresh. The modifications are not made with the same order as the modifications to the master table. Because of this creating unique indexes, foreign keys or primary keys on mviews can cause problems in the refresh process. This totally makes sense as it is better to keep the integrity checks on the master table rather than the mview. An mview is just a copy of the master table, so if we define the integrity constraints on the master table the mview will take care of itself.

This behaviour reproduces in 10G also.

The SQL engine maintains all indexes defined against a table regardless of their usage. Index maintenance can cause significant amounts of CPU and I/O usage, which can be detrimental to performance in a write-intensive system. With this in mind, it makes sense to identify and remove any indexes that are not being used as they are a pointless drain on resources. Index monitoring allows unused indexes to be identified accurately, removing the risks associated with dropping useful indexes.

It is important to make sure that index monitoring is performed over a representative time period. If you only monitor indexes during specific time frames you may incorrectly highlight indexes as being unused. The safest method is to use a monitoring period which spans the whole lifecycle of your application, including any OLTP and batch operations. In a Decision Support System (DSS) this may involve a period of weeks or months, while OLTP systems typically have shorter cycles.

ALTER INDEX

Index monitoring is started and stopped using the ALTER INDEX syntax shown below.

ALTER INDEX my_index_i MONITORING USAGE;
ALTER INDEX my_index_i NOMONITORING USAGE;

Information about the index usage can be displayed using the V$OBJECT_USAGE view.

SELECT index_name,
       table_name,
       monitoring,
       used,
       start_monitoring,
       end_monitoring
FROM   v$object_usage
WHERE  index_name = 'MY_INDEX_I'
ORDER BY index_name;

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

SET PAGESIZE 0
SET FEEDBACK OFF
SET VERIFY OFF
SPOOL temp.sql

SELECT 'ALTER INDEX "' || i.owner || '"."' || i.index_name || '" MONITORING USAGE;'
FROM   dba_indexes i
WHERE  owner      = UPPER('&1')
AND    table_name = DECODE(UPPER('&2'), 'ALL', table_name, UPPER('&2'));

SPOOL OFF

SET PAGESIZE 18
SET FEEDBACK ON

@temp.sql

-----------------------------------------------
SET PAGESIZE 0
SET FEEDBACK OFF
SET VERIFY OFF
SPOOL temp.sql

SELECT 'ALTER INDEX "' || i.owner || '"."' || i.index_name || '" NOMONITORING USAGE;'
FROM   dba_indexes i
WHERE  owner      = UPPER('&1')
AND    table_name = DECODE(UPPER('&2'), 'ALL', table_name, UPPER('&2'));

SPOOL OFF

SET PAGESIZE 18
SET FEEDBACK ON

@temp.sql

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

Foreign Key Indexes

To quote the Oracle Database Concepts manual:

“You should almost always index foreign keys. The only exception is when the matching unique or primary key is never updated or deleted.”

When a foreign key is unindexed, DML on the parent primary key results in a share row exclusive table lock (or share-subexclusive table lock, SSX) on the child table, preventing DML from other transactions against the child table. If the DML affects several rows in the parent table, the lock on the child table is obtained and released immediately for each row in turn. Despite the speed of the lock-release process, this can cause significant amounts of contention on the child table during periods of heavy update/delete activity on the parent table.

When a foreign key is indexed, DML on the parent primary key results in a row share table lock (or subshare table lock, SS) on the child table. This type of lock prevents other transactions from issuing whole table locks on the child table, but does not block DML on either the parent or the child table. Only the rows relating to the parent primary key are locked in the child table.

Resumable space allocation, introduced in Oracle 9i, is for all tablespaces at the session level. Database operations are suspended when an out-of-space condition is encountered. These suspended operations automatically resume when the error condition disappears. In Oracle Database 10g, this can be enabled at the instance level. Besides this improvement, automatic alert notification is sent when an operation is suspended.

In  Oracle 10gR1 the parameter RESUMABLE_TIMEOUT
can also be set on system level for all sessions.
SQL*Plus: Release 10.2.0.4.0 – Production on Tue Mar 31 11:58:08 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Enter user-name: / as sysdba

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create user test identified by test
  2  default tablespace example
  3  quota 1m on example;

User created.

SQL> grant create session ,create table to test;

Grant succeeded.

SQL> conn test
Enter password:
Connected.
SQL> create table t1 (eno number);

Table created.
SQL> BEGIN FOR i IN 1..10000 LOOP
  2   INSERT INTO t1 VALUES(i);
  3  END LOOP;
  4   COMMIT;
  5   END;
  6  /

PL/SQL procedure successfully completed.
SQL>  insert into t1 select * from t1;

10000 rows created.

SQL>  insert into t1 select * from t1;

20000 rows created.

SQL>  insert into t1 select * from t1;
 insert into t1 select * from t1
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace ‘EXAMPLE’

SQL> SELECT COUNT(*) FROM t1;

  COUNT(*)
———-
     40000

SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 600;
ERROR:
ORA-01031: insufficient privileges
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> grant resumable to test;

Grant succeeded.
SQL> conn test
Enter password:
Connected.
SQL>  insert into t1 select * from t1;
 insert into t1 select * from t1
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace ‘EXAMPLE’
SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 600;

Session altered.

SQL>  insert into t1 select * from t1;(this statement will wait )

————————from Another session (session 2) ——————-

SQL*Plus: Release 10.2.0.4.0 – Production on Tue Mar 31 12:19:46 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Enter user-name: / as sysdba
SQL> select sid,state,event from v$session_wait where sid=159;

       SID STATE         EVENT
———- ———– ——————————————-

       159 WAITING     statement suspended, wait error to be cleared

SQL> alter user test quota unlimited on example;

User altered.
————————Now check the SESSION 1—————————-
SQL>  insert into t1 select * from t1;

40000 rows created.

Hello DBA’S,

In our Production database(10.2.0.4) , currently we are using a backup  stratergy with
a full backup once a month and an incremental backup each week and the archived logs are backed up once a day.
All backups are directly taken in the  tape drives through a network , These tape drives are located in the different server…

In case of any recovery issues we need to transfer the backup sets from the tape to the disk through the network,so we found that there is some increase in the  recovery time .
And we decided to increase the frequency of the incremental backup in order to reduce its size .So we decided to use the Oracle 10g new feature of Block Change Tracking .

Block change tracking causes the changed database blocks to be flagged in a file.As data blocks change, the Change Tracking Writer (CTWR) background process tracks the changed blocks in a private area of memory. When a commit is issued against the data block, the block change tracking information is copied to a shared area in Large Pool called the CTWR buffer. During the checkpoint, the CTWR process writes the information from the CTWR RAM buffer to the change-tracking file.To achive this we need to enable the block change traking in our database:

SQL> conn sys as sysdba;
connected.

SQL> SELECT status FROM v$block_change_tracking;

STATUS
—————————————-
DISABLED

To enable this you need to create a new file for block change traking.

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
  2  using file ‘D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRD\change_track_file.dbf’ reuse;

Database altered.

SQL> SELECT status FROM v$block_change_tracking;

STATUS
—————————————-
ENABLED

If a block is changed in the database, the fact is recorded in this  file:D:\ORACLE\PRODUCT\10.2.0\ORADATA\PRD\change_track_file.dbf.
During incremental backup, RMAN checks this file to see which blocks need to be backed up instead of checking all the blocks of a data file.

It dramatically reduces CPU cycles and speeds up incremental backup in the process.
The block change tracking file, if present, is used automatically by the incremental backup; no special RMAN syntax is required. Using a block change tracking file saves enough time and CPU cycles  to take incremental backups every  night instead of taking once a week.

In case if you want to disable it ,you can use the below syntax.

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
 
Database altered.

Hi DBA’s,

I would like to share a nice presentation which has been given by Mr.Arup Nanda ,The President of Proligence and As a recognition of his outstanding accomplishments and contributions to the user community, Oracle awarded Arup the most coveted DBA of the Year Award at Oracle open World in September 2003.

  The following five essential best practices were derived from his years of experience working with Oracle systems large and small.

#1: Multiple Oracle Homes

My favorite best practice is the one about multiple Oracle Homes. Here it how it goes. When applying a patch or a patchset, I recommend against applying to the existing Oracle Home. Instead, I suggest creating a new Oracle Home, and apply the patches there. I create the first Oracle Home at /app/oracle/db_1, for instance. When a patch comes out, I install the whole Oracle software in a different home — /app/oracle/db_2 — and then apply the patch there. During the process of installation and patch application, the database is up and running, as it runs off the home /db_1. When the outage window comes, all I have to do is to shut down Oracle; change Oracle Home to db_2 and bring the database up. If there is a problem, I can reset the Oracle Home back to the old one.

So, here is the conventional approach:
1.Shut down the database
2.Apply patch to the Oracle Home
3.Start the database In case of problems
4.Shut down the database
5.Roll back the patch
6.Start the database

Steps 2 and 6 could take as much as three hours depending on the amount of patching. The database is down during these times.

 In the new approach:
1.Install new Oracle Home
2.Apply the patch to the new Home
3.Shut down the database
4.Change Oracle Home to the new location
5.Start the database
7.In case of problems
8.Shut down the database Change Oracle Home to the old one
9.Start the database

The database is down only during steps 4 and 8, which takes a couple of minutes at the most, not hours.

 So, here are the advantages:

1.The downtime is significantly reduced, to one 60th of the original time. 2.The risk is reduced significantly, as there is no rolling back a patch; you just go to the older version.
3.You can perform a “diff” on these two homes to see what changed. You can see the differences across multiple homes as well.
4.You can take several databases running on the same server to the new Oracle Home one by one.
5.You can see the various Oracle Homes and what patch level they are on using the inventory.

The only negative part is the space consumption — you need space for two Oracle Homes. But considering a typical Oracle Home takes about 4 GB or less, this aspect of the suggestion is trivial.

 #2: Set audit trail to DB

Set the audit trail to DB by placing the parameter AUDIT_TRAIL = DB in the initialization parameter file during the database creation. Setting this parameter does not start the auditing, because an explicit AUDIT command must be given on the object. But the parameter must be set to a value other than FALSE (the default) for the command to take effect. Being a non-dynamic parameter, the database must be bounced to change the value of AUDIT_TRAIL. To save the trouble and avoid an outage, always set the value to DB, even if you never intend to audit anything. It does not break anything and you will always be ready to audit when the time comes.

#3: Don’t use .log

Don’t use .log as the extension of redo logs. Someone may run a script to remove all the log files assuming they are redundant and you will end up losing the online redo logs as well, forcing a database recovery. Instead, name them with extension “redo” or “rdo.”

#4: Preview RMAN Restore

 Preview RMAN Restore to identify all the various backup pieces that will be used in the recovery process without doing an actual recovery. This eliminates any surprises from missing pieces during an actual recovery process.

#5: Create a new Oracle user for clients running on the same server as the DB

The Oracle Database server software also contains the client piece, which allows the clients to connect to the database on the same server. But as a best practice do not use the same user or the software; use a new one. For instance, if “oracle” is the user to install Oracle software, create a new user called, say, “oraapp” and install the client-only software using that user. The user “oraapp” should not be part of the dba or the oinstall group; so this user can’t log on to the database as sysdba. Create a new group called “appgrp” and assign the user oraaap to this group. All the application users on the box should also be part of the appgrp group. This way they can use the sqlplus, sqlldr and other executables on the server, but be able to connect as sysdba. The common practice is to use the client software in the same user as the database software owner; but starting with 10.2, Oracle has changed the security policy that takes away the global execution permissions from the Oracle Home. So the only option is to let app users be part of the dba group or change the permissions on Oracle Home — both make the database extremely vulnerable.

A materialized view  is a database object that contains the results of a query. They are local copies of data located remotely, or are used to create summary tables based on aggregations of a table’s data. Materialized views, which store data based on remote tables are also, know as snapshots (in previous versions of oracle), Materialized Views can increase many times the speed of queries that access huge data records

When you create a materialized view, Oracle Database creates one internal table and at least one index, and may create one view, all in the schema of the materialized view. Oracle Database uses these objects to maintain the materialized view data. You must have the privileges necessary to create these objects.

The following types of refresh methods are supported by Oracle.

Complete – build from scratch
Fast – only apply the data changes
Force – try a fast refresh, if that is not possible, do a complete refresh
Never – never refresh the materialized view

Materialized View Log:

When DML changes are made to master table data, Oracle Database stores rows describing those changes in the materialized view log and then uses the materialized view log to refresh materialized views based on the master table. This process is called incremental or fast refresh. Without a materialized view log, Oracle Database must re-execute the materialized view query to refresh the materialized view. This process is called a complete refresh. Usually, a fast refresh takes less time than a complete refresh.

A materialized view log is located in the master database in the same schema as the master table. A master table can have only one materialized view log defined on it. Oracle Database can use this materialized view log to perform fast refreshes for all fast-refreshable materialized views based on the master table.

To fast refresh a materialized join view, you must create a materialized view log for each of the tables referenced by the materialized view.

Privileges required:

create materialized view
create any materialized view
drop any materialized view
delete any table
insert any table
lock any table
select any table
under any table
update any table
create table
create view

There is one mandatory INIT.ORA parameter necessary for materialized views to function, this is the COMPATIBLE parameter. The value of COMPATIBLE should be set to 8.1.0, or above, in order for query rewrites to be functional. If this value is not set appropriately, query rewrite will not be invoked.

There are two other relevant parameters that may be set at either the system-level via the INIT.ORA file, or the session-level via the ALTER SESSION command.

       QUERY_REWRITE_ENABLED

Unless the value of this parameter is set to TRUE, query rewrites will not take place. The default value is FALSE.

       QUERY REWRITE INTEGRITY
This parameter controls how Oracle rewrites queries and may be set to one of three values:

ENFORCED – Queries will be rewritten using only constraints and rules that are enforced and guaranteed by Oracle. There are mechanisms, by which we can tell Oracle about other inferred relationships, and this would allow for more queries to be rewritten, but since Oracle does not enforce those relationships, it would not make use of these facts at this level.

TRUSTED – Queries will be rewritten using the constraints that are enforced by Oracle, as well as any relationships existing in the data that we have told Oracle about, but are not enforced by the database.

STALE TOLERATED – Queries will be rewritten to use materialized views even if Oracle knows the data contained in the materialized view is ‘ stale ‘ (out-of-sync with the details). This might be useful in an environment where the summary tables are refreshed on a recurring basis, not on commit, and a slightly out-of-sync answer is acceptable.

Syntax (Fast Refresh)

CREATE MATERIALIZED VIEW <schema.name>
PCTFREE <integer>
PCTUSED <integer>
TABLESPACE <tablespace_name>
BUILD IMMEDIATE
REFRESH <FAST | FORCE> ON <COMMIT | DEMAND>
<USING INDEX | USING NO INDEX>
INITRANS <integer>
STORAGE CLAUSE
AS (<SQL statement>);

Example: (Here we need to create a materialized view log first)

CREATE MATERIALIZED VIEW LOG ON employees;

CREATE MATERIALIZED VIEW mv_fast
TABLESPACE example
BUILD IMMEDIATE
REFRESH FAST ON COMMIT AS
SELECT * FROM employees;

Syntax (Force Refresh)

CREATE MATERIALIZED VIEW <schema.name>
PCTFREE <integer>
PCTUSED <integer>
TABLESPACE <tablespace_name>
BUILD IMMEDIATE
REFRESH <FAST | FORCE> ON <COMMIT | DEMAND>
AS (<SQL statement>);

 Example:

CREATE MATERIALIZED VIEW mv_force
TABLESPACE example
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
WITH ROWID AS
SELECT * FROM employees;

Syntax (Complete Refresh)

CREATE MATERIALIZED VIEW <schema.name>
PCTFREE <integer>
PCTUSED <integer>
TABLESPACE <tablespace_name>
REFRESH <COMPLETE | FORCE>
START WITH <date>
NEXT <date_calculation>
[FOR UPDATE]
AS (<SQL statement>);

 Example:

CREATE MATERIALIZED VIEW mv_complete
TABLESPACE example
REFRESH COMPLETE
START WITH SYSDATE
NEXT SYSDATE + 1
AS SELECT a.employee_id,a.last_name,a.salary,b.department_id
from employees a,departments b
where a.department_id=b.department_id;
Materialized views significantly improves the performance of Oracle systems required to process complex SQL statements.

—————A Performance Test on Materialized views——————————————–

SQL> create table sample as select rownum as id, owner,object_name , object_type from all_objects ;

Table created.
SQL> CREATE INDEX ind ON sample(ID);

Index created.
SQL> analyze table sample compute statistics;

Table analyzed.
SQL> set autotrace traceonly;

SQL> set timing on

SQL>  select owner,count(object_name) from sample group by owner;

24 rows selected.

Elapsed: 00:00:00.10

Execution Plan
———————————————————-
Plan hash value: 3791231185

Execution Plan
———————————————————-
Plan hash value: 3791231185

—————————————————————————–
| Id  | Operation          | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————–
|   0 | SELECT STATEMENT   |        |    24 |   120 |    87  (11)| 00:00:02 |
|   1 |  HASH GROUP BY     |        |    24 |   120 |    87  (11)| 00:00:02 |
|   2 |   TABLE ACCESS FULL| SAMPLE | 49717 |   242K|    80   (3)| 00:00:01 |
—————————————————————————–

Statistics
———————————————————-
          1      recursive calls
          0     db block gets
        337  consistent gets
          0     physical reads
          0     redo size
        955  bytes sent via SQL*Net to client
        392  bytes received via SQL*Net from client
          3      SQL*Net roundtrips to/from client
          0      sorts (memory)
          0      sorts (disk)
         24     rows processed

—————————–Login as a SYS user—————————————————–
SQL> conn / as sysdba
Connected.

SQL> grant query rewrite to hr;

Grant succeeded.

—————————–Login Back to HR user—————————————————

SQL> conn hr/hr;
Connected.

SQL> alter session set query_rewrite_enabled=true;

Session altered.
SQL>  alter session set query_rewrite_integrity=enforced;

Session altered.

SQL> create materialized view mv_sample
  2  build immediate
  3  refresh on commit
  4  enable query rewrite
  5  as
  6 select owner,count(object_name) from sample group by owner;

Materialized view created.

Elapsed: 00:00:00.65
SQL> analyze table mv_sample compute statistics;

Table analyzed.

Elapsed: 00:00:00.03
SQL> set autotrace traceonly
SQL>  select owner,count(object_name) from sample group by owner;

24 rows selected.

Elapsed: 00:00:00.18

Execution Plan
———————————————————-
Plan hash value: 1060132680

——————————————————————————————
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
——————————————————————————————
|   0 | SELECT STATEMENT             |           |    24 |   216 |     3   (0)| 00:00:01 |
|   1 |  MAT_VIEW REWRITE ACCESS FULL| MV_SAMPLE |    24 |   216 |     3   (0)| 00:00:01 |
——————————————————————————————
Statistics
———————————————————-
          0  recursive calls
          0  db block gets
          5  consistent gets
          0  physical reads
          0  redo size
        955  bytes sent via SQL*Net to client
        392  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         24  rows processed

The clustering factor is a number which represent the degree to which data is randomly distributed in a table. In simple terms it is the number of “block switches” while reading a table using an index

Figure: Bad clustering factor

The above diagram explains that how scatter the rows of the table are. The first index entry (from left of index) points to the first data block and second index entry points to second data block. So while making index range scan or full index scan, optimizer have to switch between blocks and have to revisit the same block more than once because rows are scatter. So the number of times optimizer will make these switches is actually termed as “Clustering factor”.

 Figure: Good clustering factorThe above image represents “Good CF”. In an event of index range scan, optimizer will not have to jump to next data block as most of the index entries points to same data block. This helps significantly in reducing the cost of your SELECT statements.

Clustering factor is stored in data dictionary and can be viewed from dba_indexes (or user_indexes)

SQL> create table sac as select * from all_objects;

Table created.

SQL> create index obj_id_indx on sac(object_id);

Index created.

SQL> select clustering_factor from user_indexes where index_name=’OBJ_ID_INDX’;

CLUSTERING_FACTOR
—————–
545

SQL> select count(*) from sac;

COUNT(*)
———-
38956

SQL> select blocks from user_segments where segment_name=’OBJ_ID_INDX’;

BLOCKS
———-
96

The above example shows that index has to jump 545 times to give you the full data had you performed full table scan using the index.

Note:
- A good CF is equal (or near) to the values of number of blocks of table.

- A bad CF is equal (or near) to the number of rows of table.

Myth:
- Rebuilding of index can improve the CF.

Then how to improve the CF?

- To improve the CF, it’s the table that must be rebuilt (and reordered).
- If table has multiple indexes, careful consideration needs to be given by which index to order table.

 References:

 Cost-Based Oracle Fundamentals:By: Jonathan Lewis

1)Make a whole database backup.

2)Login as a sys user..

sql>conn sys as sysdba

3)Check your database name

sql>SELECT nameFROM v$database;

NAME
———
ORCL

4)Make a proper shutdown of the database

here you can user immediate or transactional or normal

sql>SHUTDOWN IMMEDIATE

5) Invoke the newid utility

C:\mohd.dba>nid TARGET=system/manager@orcl DBNAME=newdb SETNAME=Y

DBNEWID: Release 10.2.0.1.0 – Production on Sat Jan 31 12:45:03 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to database ORCL (DBID=1203749959)

Connected to server version 10.2.0

Control Files in database:
G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL
G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL
G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL

Changing database name from ORCL to NEWDB
Control File G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL – modified
Control File G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL – modified
Control File G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL – modified
Datafile G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF – wrote new name
Datafile G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF – wrote new name
Datafile G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF – wrote new name
Datafile G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF – wrote new name
Datafile G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF – wrote new name
Datafile G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEMP01.DBF – wrote new name
Control File G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL – wrote new name
Control File G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL – wrote new name
Control File G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL – wrote new name
Instance shut down

Database name changed to NEWDB.
Modify parameter file and generate a new password file before restarting.
Succesfully changed database name.
DBNEWID – Completed succesfully.

6)Edit the pfile to change the db_name:

change the db_name parameter in the pfile to the new database name

db_name=newdb

7)Create a new password file using the ORAPWD utility

C:\mohd.dba>orapwd file=orapw001 password=confidential entries=10

8)Start the database using pfile:

sql>conn sys as sysdba

sql>startup pfile =G:\oracle\product\10.2.0\admin\orcl\pfile\init.ora.0122009171812

9)Recreate the spfile from the pfile

sql> create spfile from pfile=’G:\oracle\product\10.2.0\admin\orcl\pfile\init.ora.0122009171812′;

10) start the database using spfile:

SQL> startup force;
ORACLE instance started.

Total System Global Area 289406976 bytes
Fixed Size 1248600 bytes
Variable Size 92275368 bytes
Database Buffers 192937984 bytes
Redo Buffers 2945024 bytes
Database mounted.
Database opened.