Fregmentation on LMTs!!!

Hi All,
If this query is OK..then why fregmentation happens on LMTs..as it is almost impossible on LMT..
mostly INDEX tablespaces have fregmentation so as to some data tablespaces..
why is it so?
SELECT dfsc.tablespace_name tablespace_name,
DECODE (
dfsc.percent_extents_coalesced,
100,
(DECODE (
GREATEST ((SELECT COUNT (1)
FROM dba_free_space dfs
WHERE dfs.tablespace_name = dfsc.tablespace_name),
1),
1,
'No Frag',
'Fragmented'
fragmentation_status
FROM dba_free_space_coalesced dfsc
ORDER BY dfsc.tablespace_name
TABLESPACE_NAME FRAGMENTATION_STATUS
DRSYS No Frag
FIN_DATA Fragmented
FIN_IDX Fragmented
INDX Fragmented
INV_DATA No Frag
INV_IDX Fragmented
OTHER_DATA Fragmented
OTHER_IDX No Frag
PAY_DATA Fragmented
PAY_IDX Fragmented
SALE_DATA Fragmented
SALE_IDX Fragmented
SYSTEM No Frag
TESTDATA Fragmented
UNDOTBS1 Fragmented
USERS Fragmented
XDB No Frag
Thanx in Advance!!!
ORA 9.2/WIN 2K SERVER

Hi,
In addition, take a look on this thread below:
Checking Tablespace Fragmentation...
Cheers

Similar Messages

Migrating SYSTEM tablespace from DMTS to LMTS in Oracle 9.2.0.7

Migrating SYSTEM tablespace from DMTS to LMTS in Oracle 9.2.0.7 using
brspace -f dbcreate
SAP version: 4.6C
Oracle: 9.2.0.7
OS: AIX 5.3
BRTools: 6.40(42)    /** 6.40(10) or (12) will be sufficient according to SAP ***/
IMPORTANT ***************************************
MUST DO:
1. Create a Full Backup of your system
2. Test your Restore and recovery of your backup.
3. Have a copy of all your tablespaces names on hand
4. Know your SYS and SYSTEM passwords
5. Run CheckDB in DB13 to ensure it is completed successfully with no warnings. This reduce the chance of hitting errors in the process
6. Ensure your UNDO tablespace is big enough
7. OSS 400241 Problems with ops$ or sapr3 connect to Oracle
NOTE: OSS 706625(Read this note)
The migration from a dictionary-managed SYSTEM tablespace to a locally-managed tablespace using the PL/SQL procedure DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL is not supported in the SAP environment.
In UNIX, logon as ora<sid>
run command: brspace -f dbcreate
This command will triggers a Menu. The are seven(7) steps to complete the whole process. Do them in sequence, from step 1 to step 7 faithfully. In Step 1, ensure that your settings of PSAPTEMP, PSAPUNDO etc details such as filenames are correct. The rest I leave it as default and they are fine. Do not change redo log group from 8 to 4 even if you only have 4 redo groups. If not, you might need to restore the system! If the seven steps are complete without errors(warnings is acceptable), congrats. Perform a backup again.
Problems I encountered that caused me to restore system:
1./ Problem: I changed the redo group from 8 to 4 and in the later stage after the tablespaces and files are dropped, the system prompted me that 4 is not acceptable! I can't go back then so a restore is performed.
Solution: Leave the default value 8 as it is
2./ I was using wireless network and the network breaks thus process breaks.
Solution: This process in user-interactive and requires you to input confirmation along the way so do it using LAN.
3./ In the process of dropping tablespace PSAP<SID>, I encountered:
BR0301E SQL error -604 at location BrTspDrop-2
ORA-00601: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 22 with name '_SYSSMU22$" too small
Solution: I have not fixed this yet but I think it is because my PSAPUNDO is too small(800M) so I will increase it to a bigger value e.g. 5GB
4. Problem: Unable to start sap after successfully migrated. OPS$user problem
Solution: logon as <sid>adm, run R3trans -x in a directory that <sid>adm has read/write permission. R3trans -x will creates a file call trans.log. Read the details and refer to OSS 400241
Result: I have successfully performed this on one(1) system and doing this on the another one currently but encounter Problem 3. Will update this further if there are more findings.
REFERENCE:
OSS 748434 New BRSPACE function "dbcreate" - recreate database
OSS 646681 Reorganizing tables with BRSPACE
OSS 541538 FAX: Reorganizations
Message was edited by:
        Annie Chan
Message was edited by:
        Annie Chan
Message was edited by:
        Annie Chan

The current one I am implementing is a development system. The database is less than 100GB. 800MB of PSAPUNDO is sufficient for our development usage.
Follow up on Problem 3:
I created another undo tablespace PSAPUNDO2(undodata.dbf) with size of 5GB. I switched undo tablespace to PSAPUNDO2 and placed PSAPUNDO(undo.data1) offline. With PSAPUNDO2 online and PSAPUNDO offline, I started brspace -f dbcreate and encountered the error below at Step 2 Export User tablespace:
BR0301E SQL error -376 at location BrStattabCreate-3
ORA-00376: file 17 cannot be read at this time
ORA-01110: data file 17: '/oracle/DVT/sapdata1/undo_1/undo.data1'
ORA-06512: at 'SYS.DBMS_STATS", line 5317
ORA-06512: at line 1
I aborted the process and verified that SAP is able to run with this settings. I started CheckDB in DB13 and it shows me these messages:
BR0301W SQL error -376 at location brc_dblog_open-5
ORA-00376: file 17 cannot be read at this time
ORA-01110: data file 17: '/oracle/DEV/sapdata1/undo_1/undo.data1'
BR0324W Insertion of database log header failed
I don't understand then. I have already switched the undo tablespace from PSAPUNDO to PSAPUNDO2. Why the message above still appears? Once I put PSAPUNDO online, CheckDB completes successfully without warning.
I did show parameter undo_tablespace and the result is PSAPUNDO2(5GB).
So exactly, what's going on? Can anyone advise?
===============================================
I have managed to clear the message in DB13 after dropping PSAPUNDO tablespace including contents and datafiles. This is mentioned is OSS note 600141 pg 8 as below:
Note: You cannot just set the old rollback-tablespace PSAPROLL to offline instead of deleting it properly. This results in ORA-00376 in connection with ORA-01110 error messages. PSAPROLL must remain ONLINE until it is deleted. (Oracle bug 3635653)
Message was edited by:
        Annie Chan

Same table in LMT consume 10% more space than in DMT

We have a table in DMT with pct_free=10, the size is 3,891,200 block, after I use impdp import it to another database with LMT manually management extents tablespace(table has the same pct_free), the size is 4,141,059. I hope the new table should be smaller than the old one, but the fact is opposite. There is nearly no update to the table, so it seems the difference is because using LMT.
Does LMT has a much higher overhead than DMT?

It has a much lower overhead, in fact, in terms of better coping with segments which frequently extend (no ST enqueue waits, for example).
But if you specify mad uniform sizes when creating LMTs, you will end up with mad results! There's not enough information in your post to know if that's happening here or not, but if you do:
create tablespace TB1 datafile 'tb1.dbf' size 10m extent management local uniform size 1M;
and then create a table which only stores 48KB of data in that tablespace, the table will nevertheless consume 1MB of space and look very inefficient, because that large uniform size is being applied.
How, specifically, did you create your LMT? If you said, 'uniform size 1GB', for example, then you're bound to end up with whole gig extents, and thus forced to consume 32GB when your table (say) only really wanted to occupy 31.01GB
If you let autoallocate determine the extent sizes, the same sort of effect is going to happen, but it might not be so noticeable.
I'm not convinced in any case that the difference between a table occupying 29.6GB and one occupying 31.6GB is worth worrying about: 2GB of disk space seems to me to be the least of your concerns. For the total elimination of tablespace fragmentation and ST enqueue waits, 2GB seems to me a small price to pay!

Working of LMT datafile and ASSM bitmaps + data-dictionary

Hi,
I was looking to have some clarification on effective changes that take place within the database during a datafile addition/resize in a LMT. Hence what are the scenarios where a datafile resize would be better than a datafile addition and vice-versa?
I have not been able to find clear guidelines to the above.

From the perspective of bitmap in datafile header is it not true that multiple datafiles with separate bitmaps in their headers can reduce the contention for multiple hot blocks in a single datafile?
To phrase my question differently, when does the additional calculations for LMT,ASSM and data-dictionary maintainance rule in favor of resizing a single datafile(ending in a sort of big file tablespace) rather than adding datafiles?

Will a converted LMT have UNIFORM EXTENT MANAGEMENT?

if we convert a DMT to an LMT, can we then set this LMT to have UNIFORM EXTENT MANAGEMENT?
thanks

Don't convert. Yes, Oracle provides a procedure to do the conversion, but it ends up creating a horrible 'hybrid' sort of tablespace, certainly unable to use a uniform extent management technique, but not really using a proper autoallocate method either.
Better to create a new tablespace and move segments across from one to the other. Then drop the original.

Manual segment space management and LMT

hi,
I am reading a book that says:
Using manual space management requires the DBA or the creator of the segment to specify values for the PCTFREE, PCTUSED, FREELISTS, and FREELIST GROUPS parameters when creating the object and maintaining them as the volume of segment data increases.
EXAM TIP PCTFREE, PCTUSED, FREELISTS, and FREELIST GROUPS can be set only for dictionary-managed tablespaces.
This confuses me. Surely a LMT can have objects that have MSM and not ASSM, if so, why can those not objects have PCTFREE, PCTUSED, FREELISTS, and FREELIST GROUPS set?
thanks

sybrand_b wrote:
Confusion can best be resolved by referring to the official documentation (as opposed to cluttering up this forum full of doc questions with further doc questions).
Is there any particular reason (your boss beats you up when he sees you reading documentation) why you can't be bothered to visit http://tahiti.oracle.com, or do you -mistakingly- think this is an online chatroom, instead of an offline forum?
Sybrand Bakker
Senior Oracle DBAwhat kind of an answer is that? I mean, what is the points of books if docs were everything one ever needed? I have read something in a book that confuses me, and I disagree with, but maybe my understanding is wrong, so that is why I am come here to ask others for their opinion. What is wrong with that?

AUTOALLOCATE or UNIFORM extents for LMTs?

Hi,
I checked metalink and other resources, but couldn't find a conclusive statement indicating as to which one of the following is the best and recommended option:
1) LMTs with AUTOALLOCATE or
2) LMTs with UNIFORM EXTENT sizes
Any pros and cons would be appreciated.
Thanks
SS

A classic example where AUTOALLOCATE is very good is the 3rd party application where you don't know which tables are going to be big, which ones small, and which one won't be used at all If you put everything into AUTOALLOCATE it avoids wasting space, but lets the big tables grow without producing a vast number of extents.
If you are in control of the application and have good information about sizing of a few critical objects, you might choose to use UNIFORM sizing for adminstrative and monitoring reasons - it gives you the option for watching objects grow at a predictable rate.
If you are doing a lot of parallel work with scratch tables (CTAS, insert /*+ append */ then you might want to read up about the possible conflict between PX and AUTOALLOCATE at the following URL:
http://jonathanlewis.wordpress.com/2007/05/29/autoallocate-and-px/
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

LMT and DMT tablespace

Hi all,
Can you please explain me what happens while inserting/deleting bulk data in tables, which in LMT and DMT tablespace? How the blocks are utilized and how the information about blocks are maintained?
Thanks in advance,
Giridharan

Well, that's an old question.
Dictionary Managed Tablespace, as the name suggests mangages the info about the used/free blocks of the datafile within the data dictionary. The two tables that are used are UET$ and FET$. This means whenever you do any space related operations over the tablespace, Oracle has to do couple of additional tasks like
1) It has to run recurvive calls over these tables to get the info about the available space. So if the space comes out to be okay with your space related operation, like creating table , Oracle will let you go ahead. Surely enough, this is slow.
2) Your updations or any space related opeations will lead to the changes(DML) over these data dictionaries as well. This will cause extra Redo/Undo to be generated. Though, the extent of it wil not be much but still, its going to be htere and if the activity is too much, it may add up to a large chunk.
3) With any space related operations, there will be some free space that will come up. But mostly, this space will be non contiegious. This will lead to fragmentation in the datafile.
Due to these problems, Oracle gave the idea of LMT. This leads to a total change of algorithm. LMT, as the name suggests, stands for Locally Managed Tablespace. This means that the space related info of the datafile is maintained with the datafile's header itself , in bitmap blocks. These blocks are capable enough to hold entire data file within very few blocks. So this will be very fast and because they are just bits, they won't generate any additional redo/undo as well. This leads to a much better and scalable management of the datafile space.
I hope this does clear some things.
HTH
Aman....

Recycle bin LMT Vs Dictionary Managed

Hi,
Am I right in thinking you only get a recycle bin for LMT's?
So any dictionary managed tablespaces will not have a recycle bin even if recyclebin is on for the database.
Thanks.

You're correct that DMTs cannot make use of the recyclebin functionality.
create tablespace hjr datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\hjr01.dbf' size 10m extent management dictionary;
create table t1 (col1 char(5)) tablespace hjr;
show recyclebin;
{nothing returned}
drop table t1;
show recyclebin;
{nothing returned}BUT...
create tablespace hjr2 datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\hjr201.dbf' size 10m extent management local;
create table t1 (col1 char(5)) tablespace hjr2;
show recyclebin;
{nothing returned}
drop table t1;
show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
T1 BIN$zq24aOXxRGitS2FnP8SUjQ==$0 TABLE 2008-01-07:22:09:02It comes down to the fact that the recyclebin isn't a separate place where tables are moved to, but simply a means of marking extents for over-writing without actually vacating them. In DMT, that would potentially mean updating lots of rows in the UET$ table, and that would be expensive. In LMT, you simply set lots of bits.
The recyclebin is simply not feasible in DMT, in other words.

Which parts of the wirless fregment are encrypted by WEP?

which parts of the wirless fregment are encrypted by WEP?
a. payload of data
b. trailer
c. header
d. IV
which two of options are right?

The only portion of the ethernet frame that is encrypted with WEP is the payload. When the frame leaves the ethernet port of the AP, it is no longer encrypted at all. The header of the ethernet frame contains the source and destination MAC addresses, as well as an ethertype/length field.

Bitmap of LMT

(Oracle 9.2)
hi guys,
The Oracle documentation says:
A tablespace that manages its own extents maintains a bitmap in each datafile to keep track of the free or used status of blocks in that datafile. Each bit in the bitmap corresponds to a block or a group of blocks. When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the blocks.
I am confused by this statement. How does Oracle determine whether to use a block or a group of block? Furthermore, if we are using UNIFORM extents, then surely the bitmap of the LMT should be the size of a UNIFORM extent, yes?
thanks

OracleGuy777 wrote:
In LMT, each extent that is allocated within the datafile has got a header maintaining the info about the blocks which are part of it. The management is totally maintained by Oracle itself that how many blocks one bitmap block will be maintaining. Its always more than one block that a bitmap block maintains as it will be too costly to maintain a single bitmap block for a data file block.
If you want to see more internally, you can spend time looking at these 2 tables, X$KTFBUE and X$KTFBFE . They will give the info about the bitmaps withi the LMT.But I won't recommend you to go for it.thanks aman, I will look at those tables, although I will probably get more confused.
From the article you specified below, the extents were all 64K, so it was clear that each entry of bitmap represented 64k worth of data blocks. Suppose the extents could all be different sizes. How then would each entry of a bitmap be used to represent the extents?
Each bit in bitmap represent one extent, Oracle use fix view x$ktfbue to trace the size of each extents, as you can find from the table
each extent has an ADDR and KTFBUEBLKS is how many blocks this extent has.
desc x$ktfbue
Name                                      Null?    Type
ADDR                                               RAW(8)
INDX                                               NUMBER
INST_ID                                            NUMBER
KTFBUESEGTSN                                       NUMBER
KTFBUESEGFNO                                       NUMBER
KTFBUESEGBNO                                       NUMBER
KTFBUEEXTNO                                        NUMBER
KTFBUEFNO                                          NUMBER
KTFBUEBNO                                          NUMBER
KTFBUEBLKS                                         NUMBER
KTFBUECTM                                          NUMBER
KTFBUESTT                                          VARCHAR2(20)
KTFBUESTA                                          NUMBER

Convert tablespace from DMT to LMT

Hi Folks,
We have a project comming up for converting all our tablespaces from Dictionary Managed to Locally Managed. We started our pre steps on this task. I'm checking on metalink if there are any know issues or any problems after the convertion.
Please share any issues if you have encountered after converting the tablespaces from DMT to LMT and any performance degradations.
We are on 10.2.0.2 on Solaries and some on 10.2.0.2 on HP-UX . Seems to be weird for you guys that we are still on DMT on 10.2.X
Appriciate your advices..
Thanks
Karthik

Take a look here below :
Re: extent management for system tablespace
Nicolas.

Error after Oracle Migration from DMTS into LMTS

Hello ,
I'm sorry, I posted my question again from ABAP General into this forum ABAP Dictionary. I think that here someone can help me in order to proceed with my job in the Development and in production system.
We are using SAP R/3 4.6C, with SAP kernel 2271, Oracle 9.2.0.5 and HP-UX 11.23
I did the Oracle migration from dictionary into locally managed tablespaces on the QTS system (and before that the same migration on a separate system as a copy from production):
1. export data and index tablespace with Oracle export command (exp: for PSAPCLUD and PSAPCLUI)
2. import into file for creation of indexes
3. Drop the data and corresponding index tablesspace with brtools - brspace
4. recreate the tablespaces with sapdba or with sqlplus (using the ddl scripts created before dropping the tablespaces) - - I think is my problem
5. import the data with Oracle import command
6. import the indexes from the previously created sql file
7. check optimizer statistics, analyze and next extents
But there is one problem.
Because I have also used the sapdba and ddl sql for recreating the tablespaces, I didn't specify the SAP data class for the newly created tablespace.
And in the tables TAORA, IAORA and DDART (what is very unclear for me) 3 rows missing for the USER1, TEMP and ??? data class.
If you try to import some transport in the corresponding tablespace which data class is missing an error ocur.
I have read the Note 646681 - Reorganizing tables with BRSPACE, and I saw the part: If the <reorg_tsp> tablespace contains any of the following tables: SDBAH,SDBAD,DBAML,DBATL,MLICHECK,TGORA,IGORA,TSORA,TAORA, IAORA,SVERS,DD02L,DD09L,DDNTT,DDART,DARTT or SAPLIKEY (SAPLIKEY is only available in NetWeaver 2004s or higher), then you should move them to the tablespace <aux_tsp> by online reorganization using BRSPACE:
brspace -f tbreorg -t <table_list> -n <aux_tsp>
Do you have the same problem?
Do you know how I can solve the problem now after the hole migration was done?
How can I dedicate tablespace data class?
Is it enought to just enter the same rows into the TAORA, IAORA and DDART?
Thanks,
Many regards,
Ruzica

Apparently you are trying to mix 32-bit code and 64-bit code. You must ensure that the 32-bit or 64-bit option is used consistently on every command, compiling and linking. The form of the option can depend on the version of the C compiler you are using, and whether you are on an x86 or sparc system. Consult the Pro*C and C compiler documentation.

How to migrade DMT to LMT in standby database?

Hi,
I plan to migrate my existing tablespace from Dictionary Manage to Local Managed.
I have my Production and a DR Server act as standby DB server.
If i perform the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL to the tablespace in Production. Will the activity recorded in the archive-log and able sycn with the DR Server automatically?
or i need to perform it manually in DR.
Thanks.

Yes it will propagate to your DR.

Fragmented free space in empty LMT ASSM tablespace?

select count(*) from dba_extents where file_id=127;COUNT(*)
0
select count(*) from dba_free_space where file_id=127;COUNT(*)
2
select block_id, blocks from dba_free_space where file_id=127;
BLOCK_ID     BLOCKS
       128     507904
    508032     139616
select extent_management, segment_space_management, allocation_type
from dba_tablespaces
where tablespace_name=(select tablespace_name from dba_data_files where file_id=127);EXTENT_MANAGEMENT     SEGMENT_SPACE_MANAGEMENT     ALLOCATION_TYPE
LOCAL     AUTO     SYSTEM
alter tablespace ... coalesce;
select count(*) from dba_free_space where file_id=127;COUNT(*)
2
select version from product_component_version where product like 'Oracle%';VERSION
11.2.0.2.0
How is that possible?

user5066799 wrote:
Thanks Jonathan, but, sorry - have not got - what do you mean? Do you mean that space management blocks occupy first 128 blocks of datafile or do they occupy blocks after last free extent block? The only management blocks I expect to find are these first 128 blocks (1M) which as I understand are datafile header (was 64K in earlier versions, but in 11.2 is 1M, with 8K results in 128 blocks).
Or do you mean the fact of using autoallocate extent size influences this matter? Should we consider "autoallocate start size" of 64K in relation to something?Your interpretation of what I was saying is correct - but I got the scale wrong, there's a different explanation of what you're seeing.
If you dump the first few blocks of the file, in your case using something like:
alter system dump datafile 129 block min 2 block max 6;you will see that block 2 will be the "file space header block" and the next blocks will be file space bitmap blocks.
Each file space bitmap block (in an 8KB block) loses a couple of hundred bytes to block headers and other control details, then has one bit for each 64KB of the data file, where the 64KB unit is dictated by the autoallocate option
Sample dump:
buffer tsn: 14 rdba: 0x01c00002 (7/2)
scn: 0x0b86.40279c3f seq: 0x01 flg: 0x04 tail: 0x9c3f1d01
frmt: 0x02 chkval: 0x3100 type: 0x1d=KTFB Bitmapped File Space Header
File Space Header Block:
Header Control:
RelFno: 7, Unit: 8, Size: 655360, Flag: 1
AutoExtend: NO, Increment: 0, MaxSize: 0
Initial Area: 126, Tail: 655359, First: 0, Free: 81904
buffer tsn: 14 rdba: 0x01c00003 (7/3)
scn: 0x0b86.40279b45 seq: 0x01 flg: 0x04 tail: 0x9b451e01
frmt: 0x02 chkval: 0x0afb type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 7, BeginBlock: 128, Flag: 0, First: 0, Free: 63488
buffer tsn: 14 rdba: 0x01c00004 (7/4)
scn: 0x0b86.40279b47 seq: 0x01 flg: 0x04 tail: 0x9b471e01
frmt: 0x02 chkval: 0xcafb type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 7, BeginBlock: 508032, Flag: 0, First: 0, Free: 63488 Note particularly the "Free: 63488" - which is bits, each bit represents 8 blocks for a total of 507904. Allowing for the first 128 blocks in the file this is why the map in block 7/4 has a BeginBlock of 508032.
A single extent in dba_free_extents is, apparently, not allowed to cross a space management block.
Regards
Jonathan Lewis
P.S. Since there are 126 available file space bitmap blocks, and 507904 blocks allowed per bitmap block, then when the file hits 63,995,904 blocks (488.25 GB) Oracle will have to add a secondary space management area. (At least, that's if you grow the file to that size; if you pre-create the tablespace at that something above that size then perhaps Oracle will allocate 2M of file header.)
P.P.S Here's a quote from my errata pages for Practical Oracle 8i: "Allowing for a little overhead, a single 8K block can hold information about 63,488 extents,..." so not a lot has changed in the interim, apart from the fact that the header is now 1MB rather than 64KB - possibly to cater for bigfile tablespaces, possibly to help ASM and Exadata align their extents and AUs.
Edited by: Jonathan Lewis on Dec 7, 2012 6:30 PM

Fregmentation on LMTs!!!

Similar Messages

Maybe you are looking for