Path: newssvr20.news.prodigy.com!newsmst01a.news.prodigy.com!prodigy.com!newsfeed.telusplanet.net!newsfeed2.telusplanet.net!newsfeed.telus.net!news.glorb.com!postnews1.google.com!not-for-mail From: maks70@comcast.net (MAK) Newsgroups: comp.databases.oracle.server Subject: Re: Incorrect Migrated/Chained rows... Date: 27 Apr 2004 17:38:04 -0700 Organization: http://groups.google.com Lines: 34 Message-ID: References: NNTP-Posting-Host: 162.93.253.79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1083112684 32582 127.0.0.1 (28 Apr 2004 00:38:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 28 Apr 2004 00:38:04 +0000 (UTC) Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:260263 Thanks JL for your reply. > You don't quote an Oracle version - and oddities > like this can be highly version dependent. > Its 9.2.0.3. > Was there any difference between the table > parameters you used for the first copy and > the second copy ? Was the pctfree zero, > was it unrecoverable ? No! I was using unrecoverable both the times. I have tried without unrecoverable too but to no avail. > It is possible that the CTAS did something > that overestimated the number of rows that > could get into a block, and then had to correct > on the fly. (direct path load had a similar problem > a long time ago). The table in question has 305 columns ( > 255) , should it make any difference? > > One minor detail - in your SQL to check row > lengths nvl(vsize(col),1) would probably be a > better approximation, as most columns will have > an extra one byte for the length. (trailing nulls > being one exception, and columns longer than > about 250 bytes which use a 3-byte length). > Exellent suggestion! Thanks.