Re: Duplicates in systabnames?

Omar Muñoz wrote: > Hi. > Since dbsname was equal for both records I > reviewed sysptnhdr and everything is agree with your > explanation. Besides nextns has the same values I got > with oncheck -pt. > > Thanks a lot > Anytime. BTW, detached indexes are a bit more efficient in operation than semi-attached indexes. You may want to schedule a reorg of that index when you have time. Art S. Kagel Oninit > Omar Munoz > > --- "Art S. Kagel (Oninit)" <art@oninit.com> wrote: > > >> Omar Muñoz wrote: >> >>> Hi. >>> >>> I was using one of the IIUG scripts to >>> >> calculate >> >>> better sizes for extents (tabextplan) and I >>> >> realized >> >>> that one table gave me a different result in >>> comparison to oncheck -pt. Researching, i found >>> >> out >> >>> that there are two record in sysmaster:systabnames >>> with the same tabname and different partnum, and >>> >> the >> >>> table I'm talking about is not fragmented. Is >>> >> that >> >>> kind of duplicate something normal? should I be >>> >> worry >> >>> about corruption on database? >>> >>> >> No. Not corruption but more likely one record is >> for the table and the >> other for a semi-detached index. These were created >> by some IDS >> versions (7.30 and 9.21 IB) when an index was >> created without an IN >> clause. You can verify this by looking closer at >> the sysptnhdr records >> for the two partnums. One will show that npused is >> approximately equal >> to npdata while the other will show that npdata is >> zero. This latter is >> the index partition. If you are running a later >> release of IDS this >> just means that the index in question was created by >> an earlier version >> and has never been rebuilt under the newer release. >> >> Prior to these IDS versions indexes that were not >> explicitely detached >> (ie had no IN clause) were fully attached to the >> table they index, >> meaning that their pages were interleaved with data >> pages extent by >> extent. In even earlier versions of Informix index >> and data pages were >> interleaved within the same extents. Semi-detached >> indexes were an >> initial attempt to gain some of the performance >> improvements of fully >> detached indexes without requiring users to specify >> an IN clause. Later >> releases behave as if a default IN clause specifying >> the table's home >> dbspace had been supplied. >> >> Art S. Kagel >> Oninit =========================================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ===========================================================================================