Row migration & chaining

Hi,
we have a database which has above 600 tables(all are same schema).Everyday DML statements happen Nearly 400 tables.How to find the row migration & chaining by A SINGLE QUERY.
I would like to find everyday.Is it possible without analyze?
I know analyze command but we have to mention all the tables.

Lubiez Jean-Valentin wrote:
However, the columns CHAIN_CNT and NUM_ROWS are populated by ANALYZE statement or DBMS_STATS package.Are you sure that DBMS_STATS can be used to populate CHAIN_CNT? A default DBMS_STATS.GATHER_SCHEMA_STATS does not populate the CHAIN_CNT, for example. And I'm not aware of any way to populate that without using ANALYZE.
user3266490 - Why do you want to check this sort of thing on a daily basis? That seems exceptionally odd. Even checking it quarterly would seem like overkill. Are you actually having problems with excessive migrated rows (you can't fix chained rows, so those are basically irrelevant)? If you are, then whatever tables are having problems probably just need to be rebuilt with a more appropriate PCTFREE setting.
Justin

Similar Messages

Row chaining and row migration in Oracle 10g R2/11g R2

Hi,
Due to the business rule changes, one of the numeric column in a large table (20 millions rows) will be expanded from number(8) to number(10). Also, the values of this column of each row will be updated from 6 digits to 10 digits. All the indexes that use this column will be dropped and recreated after update. I would like to know if there is any row chaining or row migration issue in Oracle 10g R2 /11g R2.
Thanks for your help

neemin wrote:
Hi,
Due to the business rule changes, one of the numeric column in a large table (20 millions rows) will be expanded from number(8) to number(10). Also, the values of this column of each row will be updated from 6 digits to 10 digits. All the indexes that use this column will be dropped and recreated after update. I would like to know if there is any row chaining or row migration issue in Oracle 10g R2 /11g R2.
Thanks for your helpIt depends.
what you do observe after TESTING against the Development DB?

Row chaining and row migration ???

hi
Can someone tell me what are the oprions to over come row chaining and row migration in 10g and 11g databases ???
thanx in advance.
s

WIP wrote:
hi
Can someone tell me what are the oprions to over come row chaining and row migration in 10g and 11g databases ???
thanx in advance.
sHi.Chained row is a row that is too large to fit into a single database data block. row migration mean is update some rows would cause it to not fit on the block anymore,then these migrates to new address.For more information see below links
http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/
http://www.akadia.com/services/ora_chained_rows.html

About row-chaining, row- migration in a block

What happens during row-chaining, during inserting of a record in a block, about row-migration, update of row occurs exactly at which place in a block?

Hi,
Why Every WhereYou ask Doc Questions, better you read some oracle Doc.

ROW CHAINING 과 ROW MIGRATION

제품 : ORACLE SERVER
작성날짜 : 2002-04-10
ROW CHAINING 과 ROW MIGRATION
=============================
Purpose
Row chaining 과 Row Migration에 대해 이해하고 줄이는 방법을 확인한다.
Problem Description
Row chaining 은 단일 테이블 상의 특정 Row의 길이가 증가해서 더 이상
동일한 데이타 블럭에 들어갈수 없을때 발생한다. 이때 RDBMS는 또
다른 데이타 블럭을 찾는다. 이 데이타 블럭은 원래 블럭과 연결되어
있다. 이 경우 데이타 블럭이 하나의 I/O 작업과 동일한 양을 수행하기
위해 두 개의 I/O를 사용해야 한다는 점이다. 이 상황은 여러분의
데이터베이스 성능을 빠르게 약화시킬 것이다.
Data Block상의 하나의 Row는 길이가 증가하면서 갱신되며, Block의
Freespace가 0%일 때, Row는 Migration을 일으킨다. 물론, 전체 Row가
들어갈 만한 크기의 새로운 Block에 Row에 대한 Data가 Migration된다.
이경우 ORACLE은 Row에 대한 정보를 가져오기 위해 하나 이상의 Data
Block을 반드시 읽어야 하므로 I/O Perfmance는 감소한다.
Solution Description
1. Row chaining과 migration 확인
1) run ?/rdbms/admin/utlchain.sql
2) ANALYZE Command를 통해 Chaining과 Migrating의 횟수를 조사한다.
analyze table emp list chained rows;
2. 해결과정
1) 데이터 열을 CHAINED_ROWS 테이블의 ROWID를 사용하여 원래
테이블과 같은 행 구조를 가진 중간 테이블(intermediate table)로
이동시킨다.
2) 옮겨진 데이터 열을 CHAINED_ROWS 테이블의 ROWID를 사용하여 삭제 한다.
3) 중간 테이블로부터 열들을 다시 원래 테이블로 삽입한다.
4) 중간 테이블을 버린다.
5) CHAINED_ROWS 테이블의 레코드를 삭제한다.
이 과정이 수행되고 나면 analyze 명령은 다시 수행되야 한다. row가
다시 CHAINED_ROWS 테이블에 쌓이면 어떤 블럭에도 전체row 가 들어갈
충분한 공간이 없기 때문이다. 이것은 한 데이타 블럭의 한 row 가 너무
길어서 이거나 테이블의 PCTFREE 가 적절하지 못하기 때문이다. 전자의
경우는 chaine 현상이 일어날수 밖에 없고 후자의 경우 다음과 같이
PCTFREE 를 수정한다.
3. PCTFREE 값을 조정 하여야 하는 경우
1) 테이블에 대한 더 나은 퍼센트 프리 요소(percent free factor)를 결정한다.
2) 전체 테이블을 그 모든 의존관계(예를 들면, 인덱스, 그렌트(grants),
제약조건들 등)와 함께 export한다.
3) 원래 테이블을 버린다.
4) 새로운 사양으로 다시 만든다.
5) 테이블을 import한다.

Hi,
SQL> SELECT name, value FROM v$sysstat WHERE name = 'table fetch continued row';
NAME VALUE
table fetch continued row 163
Is this mean 163 tables contains chained rows?
Please suggest me.
Thanks
KSG

Row chaining and Row migrate

Hi,
how to do the difference between row chaining and row migrate.
In what table may i see the difference.

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:4423420997870

Migrated/chained rows causing double I/O

" You have 3,454,496 table fetch continued row actions during this period. Migrated/chained rows always cause double the I/O for a row fetch and "table fetch continued row" (chained row fetch) happens when we fetch BLOB/CLOB columns (if the avg_row_len > db_block_size), when we have tables with > 255 columns, and when PCTFREE is too small. You may need to reorganize the affected tables with the dbms_redefintion utility and re-set your PCTFREE parameters to prevent future row chaining.
What is migration and row chaining and when does this happen?
Is there a query to find out affected tables? i.e migrated and chained rows?
Is there a query to find out tables whos pctfree size is small?
How to determine the optimal value for pctfree for these affected tables/

user3390467 wrote:
" You have 3,454,496 table fetch continued row actions during this period. Migrated/chained rows always cause double the I/O for a row fetch and "table fetch continued row" (chained row fetch) happens when we fetch BLOB/CLOB columns (if the avg_row_len > db_block_size), when we have tables with > 255 columns, and when PCTFREE is too small. You may need to reorganize the affected tables with the dbms_redefintion utility and re-set your PCTFREE parameters to prevent future row chaining.
This is one of the better observations that you can get from the Statspack Analyzer. It would be helpful, though if it compared the number of continued fetches with the number of rows fetched by rowid and rows fetched by tablescan to produce some idea of the relative impact of the continued fetches.
It is possible that this advice is a waste of space, though --- and we can't tell because (a) we don't know how long the interval was, and (b) we don't know where your system spent its time.
If you care to post your statspack report, we might be able to give you some suggestions of the issues that are worth addressing. If you choose to do this (a) you may want to edit some of the text to make the report anonymous (database name, instance name, components of filenames, all but the first few words of each "SQL ordered by" statement).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."
Stephen Hawking

ROW MIGRATION 테스트

제품 : ORACLE SERVER
작성날짜 : 2003-08-04
여기서는 row migration을 테스트 할 수 있는 방법을 알아 본다.
개요>
- migration을 테스트 할 수 있는 테이블을 만든다.
- 이전 데이타보다 훨씬 큰 데이타로 update한다.
- 테이블을 analyze하여 migration이 일어난 row들을 알아낸다.
- 임시 테이블을 만들어 상기 row를 저장한다.
- 원래의 테이블에서 migration이 일어난 row들을 삭제한다.
- 임시 테이블의 내용을 원래의 테이블에 insert 한다.
SQL> create table chain (name varchar2(100));
SQL> insert into chain values('a');
SQL> insert into chain select * from chain;
SQL> /
SQL> /
SQL> update chain set name = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa';
256 rows updated
SQL> commit;
SQL> @?/rdbms/admin/utlchain /* chained_rows table 생성 */
SQL> analyze table chain list chained rows;
SQL> select count(*) from chained_rows; /* chained, migrated rows
확인 */
SQL> create table chained_temp as select * from chain
2 where rowid in (select head_rowid from chained_rows
3 where table_name = 'CHAIN');
SQL> delete from chain
2 where rowid in (select head_rowid from chained_rows
3 where table_name = 'CHAIN');
SQL> insert into chain select * from chain_temp;
SQL> commit;
SQL> delete from chained_rows;
SQL> commit;
SQL> analyze table chain list chained rows;
SQL> select * from chained_rows;
no row selected
Reference Documents
<Note:122020.1>

in this case the concept is row chaining: "Oracle Database stores the data for the row in a chain of one or more data blocks reserved for the segment. Row chaining most often occurs with large rows. Examples include rows that contain a column of data type LONG or LONG RAW, a VARCHAR2(4000) column in a 2 KB block, or a row with a huge number of columns. Row chaining in these cases is unavoidable." http://docs.oracle.com/cd/E11882_01/server.112/e25789/logical.htm#sthref1529

Reg: Row migration-

Hi Experts,
I got a doubt regarding the concept of 'Row Migration'.
From http://www.akadia.com/services/ora_chained_rows.html :
Migrate a row when an update to that row would cause it to not fit on the block anymore (with all of the other data that exists there currently)
But I'm getting confused is -- all the blocks will be of same size right (say 4 kb). Then migrating a row(say of 8 Kb) to another block (again of same 4 Kb), how 'll that help?
I can understand the concept of 'Row Chaining' where data is shared/divided into multiple blocks.
A nice article by Hans Forbich (but still not getting Row migration properly) -- https://forums.oracle.com/message/1806755#1806755
Am I getting the concept of 'Migration' wrongly? Please rectify me.
Help much appreciated.
Thanks,
Ranit

ranitB wrote:
Yes sure I'll do the tests, John. Thanks and much appreciated.
Could you please just clarify if my above inference is correct?
-- Ranit
Did you read your own doc reference?
Row Chaining
A row is too large to fit into a single database block
So now how does that relate to what YOU said above:
Row chaining -- occurs only when an Insert happens
Ask yourself: which of these operations (insert, update, delete) can make a row 'too large to fit into a single database block'?

How row migration get eliminated by export and import the table.

Hi ,
Please let me know,how row migration get eliminated by export and import the table.
Another method,deleting migrated rows and inserting those rows from copied table,
i think the concept behind this method is,inserting these rows into new block.
pls correct me if i am wrong.
Thanks,
Kumar.

Hi!
You can also use ALTER TABLE MOVE command, or if you are on 9i you can use DBMS_REDEFINITION package.
If you have a maintainance window the easiest way would be to use alter table move.
Regards,
PP

ITL Waits and row migration.

Oracle Version 11.2.0.3 PSU3
OS: SLES11 GA 64 bit
We had an issue with ITL waits on a specific table. In test this resulted in a deadlock so as a fix we rebuilt the table with initrans 8 and pctfree 75, this has improved the situation as we no longer have deadlocks but we have had an instance of high waits for ITL slots. Our development team assure us that a maximum of 6 transactions should be active on the table in question at any given time so we should not see any waits at all. As a bonus feature the table in question is initially loaded with just the primary key columns and the rest of the data (60 columns in all) is filled in over time which can cause considerable row migration to occur has anyone else encountered an issue of this type? Does row migration use additional ITL slots? I am attempting to replicate this in a development environment but so far can not get a replication of the problem.

rp0428 wrote:
Row migration can consume excess ITL entries - every row migrated in a single transaction will allocate an ITL slot in the target block, so if you manage to get (say) 5 rows in a block migrating in a single transaction and they all migrate to the same block you will find that you have used 5 ITL slots in that block - so you can't rule out the possibility that the migration is the cause of the ITL waits.
Can you expand on that a bit and reconcile it with what you say in the ITL entry in your Oracle Scratchpad Glossary article?
http://jonathanlewis.wordpress.com/2009/06/23/glossary/
The transaction needs to acquire only one ITL entry in the block no matter how many rows in the block it changes.
If an ITL (Interested Transaction List) entry represents 'interest' by a singlel transaction why would that single transaction need more than one entry in the block when migrating rows but not when updating existing rows?
What am I overlooking?
rp0428,
There are two possible replies to that question - the absolutely straightforward one is that I forgot to mention any special cases (the "Index Explosion" bug is another, very similar, case) when I wrote that note; the "wiggle" one is that each migration event behaves like a recursive transaction, which leaves you with one ITL entry per arriving row.
Regards
Jonathan Lewis

Row chaining & Migration

My production is running on 8i.
I have obserevd that some of the tables gain chain_cnt>2,00,000.
I brought the chain count to zero by creating a temporary table,
moving all the migrated rows to it.Then deleting the migrated rows from the original table,inserting back all the rows from temporary table back into Original table.
Then analyzing the table for compute statistics.
Can anybody guide me how can I prevent row migration/chaining in future ?
What are the parameters I have to consider while creating a table?
Thanks in advance,
chotu

Row Chaining and Migration are two different things with different cause. Based on your description you were having Row Chaining.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/logical.htm#i15914
Since you are on 8i you might be using manually managed tablespace. For that you mainly reduce row chaining by tweaking PCTFREE and PCTUSED

What to do if row chaining is found?

Hello Alls,
If i found rows chaining in my table then what i have to do?
also in my database there is one table which contain the 2,00,00,000 of records so it is advisable to make partition of this table for faster searching?
and how to check performance of oracle 10g database. since installed i am not checking any things in database?
how to check in database which patches are applied on the database?
can any body give me basic guidance from that i can check my database works fine or not. i want to check its response time and all performance related. currently i am getting very slow response from my database.

If i found rows chaining in my table then what i have to do?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.
Migration is caused by PCTFREE being set too low, there is not enough room in
the block for updates. To 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/chaining :
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
also in my database there is one table which contain the 2,00,00,000 of records so it is advisable to make partition of this table for faster searching?download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm
and how to check performance of oracle 10g database. since installed i am not checking any things in database?
can any body give me basic guidance from that i can check my database works fine or not. i want to check its response time and all performance related. currently i am getting very slow response from my databasedownload-uk.oracle.com/docs/cd/B19306_01/server.102/b14211/toc.htm
Jafar

How to identify migrated rows on a table

Hi, folks,
I'm wondering how to identify migrated rows on a table.
I understand that ANALYZE generates data into CHAINED_ROWS. The Oracle document implies that this table has both CHAINED ROWS and MIGRATED ROWS. FYI:
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/general.htm#sthref1881
But how can I tell migrated rows from chained rows.
Thanks!
Alex

im also not looking to ExporttoExcel feature on ADF just copy all the records displayed on a table
im also not looking to ExporttoExcel feature on ADF just copy all the records displayed on a table ,
Hi you can set the property( exportedRows) of exportListener
you can limit the number of rows to download
chekout documentaion
ADF RichClient API - af:exportCollectionActionListener

How can we reduce Row Chaining?

In a 10gR2 db, how can i reduce row chaining in tables?

Hi,
First, the prevention techniques for chained rows vs. migrated rows is a bit different. Note that both chained rows and migrated (relocated) rows manifest as "table fetch continued row" in v$sysstat and stats$sysstat for STATSPACK and dba_hist_sysstat for AWR.
Preventing chained rows - Chained rows can occur when a row is to large for a data block. In these cases, moving large objects into a tablespace with a larger blocksize can often relieve chained rows.
Preventing migrated rows - Migrated rows occur when a row expands (usually w2ith a varchar2 data type), and there is not enough reserve defined by PCTFREE for the row to expand. In this case, you adjust the PCTFREE to ensure that future rows will have room to expand and reorganize the table to remove the fragments.
On some tables which are stored tiny and grow huge, you may need to set PCTFREE to a "large" value, so that only one row is stored per block. For example, if I have a row with a varchar2 that is stored at 2k and grows to 30k, I would need to use a 32k blocksize and set PCTFREE=95 so that only one rows is stored on each data block. That way, at update time, there will be room for the row to expand without fragmenting.
Operationally, Oracle consultant Steve Adams offers this tip for finding the difference between chained and migrated rows:
http://www.freelists.org/archives/oracle-l/10-2008/msg00750.html
+"You can tell the difference between row migration and chaining by listing the chained rows with ANALYZE table LIST CHAINED ROWS and then fetching the first column from each "chained row" in a single query.+
+The count of continued row fetches will be incremented for every migrated row, but not for most chained rows (unless the first cut point happens to fall with the first column, which should be rare)."+
Hope this helps . . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference"
http://www.rampant-books.com/book_2005_1_awr_proactive_tuning.htm

Row migration & chaining

Similar Messages

Maybe you are looking for