Asm extent allocation

Hi ASM experts ,
this is written in oracle11gr2 workshop1 lesson5 page 22
for the first 20,000 extents, the extent size is equal to the AU size. After 20,000 extents and up to 40,000 extents, the extent sets are always allocated 8 at a time with the extent size equal to 4*AU size. If the AU size is 1 MB, this means the ASM file will grow 64 MB at a time (8 * 4 * 1 MB). If the file is coarse-grained striped then it is striped across the 8 extent sets with stripes of 1 AU. Striping is always done at the AU level, not at the extent level. Thus every AU of a coarse-grained file is on a different disk than the previous AU of that file no matter how large the file. After 40,000 extents, the extents are still allocated 8 at a time, but with an extent size equal to 16*AU size.
first of all i don't know how 8*4*1 will be 64
and my question is does oracle allocate 8 extents at a time whatevre number of previous allocated extents under 20000 or over 40000?
thank you for reading.

user475845 wrote:
Hi ASM experts ,
this is written in oracle11gr2 workshop1 lesson5 page 22
for the first 20,000 extents, the extent size is equal to the AU size. After 20,000 extents and up to 40,000 extents, the extent sets are always allocated 8 at a time with the extent size equal to 4*AU size. If the AU size is 1 MB, this means the ASM file will grow 64 MB at a time (8 * 4 * 1 MB). If the file is coarse-grained striped then it is striped across the 8 extent sets with stripes of 1 AU. Striping is always done at the AU level, not at the extent level. Thus every AU of a coarse-grained file is on a different disk than the previous AU of that file no matter how large the file. After 40,000 extents, the extents are still allocated 8 at a time, but with an extent size equal to 16*AU size.
first of all i don't know how 8*4*1 will be 64
and my question is does oracle allocate 8 extents at a time whatevre number of previous allocated extents under 20000 or over 40000?
thank you for reading.Hi,
Documentation  says:
The extent size of a file varies as follows:
Extent size always equals the disk group AU size for the first 20000 extent sets (0 - 19999).
Extent size equals 4*AU size for the next 20000 extent sets (20000 - 39999).
Extent size equals 16*AU size for the next 20000 and higher extent sets (40000+).
Please check : http://docs.oracle.com/cd/E11882_01/server.112/e18951/asmcon.htm#BABCGDBF
Figure 1-4 Oracle ASM File Allocation in a Disk Group+
Regards
Mahir M. Quluzade

Similar Messages

  • RAC extent allocation

    Hi Guys,
    I had a question regarding extent allocation to a segments. In a RAC environment we allocate extent to specific instance, why is it so?
    As we know extent are the space allocated at stogare level, so why do we allocate to specific instance in RAC?
    Is there any specific reason to do so...
    Please suggest...
    Thanks!

    can you show me an example where you allocated an "extent" to a specific instance? Are you using ASM or shared file system - if shared FS, which one? Bigfile tablespace? Smallfile tablespace?

  • Overlapped extent allocation, backing up and erase/install

    Can't boot up my G4 flat panel iMac. Have tried safe boot mode - hangs on grey screen and spinning gears. Ran Disk Repair from install disk which reported 'overlapped extent allocation' files - dozens of 'em, so decided to back up users folders to g5 tower using target disk mode and I can access the iMac's hard drive through TDM.
    Having read this technical document:
    http://support.apple.com/kb/HT1553?viewlocale=en_US#3c
    it specifies that that I have to log into the imac as a root user to copy the user folders to the G5 but as I can't log in to it am I OK just to access and copy the user folders from the imac via target disk mode? (I've started this but, for example, when copying one of the user folders - 35GB of content - the copied folder correctly has 16 folders within, but has a few thousand bytes of data less than the original folder - why is this and will it cause problems after erasing the imac's drive and attempting to copy back the user directories?
    I have read elsewhere that I can search for the problematical Overlapped Extent Allocation files in the DamagedFiles directory but can I safely delete these and how can I tell if I can or can't and how do I find them? (the reasoning being that if I can safely delete these then the imac may boot up OK)
    When quitting the installer menu on the imac (when booting from the install disk) I am prompted to either quit or choose startup disk. If I choose the latter option will the imac boot from the install disk enabling me to back up the user folders to an external drive using the method recommended in the technical document I previously referred to (i.e logging in as a root user)?
    Thanks for any help

    There are a couple of ways to deal with the problem. See the following:
    Handling 'overlapped extent allocation' errors reported by Disk Utility or fsck;
    Or buy Disk Warrior which will fix the problem for you and any other directory related problems that Disk Utility does not fix.
    However, the most effective solution is to erase the drive and reinstall OS X. Since you are accessing the drive via TDM, copy your personal data to a backup drive or folder on the other computer. There's no benefit to copying the entire Home folder because it may contain files affected by the problem. Better to copy only your data files. You will have to do some software reinstalling and re-registering, but that's better than having damaged files.

  • Why use uniform extent allocation?

    version- 11.2.0.2.0
    Hello guys, I've been reading UNIFORM vs AUTOALLOCATE extent allocation.
    I've read the following articles.
    https://blogs.oracle.com/datawarehousing/entry/parallel_load_uniform_or_autoallocate
    Ask Tom: On Loading and Extents
    https://forums.oracle.com/thread/2518951
    From what I understood, autoallocate trumps the uniform in all scenarios (unless I am missing something).
    In the thread "AUTOALLOCATE vs UNIFORM SIZE"
    for the benefits of autoallocate and uniform size allocation Kh$n wrote
    Benefits of AUTOALLOCATE
    * Prevents space fragmentation.
    Benefits of UNIFORM extent sizes
    * Prevents fragmentation. 
    (I dont understand what is the difference between those two fragmentation prevention, are those benefits one and the same?)
    even in scenarios where we know exactly how much data will be loaded, there is always a chance of extent wastage and with out extent trimming that space will be unusable.
    Can someone please explain in which cases we use uniform extent allocation?
    for suppose we use uniform extent allocation and we have lot of unused space from the extent allocation, can that space be reclaimed using shrink space command for tables and indexes?
    Thank You

    Extent trimming, to the best of my knowledge, is something that only happens when you are using parallel query to do large loads, not something that happens during normal OLTP type operations.  As with anything called "automatic" in Oracle, though, the internals are subject to change across versions (and patchsets) and are not necessarily documented, so it is entirely possible for behaviors to change over time.  Relying on specific internal behaviors is generally not a good idea.
    The example I gave (assuming you reverse the truncating of A and the loading of C, as Hemant pointed out) produces "fragentation" when you're using automatic extent management.  It's not a particularly realistic scenario, but it is possible.  If you never delete data, never truncate tables, (and, presumably, never shrink tables), extents would never be deallocated and there would, therefore, never be holes.  That is just as true of ancient dictionary managed tablespaces as well as locally managed tablespaes whether you're using uniform or autoallocated extents.
    Shrinking a table has nothing to do with defragmenting a tablespace.  It is simply compacting the data in the table and then potentially deallocating extents.  You can do that with any locally managed tablespace.  There is still the possibility, of course, that you have just enough data in the table that you need to allocate 1 extra extent when you only need space for 1 row in 1 block.  So there may be some number of MB of "wasted" space per segment (though, again, this is generally not something that is a practical concern since the data in tables generally changes over time and it's generally not worth the effort of worrying about a few MB).
    Justin
    For your third question, assuming both extents are part of the same segment, assuming that the space is actually usable based on things like the PCTUSED setting of the table, and assuming a nice, simple conventional path insert in a single-user, Oracle would use the free space in the extent for new inserts before allocating a new extent.  Oracle generally doesn't allocate new extents unless it needs to (there are caveats to this-- if the only blocks with free space have a relatively large fraction of their space used such that a particular new insert only fits in 1 of the 1 million blocks in the currently allocated extents, Oracle will potentially give up before finding the 1 in a million block that it would need an may allocate a new extent).
    Message was edited by: JustinCave

  • Repeated Overlapped Extent Allocation

    I recently began having problems with "Overlapped Extent Allocation" errors on my hard drive on my "Late 2010" MacBook Air. When it first happened, I formatted the drive, reinstalled OSX 10.7, and restored my data. Within a month or so, the drive was corrupted again with the same errors. So, I replaced the hard drive, reinstalled OSX, and restored my data. Now, only a couple weeks after doing this, I am having the same problem yet again. What could be causing this to happen so frequently?

    Linc,
    Thanks for the reply. Unfortunately, I've already replaced the drive and it's doing the same thing on the new drive. I suppose it's possible that I got a bad drive, but it's hard to imagine it having exactly the same error as the previous drive.

  • Overlapped extent allocations

    Hi all,
    I'm trying to solve a number of overlapped extent allocations (OS X 10.2.8) using the command line solution described in http://docs.info.apple.com/article.html?artnum=25770. I have previously tried to fix the HD using Tech Tool deluxe, but the repair phase seems to hang after a few hours when the rate of block processing slows down to one per several minutes - suggesting a time to complete of about 11 days!!
    Starting with 9 overlaps, I've deleted offending files for 6 of them - they were either preference or cache files that could go without any knock-on impact.
    I'm now left with the following affected files:
    Users/mike/Library/Mail/Mailboxes/Mailgroups/GPSrunners.mbox/Incoming_mail
    /private/var/run/cron.pid
    /private/var/run/utmp
    Can anyone please advise how to deal with these?
    I'm happy to lose the mailbox if I delete the first one.
    What do the 2nd and 3rd files do?? Will they cripple my OS if I delete them? I have a backup of my HD on an external drive taken a few weeks ago so the user data will not be current but the OS should be an intact backup of the OS - I can certainly boot from it. Is there a way to replace them from the HD, and if so do I have to do that from the command line (they don't seem to be visible to the finder).
    Grateful for any help - in nice simple steps for someone whose command line knowledge was limited to fsck until today!
    thanks,
    Mike
    iMac800   Mac OS X (10.2.x)  

    Kappy, Fifthwheel, WJ,
    Thanks for your excellent help.
    I've deleted the mbox and cron.pid files - the allocation error asociated with the utmp file just seems to have gone away. Checking the HD by fsck or Disk Uitility/First Aid from an external drive says the disk is OK.
    HOWEVER, I still have the problem reported here:
    http://discussions.apple.com/thread.jspa?threadID=583008&tstart=0
    Could this login difficulty be caused by the utmp file being damaged? If so, how can I replace it by a good one if, as WJ suggests, it will not be recreated automatically if I delete it?
    Can I use the one on my external drive which has the OS backed up, and if so how do I actually move it (command line or finder)?
    thanks,
    Mike
    iMac800 Mac OS X (10.2.x)
    iMac800 Mac OS X (10.2.x)

  • Fixing "overlapped extent allocation (file 7d)"...

    Hi,
    While running fsck i get the error "overlapped extent allocation (file 7d)"
    I've read the guide on how to delete problematic files, but does this apply to my error (i.e. it's not a 7-digit file number)?
    btw, i tried running "find / -inum 7". The hard drive buzzes a bit then displays the normal prompt (sh-2.05) and not the path to my problem file...
    Any ideas?
    Thanks
    mac os x 10.2.3

    By "regular mode", he means after the system has booted to the login window. Most people who run fsck do it from single-user mode (no GUI, no Terminal; just a command line).
    When you try 'sudo -s' from a non-administrator account, it will fail ("(this user) is not in the sudoers file..."). Thus when you typed the 'find / -inum 7', you are doing the search as the non-administrative user rather than as root, which means that your access to the file system is limited to the files and directories that that user is allowed to read (usually only system files and its own home directory). So no, the directories that yield ": Permission denied" are not corrupt; they just aren't yours, so you're not allowed to search them.
    Disk Warrior won't do you much good if you try to run it from a non-administrator account; it'll suffer the same restrictions you encountered with your 'find'.
    Your best bet is to print reboot to single-user mode and attempt to fix the problem there.

  • Determining Extent Allocation Type

    Does anyone know how you tell if a tablespace has been configured to use UNIFORM extent allocation or AUTO ALLOCATE . I can see in dba_tablespaces if the extent is dictionary or locally managed. I can also see if it is using ASSM or not but I am struggling to see where the actual method of extent allocation is recorded
    thanks,
    Jim

    http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_4157.htm
    ALLOCATION_TYPE

  • Change extent allocation in tablespace

    Hi All,
    Database Version : 11.1.0.6
    I have a LMT tablespace with uniform extent of 192 K. It has been in use since long .
    Is it possible to change the extent allocation to AUTOALLOCATE now ?
    If not , is there any workaround ..
    Thanks

    hi..
    there is no "alter table space" syntax for changing extent management from uniform to auto allocate. Hence, you must re-define the table space to change the extent management:
    * Backup the table space
    * Export the table space data
    * Drop and re-allocate the table space
    * Import the table space

  • Overlapped extent allocation

    My iBook is not starting, so I ran the start up disc, and the diagnostic said I had an overlapped extent allocation. So I want to back up before I reinstall OS X, but I do not not know how to back up from either the start up or safe mode. Can someone help me? Thanks so much.

    Angela:
    When I ran the Disk Utility it said it was fixed, but I still could not start up the computer. I actually ran the Utility a couple of times.
    Yet in your first post in the topic you said:
    so I ran the start up disc, and the diagnostic said I had an overlapped extent allocation.
    If Disk Utility said it was fixed, what "start up disc" did you run?
    As Doug pointed out, overlapping extent allocation files is a directory issue that needs to be addressed by a utility like Disk Warrior or Tech Tool Pro. Backing up and re-installing is an acceptable solution, but much more invasive.
    One of the causes of overlapping extent allocation files is an overfull internal Hard Disk Drive. If you have less than 10% of available capacity on your HDD you should consider leaning down the contents of the drive or getting a larger HDD.
    Good luck.
    cornelius
    Message was edited by: cornelius

  • 10g Local Extent Allocation "UNIFORM"

    Hello all,
    I'm in the process of 8i (Dictionary extent) to 10g (Local extent) migration, and I have a question.
    is "USER" allocation in 8i same as "UNIFORM?"
    Thanks!

    ok thank you. Here's the steps I've taken:
    1. Pre-created the tablespace as "UNIFORM" on 10g
    2. Ran IMP (dmp from 8i, as "USER")
    3. ALLOCATION_TYPE still shows as "UNIFORM"
    So basically, because the purpose was to EXP/IMP from server A to server B, I did not do take any upgrade steps, just simple EXP/IMP. Would the upgrade option automatically have changed allocation_type to "USERS" from "UNIFORM?"
    if you see something wrong with below, please kindly let me know...
    SQL> select tablespace_name, extent_management, allocation_type, contents from dba_tablespaces;
    TABLESPACE_NAME EXTENT_MAN ALLOCATIO CONTENTS
    SYSTEM LOCAL USER PERMANENT
    SYSAUX LOCAL SYSTEM PERMANENT
    USERS LOCAL SYSTEM PERMANENT
    TOOLS LOCAL SYSTEM PERMANENT
    TEMP LOCAL UNIFORM TEMPORARY
    TEMP_ACDB LOCAL UNIFORM TEMPORARY
    USERS_ACDB LOCAL SYSTEM PERMANENT
    UNDO01 LOCAL SYSTEM UNDO

  • How many extents allocated when table created?

    I am using Oracle 9,
    is the number going to be what we specified by minextents?
    thanks

    Srinivas,
    You said,
    If its AUTOALLOCATE , Oracle starts with 1 extent of 64KB , then 128KB as the first extent becomes full, then 256KB so on....
    Can you help me in understanding this statement?I don't think that its true. See here,
    SQL> select * from V$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    SQL> drop tablespace test including contents and tablespaces;
    drop tablespace test including contents and tablespaces
    ERROR at line 1:
    ORA-00905: missing keyword
    SQL> drop tablespace test including contents and datafiles;
    Tablespace dropped.
    SQL> create tablespace test datafile 'd:\test.dbf' size 100m extent
    ocal autoallocate ;
    Tablespace created.
    SQL> select tablespace_name,initial_extent,next_extent from dba_tab
      2  where tablespace_name='TEST'/
      3
    SQL> select tablespace_name,initial_extent,next_extent from dba_tab
      2  where tablespace_name='TEST'
      3  /
    TABLESPACE_NAME                INITIAL_EXTENT NEXT_EXTENT
    TEST                                    65536
    SQL> --Creating a table inside in this tablespace
    SQL> create table t as select * from dba_objects;
    Table created.
    SQL> alter table t move tablespace test;
    Table altered.
    SQL> select tablespace_name, extent_id, bytes/1024, blocks
      2  from user_extents
      3  where segment_name = 'T';
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                    0         64          8
    TEST                                    1         64          8
    TEST                                    2         64          8
    TEST                                    3         64          8
    TEST                                    4         64          8
    TEST                                    5         64          8
    TEST                                    6         64          8
    TEST                                    7         64          8
    TEST                                    8         64          8
    TEST                                    9         64          8
    TEST                                   10         64          8
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   11         64          8
    TEST                                   12         64          8
    TEST                                   13         64          8
    TEST                                   14         64          8
    TEST                                   15         64          8
    TEST                                   16       1024        128
    TEST                                   17       1024        128
    TEST                                   18       1024        128
    TEST                                   19       1024        128
    TEST                                   20       1024        128
    21 rows selected.
    SQL>
    SQL> insert into t select * from t;
    50356 rows created.
    SQL> /
    100712 rows created.
    SQL> /
    201424 rows created.
    SQL> /
    402848 rows created.
    SQL> commit;
    Commit complete.
    SQL> analyze table t compute statistics;
    Table analyzed.
    SQL> select tablespace_name, extent_id, bytes/1024, blocks
      2  from user_extents
      3  where segment_name = 'T';
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                    0         64          8
    TEST                                    1         64          8
    TEST                                    2         64          8
    TEST                                    3         64          8
    TEST                                    4         64          8
    TEST                                    5         64          8
    TEST                                    6         64          8
    TEST                                    7         64          8
    TEST                                    8         64          8
    TEST                                    9         64          8
    TEST                                   10         64          8
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   11         64          8
    TEST                                   12         64          8
    TEST                                   13         64          8
    TEST                                   14         64          8
    TEST                                   15         64          8
    TEST                                   16       1024        128
    TEST                                   17       1024        128
    TEST                                   18       1024        128
    TEST                                   19       1024        128
    TEST                                   20       1024        128
    TEST                                   21       1024        128
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   22       1024        128
    TEST                                   23       1024        128
    TEST                                   24       1024        128
    TEST                                   25       1024        128
    TEST                                   26       1024        128
    TEST                                   27       1024        128
    TEST                                   28       1024        128
    TEST                                   29       1024        128
    TEST                                   30       1024        128
    TEST                                   31       1024        128
    TEST                                   32       1024        128
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   33       1024        128
    TEST                                   34       1024        128
    TEST                                   35       1024        128
    TEST                                   36       1024        128
    TEST                                   37       1024        128
    TEST                                   38       1024        128
    TEST                                   39       1024        128
    TEST                                   40       1024        128
    TEST                                   41       1024        128
    TEST                                   42       1024        128
    TEST                                   43       1024        128
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   44       1024        128
    TEST                                   45       1024        128
    TEST                                   46       1024        128
    TEST                                   47       1024        128
    TEST                                   48       1024        128
    TEST                                   49       1024        128
    TEST                                   50       1024        128
    TEST                                   51       1024        128
    TEST                                   52       1024        128
    TEST                                   53       1024        128
    TEST                                   54       1024        128
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   55       1024        128
    TEST                                   56       1024        128
    TEST                                   57       1024        128
    TEST                                   58       1024        128
    TEST                                   59       1024        128
    TEST                                   60       1024        128
    TEST                                   61       1024        128
    TEST                                   62       1024        128
    TEST                                   63       1024        128
    TEST                                   64       1024        128
    TEST                                   65       1024        128
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   66       1024        128
    TEST                                   67       1024        128
    TEST                                   68       1024        128
    TEST                                   69       1024        128
    TEST                                   70       1024        128
    TEST                                   71       1024        128
    TEST                                   72       1024        128
    TEST                                   73       1024        128
    TEST                                   74       1024        128
    TEST                                   75       1024        128
    TEST                                   76       1024        128
    TABLESPACE_NAME                 EXTENT_ID BYTES/1024     BLOCKS
    TEST                                   77       1024        128
    TEST                                   78       1024        128
    TEST                                   79       8192       1024
    TEST                                   80       8192       1024
    TEST                                   81       8192       1024
    82 rows selected.
    SQL>Its not working in the way youmentioned. The extents are of 65kb till 16 extents than it changes to 1024kb untill 78 and then 8192 kb. Is it something that I am missing?
    Aman....

  • ASM Disk Allocation

    Dear All,
    I need one more piece of advice from you guru's.
    I have 20 TB of SAN available. Our database is currently 1 TB in size and will grow to 20 TB very soon. We have the following env:
    OS: RHEL 5.5
    DB: Oracle Database 11g R2 Patch - 1
    RAC: 2-node RAC using ASM
    RAID: SAN is Raided as "1+0"
    The question:
    How do I allocate the 20 TB of storage to ASM. How many LUNs should I create? As SAN is already RAIDed, I don't think I should go ASM redundancy.
    Please share your experience.
    Thanks
    P

    Hi,
    max LUN size ASM can handle on non Exadata platform is 2TB.
    So I would choose any size between 1 to 2TB luns.
    With 2 TB Luns you are left with a total of 10 .
    You could use more (smaller), but then you have to administer and oversee more luns. I think 10 is a pretty nice number..
    Max I would to is 1TB lun and end up with 20 luns.
    However keep in mind, that when you want to grow, Oracle recommends adding luns with the same size.
    So if you don't wan't to grow in 2 TB steps in the future, choose a smaller lun size.
    As you stated you can stay with external (no) redundancy in ASM.
    Regards
    Sebastian

  • Most allocated extents in any segment

    hi gurus
    My db is oracle with HP-UX In rz20 -- database-oraclesegmentsin that most allocated extents in any segment-  is showing red.how to rectify this problem. and y its shoing red wht is the problem and how can i solved this.
    thanks/regards

    Hi,
    If you are using Locally managed tablespace ( by default as of Oracle 9i), then you dont have worry about this warnings.
    High number of extents is not a problem in LMTS.
    Please check the below link & sap notes
    http://help.sap.com/saphelp_nw70/helpdata/EN/25/5215e970077e4fb366e5ce25629aac/frameset.htm
    Note 599694 - LMTS autoallocate: Extent allocation
    Note 706625 - Oracle9i: Locally managed SYSTEM tablespace
    Note 214995 - Oracle locally-managed tablespaces in the SAP environment
    Hope this helps.
    Thanks,
    Sushil

  • DB02:Space management/Segments/Most allocated extents in any segment

    Hi ,
    in My SAP server: DB02 > Oracle Database Administration > Alerts > Alert monitor, there are few red alerts.
    1. Space management > Segments >Most allocated extents in any segment  263  > 200   - 263 > 200: number of extents > threshold 03.03.2009 09:35:46
    in RZ20 Most allocated extents in any segment  having thersold value :200
    Can anybody knows what it is about? How to fix this? And what are the risks if I ignore this?
    with Regards
    Harinatha Reddy M

    Hi,
    What is your Oracle database version.? If it is 9i or 10g then you can ignore this warning as from Oracle uses Localy managed Tablespaces.
    Please check below mentioned SAP notes, it may help you.
    Note 599694 - LMTS autoallocate: Extent allocation
    Note 706625 - Oracle9i: Locally managed SYSTEM tablespace
    Note 214995 - Oracle locally-managed tablespaces in the SAP environment
    Thanks,
    Sushil

Maybe you are looking for