Error Message:
SMON: following errors trapped and ignored:
ORA-01595: error freeing extent (3) of rollback segment (1))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4193], [6179], [6757], [], [], [], [], []

Suggested Fix:
Recreate Undo Tablespace

1. Create the new undo tablespace.

create UNDO tablespace UNDO2 datafile ‘/UNDO201.dbf’ size 200M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 500M;

2. Assign New Undo Tablespace to Everyone

alter system set undo_tablespace = ‘UNDO2′ ;

3. drop old undo table space (might have to wait for all sessions holding space in old undo to leave)

drop tablespace including contents cascade constraints;

before Recreating please check whether any data files is in recovery mode and the data files using DBV (DB Verify)

delete from where rowid not in (
select min(rowid) from
group by );

delete from emp a where rowid >
any (select rowid from emp b where a.empid=b.empid);

delete from T t1 where t1.rowid >( select min(t2.rowID) from T t2
where t1.col1 = t2.col1 and t1.col2 = t2.col2);

Concepts: There are two circumstances when this can occur, the data for a row in a table may be too large to fit into a single data block. This can be caused by either row chaining or row migration.

Chaining: Occurs when the row is too large to fit into one data block when it is first inserted. In this case, Oracle stores the data for the row in a chain of data blocks (one or more) reserved for that segment. Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG, LONG RAW, LOB, etc. Row chaining in these cases is unavoidable.

Migration: Occurs when a row that originally fitted into one data block is updated so that the overall row length increases, and the block’s free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row: the rowid of a migrated row does not change.
When a row is chained or migrated, performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for that row.

o INSERT and UPDATE statements that cause migration and chaining perform poorly, because they perform additional processing.

o SELECTs that use an index to select migrated or chained rows must perform additional I/Os.

Detection: Migrated and chained rows in a table or cluster can be identified by using the ANALYZE command with the LIST CHAINED ROWS option. This command collects information about each migrated or chained row and places this information into a specified output table. To create the table that holds the chained rows,
execute script UTLCHAIN.SQL.
SQL> ANALYZE TABLE scott.emp LIST CHAINED ROWS;
SQL> SELECT * FROM chained_rows;
You can also detect migrated and chained rows by checking the ‘table fetch continued row’ statistic in the v$sysstat view.
SQL> SELECT name, value FROM v$sysstat WHERE name = ‘table fetch continued row’;
NAME VALUE
—————————————————————- ———
table fetch continued row 308

Although migration and chaining are two different things, internally they are represented by Oracle as one. When detecting migration and chaining of rows you should analyze carrefully what you are dealing with.

Resolving:
o In most cases chaining is unavoidable, especially when this involves tables with large columns such as LONGS, LOBs, etc. When you have a lot of chained rows in different tables and the average row length of these tables is not that large, then you might consider rebuilding the database with a larger blocksize.

e.g.: You have a database with a 2K block size. Different tables have multiple large varchar columns with an average row length of more than 2K. Then this means that you will have a lot of chained rows because you block size is too small. Rebuilding the database with a larger block size can give you a significant performance benefit.
o Migration is caused by PCTFREE being set too low, there is not enough room in avoid migration, all tables that are updated should have their PCTFREE set so that there is enough space within the block for updates.
You need to increase PCTFREE to avoid migrated rows. If you leave more free space available in the block for updates, then the row will have more room to grow.
SQL Script to eliminate row migration :
— Get the name of the table with migrated rows:
ACCEPT table_name PROMPT ‘Enter the name of the table with migrated rows: ‘

— Clean up from last execution
set echo off
DROP TABLE migrated_rows;
DROP TABLE chained_rows;
— Create the CHAINED_ROWS table
@…/rdbms/admin/utlchain.sql
set echo on
spool fix_mig
— List the chained and migrated rows
ANALYZE TABLE &table_name LIST CHAINED ROWS;

— Copy the chained/migrated rows to another table
create table migrated_rows as
SELECT orig.*
FROM &table_name orig, chained_rows cr
WHERE orig.rowid = cr.head_rowid
AND cr.table_name = upper(‘&table_name’);

— Delete the chained/migrated rows from the original table
DELETE FROM &table_name WHERE rowid IN (SELECT head_rowid FROM chained_rows);

— Copy the chained/migrated rows back into the original table
INSERT INTO &table_name SELECT * FROM migrated_rows;

spool off

Tips

1. Analyze the table and check the chained count for that particular table
8671 Chain Count

analyze table tbl_tmp_transaction_details compute statistics

select table_name,chain_cnt,pct_free,pct_used from dba_tables where table_name=’TBL_TMP_TRANSACTION_DETAILS’

2. Increase the pctfree size to 30

alter table tbl_tmp_transaction_details pctfree 30

3. Regenerate Report (When rows get updated only we will have Chained rows)

tbl_report_generation_status

begin dbms_job.run(190); end;

4. Analyze the table and check the chained count for that particular table
0 Chain Count

analyze table tbl_tmp_transaction_details compute statistics

select table_name,chain_cnt,pct_free,pct_used from dba_tables where table_name=’TBL_TMP_TRANSACTION_DETAILS’

Note:
If we want to do the procedure to delete the chained rows from original table and insert the same again, then we need chained_rows table
To create chained rows we need to run the utlchain.sql from $ORACLE_HOME/rdbms

Find out the chained rows.

analyze table tbl_tmp_transaction_details list chained count;

The above command will move the chained rows to chained_row table
Based on the rowid in chained_row table we can move those record to temp table and delete those chained rows from original table then insert the same again into original table.

select * from tbl_tmp_transaction_details where rowid=’AAAG8DAAGAAAGOKABD’:

Import terminated successfully without warnings – But no Object imported

Scenario: We have got the Dump from remote site and they have mentioned that dump was exported from SYSTEM user.

we tried the following two option but none of the expected object was imported to “bbb” schema

[oracle@UNIX backup]$ imp userid=system/xxxx fromuser=aaa touser=bbb file=backup.dmp log=export-1.log

[oracle@UNIX backup]$ imp userid=system/xxxx fromuser=system touser=bbb file=backup.dmp log=export-1.log

[oracle@UNIX backup]$ tail -1 imp.log
Import terminated successfully without warnings.
[oracle@UNIX backup]$

Import log says import completed successfully but it is not showing any object getting imported in log also.

We have tried with show=y option to see the content but still it is not showing.

Cause :
It is because we have expected objects in “CCCC” user at remote site. When engineer exported the dump
he used system user and did the full export of the database.

Solution
Since the remote site DBA used full export from system user and we need object from “CCCC” we have to do any of the following option

1. Do Full Import against the target database
or
2. Import command with the fromuser=”CCCC”

How do you find out the which user have the object you required without remote site enginner inform you. Only option is edit
the dump file in any editor if it is small. If not cat the file with more
$ cat backup.dmp |more
Look for the word CONNECT CCCC

virtual circuit status, enq: TX – row lock contention, latch: shared pool – Values are High

If you set the SGA_TARGET> 0 or MEMORY_TARGET parameter is set then check for the Bug 7039896 Spin under kghquiesce_regular_extent holding shared pool latch with AMM

Double check with Oracle Support before you apply any patch.

While creating temporary tablespace one can create it by using datafile or tempfile but there is a big difference in performance using temp file will give you better performance since it is autimatically managed by oracle, once temp segment is inactive and nolonger in use oracle mark it that space available to others so it can be used by others. But when you use datafiles for temp tablespace smon has to drop inactive segments manually to release the space this is big overhead smon invokes to remove inactive temp segments periodically it may take upto 12 hrs of time so it unneccessarily raises requirement for bigger temporary tablespace. So better to always use tempfiles for temporary tablespaces

SGA Keep is only possible for the below type of objects

- PACKAGE
- PACKAGE BODY
- FUNCTION
- TRIGGER
- TYPE
- Cursor

TABLE & LIBRARY
Not possible
- Procedure , PACKAGE ,PACKAGE BODY & FUNCTION
SQL> exec dbms_shared_pool.keep(‘xxxxxxxx’, ‘p’);
- TYPE
SQL> exec dbms_shared_pool.keep(‘xxxxxxxx’, ‘t’);
- TRIGGER
SQL> exec dbms_shared_pool.keep(‘xxxxxxxx’, ‘r’);
- CURSOR
1. Issue SQL statement to load it into the shared pool.
2. Determine the ADDRESS and HASH_VALUE of the SQL statement. This can
usually be obtained from calling DBMS_SHARED_POOL.SIZES. For example,
in the output from the SIZES procedure above you can determine that:
ADDRESS = 70378A10
HASH_VALUE = -614308548
for the SQL statement:
select ename from emp where empno = 7788
If the information cannot be determined from SIZES, then check the view
V$SQLAREA.
3. Issue the following statement to keep the cursor:
SQL> exec dbms_shared_pool.keep(’70378A10, -614308548′, ‘c’)
PL/SQL procedure successfully completed.

Move Tables Between Tablespaces / Move Table from one Tablespace to another Tablespace

There are many methods available to move the tables between tablespaces.

1. Export /Import
export the existing table
remove quota from the old tablespace
change the default tablespace to the new tablespace
drop the old table
import the table
change the default tablespace back again
restore quota on the old tablespace

2. ALTER TABLE
MOVE TABLESPACE < target_tablespace>

This is possible Only if U are on 8i Provided the table does not have LOBs
You cannot MOVE an entire partitioned table (either heap or index organized). You must move individual partitions or subpartitions.
You cannot move a table with a LONG or LONG RAW. You must exp that table and imp it into a table
Recreate underlying indexes using ‘alter index rebuild’
Check the Invalid objects using this table and compile it to become valid.
The indexes on the tables being moved will become unusable after the table, rebuild them right after moving a table — before moving the next table (to reduce downtime).

- You can find out using the following dictionray views
DBA_TABLES.temporary, DBA_SEGMENTS.segment_type,V$TEMPFILE, DBA_TEMP_FILES

- select * from dba_segments where segment_type = ‘TEMPORARY’;

- What is temporary segments or temporary tables

– other sessions can see table definition but not data
– data truncated when transaction/session (commit/rollback/exit) ends
– sessions get bound to temporary tables with the first insert into the table
– segments allocated to table at insert time not create time like normal tables

– creating
– session specific:
CREATE GLOBAL TEMPORARY TABLE ON COMMIT PRESERVE ROWS;
– transaction specific:
CREATE GLOBAL TEMPORARY TABLE ON COMMIT DELETE ROWS;

– example:
CREATE GLOBAL TEMPORARY TABLE emp_temp
(emp_name VARCHAR(60) NOT NULL,
emp_id NUMBER(4) NOT NULL,
CONSTRAINT emp_temp_pk PRIMARY KEY (emp_id)) ON COMMIT PRESERVE ROWS;

INSERT INTO emp_temp (emp_name, emp_id) values(‘Mudhalvan’,1);

COMMIT;

SELECT sid,
serial#,
username,
machine
FROM v$session
WHERE sid IN
(SELECT sid
FROM v$lock
WHERE id1 IN
(SELECT object_id
FROM dba_objects
WHERE object_name =
AND owner = ))