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?

Similar Messages

  • 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

  • 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

  • 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....

  • 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

  • OATM conversion - should I use unform or auto allocated extents

    Hi, as part of an 11i to R12 E-Biz upgrade, I am migrating to the OATM model of tablespaces. One issue I am not sure about is whether to create the new OATM tablespaces so that they use Uniform Extents or whether I should set them to use Auto Allocate. I appreciate that some folk believe Auto Allocate can in the long run lead to freespace fragmentation. However I have not seen any recommendation from Oracle in any of the upgrade documentation as to which method of extent allocation to use.
    Q1. Any ideas on which is the recommended / better / wiser extent allocation method to use ?
    Q2. Are the concerns around free space fragmentation with the Auto Allocate method really likely ?
    Also when I ran the Sizing Report in the OATM migration utility against my existing non OATM 11i tablespaces to predict the space I required for the migration, I got very different results / predictions !
    For Uniform Extent Allocation I got the following prediction
    Required 20% buffer Current
    ======= ======= =====
    Total(in KB): 83,552,256 100,261,687 31,653,400
    For Auto Allocate I got the following prediction
    Required 20% buffer Current
    ======= ======= =====
    Total(in KB): 29,842,048 35,809,437 31,653,400
    Q3. Any idea why there is such a large variation between the predicted figures for both methods ?
    any insight or shared thoughts greatly appreciated,
    Jim

    Thanks Hussein,
    The notes indicate that the recommendation for OATM is Uniform Extnts of 128 Kb. However it caveats that with the statement "if that suits your database". How are you meant to pre-determine what extent size suits your current data / database ?
    Also when I ran the pre-sizing report in the OATM migration utility I got vastly different space predictions ( see below ) when proposing to use Uniform Extent Allocation ( of 128 Kb ) and Auto Allocate. Do you know why there should be such a large difference in the figures ( especially as the recommended Unform Extent allocation is so much larger ! )
    For Uniform Extent Allocation
    ==================
    Required 20% buffer Current
    Total(in KB): 83,552,256 100,261,687 31,653,400
    For Auto Allocation
    ============
    Required 20% buffer Current
    Total(in KB): 29,842,048 35,809,437 31,663,600

Maybe you are looking for

  • Problem in my Select query

    Hi Experts, I need a clarification in my Select query. Have created a custom search help and my requirement is I have Request ID, Last and First Name as my search parameters. I need to fetch the values from my Ztable on search with the above said sea

  • Hello may name is Artur. How I can connect my PC and my Iphone to my appletv

    How can I connect my Iphon and PC to my appletv?

  • Overconfirmation-Sum of confirmed quantity exceeds  sum of stock

    Hi, We have stock for a material but on the CO06 screen cumulated ATP quantity is negative. Although there is only one open sales order. How can I correct  the problem. Thanks.

  • Java.io.InvalidClassException in WebLogic

    When I use weblogic 8.1 JMS SERVICE,I encounter a problem. Sample code like: Properties p=new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory"); p.put(Context.PROVIDER_URL,"t3://localhost:7001"); Context con

  • Domain controller backup and recovery

    We have  5 DCS 3 in one location and other 2 in another location Considering the first location with 3 dcs, we have baremetal backup (windows server backup) configured for all 3 dcs What will be the best way to restore/recover if one of the dc fails,