Optimal size for TEMP tablespace tempfiles

Hi all,
I've rumaged through Oracle documentation on the above topic but can't find the answer I'm seeking:
How do you determine the optimal size for your tempfiles? Are there rules to guide one in this area? For example for a 50G database, how do you determine if it's 2G, 3G or 4G that's best for the database? What about a 500G database?
Anwers will be appreciated.
Regards

It's the size of the sets, as you say. And in a data warehouse, the data sets can be very large. I'd say that in an OLTP database, then the useage of temp would (should) be low; but in a data warehouse, all bets are off: one-off end of month runs; director wants a monolithic report running; all that sort of DWH-related type of processing, which, by its nature, happens all the time. Similarly, a large number of users (e.g. users of, say, a Third Party BI tool) amy lead to lots of big sorts, owing to the ad hoc nature of their queries. Standard DWH stuff.
I don't often see tiddly-widdly bits of SQL in data warehouses, like your SELECT COUNT(*) FROM tab$ example. It could be done, sure, but more likely will be bit, fat queries, which a DWH is designed to deal with. And a lot of temp may be required.
From that 6-years old (but relevant) article (my emphasis): "For example, if you join two *large* tables, and Oracle cannot do the sort in memory (see SORT_AREA_SIZE initialisation parameter), *space will be allocated in a temporary tablespace for doing the sort operation*."
Regards - Don Lewis

Similar Messages

  • Size for TEMP tablespace

    I don't know if this is a "valid" question. We have users running reports on our production system. The sometimes complain about the temp space being too small (due to their queries crashing when using too much temp space).
    But I also have a feeling that you can keep throwing disks at TEMP space, and that it will never be enough.
    What should the size of a database's TEMP space be - is there a rule of thumb for this ?
    Dirk

    There are several considerations that you should take into account when you try to size your temporary tablespace:
    First, how much sort does you average transaction need and how many concurrent transactions does your system need to support. This number gives you a starting point for the minimum workable size for normal operations.
    Now, how big is the largest table on your system and do you wish to be able to support select * from biggest order by ? Supporting an unqualified select on your largest table may not be required.
    How big is the largest index in your system? It is likely that you need to have enough temp space available to recreate this index in the event of corruption without having to take special action to allocate more space to temp on a temporary basis. But having to add space in the event of a diaster might be acceptable.
    Figure out what the largest sort operation you need to be able to support is and then add enough space to handle the number of concurrent average transactions that would be expected to be on the system at the same time. This is the size you should use for your temporary tablespace.
    It is better to have all the space you will need for any normal and for any maintenance operation available at all time rather than trying to find additional file space to support special maintenance tasks or diaster recovery operations.
    HTH -- Mark D Powell --

  • Determining datafile size for temp tablespace

    Is there a rule of thumb for determining the size of the temporary tablespace, or at least a common starting value?
    -Thanks
    Chuck

    Rule of thumb ... trial and error.
    That is what your test environment is for.
    We have over 200 databases with TEMP ranging from 50Mb up to 56Gb. So go figure!!!

  • Storage parameter for Temp tablespace

    Hi all,
    Greetings of the day...
    DB version is 10.2.0.4 ..Size of db is 550gb and in that temp tablespace is 40gb... daily and frequently we used to unable to extent temp segments...Saw the storage parameters of temp segments it has only 'EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16777216'
    Please suggest as how to define storage parameters for temp tablespace...Am able to find the query which uses temp segments...Just needed to know abt the storage parameters for it..
    thanks,
    baskar.l

    CREATE TEMPORARY TABLESPACE TEMP TEMPFILE
    '/u02/TSTLOG/temp01.dbf' SIZE 15360M AUTOEXTEND ON NEXT 100M MAXSIZE 32767M
    TABLESPACE GROUP ''
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
    Hope this will work.
    Regards
    Asif Kabir

  • To shrink the size of TEMP tablespace

    Dear all,
    There is a databse with RAC, now in OEM the size of TEMP tablespace has been reached at 99.9%. now we want to shrink the size of TEMP tablespace.
    how to we do that???????
    plz help me...........

    Temporary tablespaces usually show they are full, however this space is not actually in use. It is rather allocated. Oracle has evaluated the best way to obtain the most of performance, and he said it is better to allocate once than allocate-deallocate-reallocate extents, so temporary space is not 'released'.
    If you want to feel psychologically more confortable with lower allocated space, you can drop your tablespace (create an interim default temporary tablespace first) and recreate it.
    You can also rebuild temporary datafiles:
    alter tablespace temp add tempfile 'C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.dbf' size 32m;
    SQL> select name from v$tempfile;
    NAME
    C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP.DBF
    C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.DBF
    SQL> alter database tempfile 'C:\ORACLE\ORACLEXE\ORADATA\XE\TEMP01.DBF' drop including datafiles;
    Database altered.

  • Optimal size of System - Tablespace

    What is the optimal size for the system-tablespace with all option (with JVM and more) with the ORACLE Version 8.1.7 or 9i ?

    There is no one-size-fits-all answer. The options you mentioned will have some affect on the size, only because they will add more OBJECTS to the database. The key drivers for how to size SYSTEM are the number of objects and users you anticipate in your database, and the number of database structures (tablespaces, files, logs, etc). The dictionary tables in the SYSTEM tablespace exist to maintain information on everything in the database, and are updated automatically as changes are made to database objects or structures. I usually recommend 200M as a safe starting value unless you know you will be creating a lot of objects, go with 250-300M.
    A little story. A while back, I was forced (while protesting quite loudly) to create private synonyms for every table in the database for every user in the database. I warned the people who ordered this that we might encounter problems in SYSTEM, (and in the shared pool) because the total number of OBJECTS (synonyms) being added totalled well over 1 million. As predicted, the system tablespace could not handle the load, and I had to add one new file to SYSTEM, and then another on a DIFFERENT storage volume (no space left on original). When this was done, our SYSTEM tablespace was almost 600M. (The OBJ$ table swelled up like a balloon). When the geniuses who forced me to do this realized it was a really bad idea, they told me to drop the synonyms. But we were left with 3 SYSTEM datafiles when we only needed one (you can't drop them).

  • How do you determine the optimal size for Mozilla Firefox?

    How do you determine the optimal size for cache in Mozilla
    Firefox? I am using Firefox 7.0.1 on a 64-bit Windows 7 Ultimate operating system with 3GB RAM and 300 GB hard drive, but I have other computers running Windows XP. If the answer doesn't apply to all current versions of Firefox on all supported Windows operating systems, please explain the differences. Is there a formula for calculating the best cache size?

    I found that the best idea is to let Firefox decide that itself.

  • Adobe SendNow - What is the optimal size for custom logos?

    I just tried to upload a custom logo (800x200) and it seemed to be stuck up in the top left corner, with a large amount of blank white screen.
    What is the optimal size for this please, and how do I centre a smaller logo?
    It is of course entirely possible I will need to make one in PS - not a problem - but the right sizes would be helpful info please.
    Many Thanks

    That is what I read too - but when I uploaded one it got tucked up in the top left corner of the "custom" setup thumbnail.
    Perhaps it is just a glitch in that dialogue, but it certainly looked as if there was a raft of space to the right & underneath.
    Still, probably Pilot Error so I will recheck - thank you Dave.

  • OPTIMAL size for rollback segment in Oracle 8i

    In our Database we have 13 Rollback segments & total size of all rollback segments is 33gb.
    Used % it is showing 99.84%.
    each rollback segment having near around 4gb of size.
    I am in confusion to set OPTIMAL value for each rollback
    segment.
    can any one help me out reg this.
    My roll back seg statistics are as fallows:
    SEGMENT_NAME TABLESPACE_NAME WAITS SHRINKS WRAPS STATUS
    R00 SYSTEM 0 0 12 ONLINE
    RBS0 RBS 0 0 19 ONLINE
    RBS01 RBS 0 0 16 ONLINE
    RBS02 RBS 1 0 12 ONLINE
    RBS03 RBS 0 0 11 ONLINE
    RBS04 RBS 0 0 21 ONLINE
    RBS05 RBS 1 0 22 ONLINE
    RBS06 RBS 0 0 16 ONLINE
    RBS07 RBS 0 0 15 ONLINE
    RBS08 RBS 0 0 12 ONLINE
    RBS09 RBS 1 0 19 ONLINE
    SEGMENT_NAME TABLESPACE_NAME WAITS SHRINKS WRAPS STATUS
    RBS12 RBS 0 0 13 ONLINE
    RBS13 RBS 0 0 18 ONLINE
    SYSTEM SYSTEM 0 0 0 ONLINE

    Aman,
    Definitely that would be a great approach to share the knowledge; but right now my notes are still in the shape of notes only; i have'nt tested them. I simply read forum and asktom and whenever i found good lines i copy and paste them and whenever i found the similar question in the forum i paste / repharase there in my own language and understanding (because till then i have tested and learnt them very well.)
    Although i am highly obliged by your suggestation; let me that much knowledgable; so that i may run my own blog...!
    Regards
    Girish Sharma

  • Maxsize 0 after autoextend turned off for Temp tablespace!

    Hi,
    DB:11.1.0.7
    We had earlier the tempfiles with maxszie unlimited as below:
    select FILE_NAME,TABLESPACE_NAME,BYTES/(1024*1024) "Size",MAXBYTES/(1024*1024) "Maxsize",AUTOEXTENSIBLE from dba_temp_files;
    February 10, 2011 Tablespace used by DEV database
    ===================================
    FILE_NAME
    TABLESPACE_NAME Size Maxsize AUT
    /oradata/DEV/temp01.dbf
    TEMP 1024 32767.9844 YES
    /oradata/DEV/temp02.dbf
    TEMP 1024 32767.9844 YES
    /oradata/DEV/temp03.dbf
    TEMP 3072 32767.9844 YES
    Now after turning autoextend off, why maxsize is showing as '0' instead of being at unlimited as earlier?
    Please see below:
    select FILE_NAME,TABLESPACE_NAME,BYTES/(1024*1024) "Size",MAXBYTES/(1024*1024) "Maxsize",AUTOEXTENSIBLE from dba_temp_files;
    February 10, 2011 Tablespace used by DEV database
    ===================================
    FILE_NAME
    TABLESPACE_NAME Size Maxsize AUT
    /oradata/DEV/temp01.dbf
    TEMP 1024 0 NO
    /oradata/DEV/temp02.dbf
    TEMP 1024 0 NO
    /oradata/DEV/temp03.dbf
    TEMP 3072 0 NO
    Could anyone please explain?
    Thanks for your time!
    Regards,

    Handle:      user10088255
    Status Level:      Newbie
    Registered:      Mar 4, 2009
    Total Posts:      87
    Total Questions:      62 (62 unresolved)
    so many questions without ANY answers.
    http://forums.oracle.com/forums/ann.jspa?annID=718

  • INCLUDED_IN_DATABASE_BACKUP for temporary tablespace

    Hi,
    The query output from v$tablespace shows the INCLUDED_IN_DATABASE_BACKUP value for temp tablespace in my db is "YES". The only way to have the value "NO" is to configure rman to exclude tbs. But you can not exclude temporary tablespace. Based on the size of total full backup files, the temp tablespace does not seem to be backup by rman. Is this a bug or is there other way to set this value for temporary tablespace to "NO"? I'm using 9iR2. Thanks.

    >...The only way to have the value "NO" is to configure rman to exclude tbs. But you can not exclude temporary tablespace.
    RMAN doesn't include the temporary tablespace in the backups.
    SQL> select * from v$tablespace;
           TS# NAME                           INC
             0 SYSTEM                         YES
             7 TEST                           YES
             3 USERS                          YES
            4 TEMP YES
             6 UNDO                           YES
    RMAN> list backup of tablespace TEMP;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of list command at 01/26/2006 20:04:06
    RMAN-06004: ORACLE error from recovery catalog database: RMAN-20202: tablespace not found in the recovery catalog
    RMAN-06019: could not translate tablespace name "TEMP"
    RMAN> list backup of tablespace UNDO summary;
    List of Backups
    ===============
    Key     TY LV S Device Type Completion Time #Pieces #Copies Tag
    3125    B  0  A DISK        22-JUL-05       1       1       TAG20050722T102731
    3207    B  0  A DISK        24-OCT-05       1       1       TAG20051024T163622
    3248    B  1  A DISK        02-NOV-05       1       1       TAG20051102T225318
    3360    B  F  A DISK        23-JAN-06       1       1       TAG20060123T172135Aron

  • Oracle 9i TEMP tablespace backup problem using RMAN!

    Oracle8/8i whole backup is ok for our backup software(using RMAN without RC database), but for Oracle 9i, I get following error messages when backing up temp tablespace.
    1. RMAN-20202: tablespace not found in the recovery catalog
    2. RMAN-06019: could not translate tablespace name "TEMP"
    I check some views of Oracle9i, and know some changes happen for temp tablespace in 9i, but how to deal with this problem. Any idea, please!

    In 9i RMAN does not restore temporary datafiles. Instead, you should create them after your restore. I believe that Oracle is going to make a change to this in the next release of 9i and have RMAN create the temporary files. You can view the temporary datafiles @ v$tempfile.
    I believe RMAN doesn't restore temporary files because they are locally managed and not in the control files. RMAN reads the controlfile of the target database to obtain info about backups, datafiles, etc.
    Hope this helps.

  • Temp tablespace 99%full

    What are the suggestion for temp tablespace, if its 99%full, should we keep adding space in it or it will use existing space?
    TABLESPACE TOTAL_MB USED_MB FREE_MB PCT_USED GRAPH (X=5%)
    TEMP 17,500.00 17,444.00 56.00 99.68 [XXXXXXXXXXXXXXXXXXX-]

    Hi,
    >>What are the suggestion for temp tablespace, if its 99%full, should we keep adding space in it or it will use existing space?
    I think that you don't need worry about, unless you're receiving some ORA- error about out of space in TEMP tablespace. You can see below an SQL output from a database used here in my company for development and tests purposes. The database is up uninterruptedly by 7 months and the space size for the TEMP tablespace have been configured to use 900 MB.
    LEGATTI@ORACLE10> SELECT tablespace_name, SUM(bytes_used), SUM(bytes_free)
      2  FROM   V$temp_space_header
      3  GROUP  BY tablespace_name;
    TABLESPACE_NAME                SUM(BYTES_USED) SUM(BYTES_FREE)
    TEMP                                 943718400               0Cheers
    Legatti

  • Setting the size of a tablespace prior to its creation

    Hi guys,
    Oracle version: 10.2.0.x
    OS: Windows 32bit
    I was wondering if there are any 'conditions' in setting the intial size of a tablespace prior to its creation. This is because, one of our customers wants to export and import from one schema into another but set an initial size for a tablespace during its creation and prior to importing data into it, but we have a database wizard tool that creates the accounts/schemas by using the following underlying sql:-
    CRETE TABLESPACE <tbl_name> datafile <path><datafile_name>.dbf SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 32000M DEFAULT STORAGE (INITIAL 256 NEXT 256K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0) ONLINE;
    Under normal circumstances, what he would do is to use our wizard tool and create an account and then import data from an export dump.
    But he wants to create a tablespace using a SQL something like:-
    CRETE TABLESPACE <tbl_name> datafile <path><datafile_name>.dbf SIZE 2000M AUTOEXTEND ON NEXT 500M MAXSIZE 32000M DEFAULT STORAGE (INITIAL 256 NEXT 256K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0) ONLINE;
    He thinks this should be ok because his export dump would be on size 2GB and would want to import all of that 'at once' i.e. without actually using autoextend feature for the first 2GB.
    Does this make any sense? Do you guys see any difference 'performance-wise' between the 2 create tablespace statements?
    I think the second sql (with size 2000M initially) seems to be a more logical approach but I am not really sure of the implications going down the line performance-wise.
    Any help/input much appreciated!
    Thanks guys

    1) Provide the facility in your tool to change the default size of datafiles and keep autoextend off.You won't believe it...we had this option in a previous version but now it isn't there anymore!
    But why turning off AUTOEXTEND? I mean, our customers are not meant to modify anything in the database other than via using our software, hence we would want our customers to just use the software as it is but have their DBAs monitor the growth of any datafiles etc...
    2) Let your tool do what it is doing and then manually increasing the size of the datafiles and making autoextend off once you have created the tablespace and before doing import. This can be done by your tool or loggin to the database.We could do this, but we don't want our customers to manually finger the database as they are/might not be Oracle-efficient and wouldn't want production systems to crash for the same reason.
    Hence we could just give them the SQL to be replaced with the 'default' one and then create a tablespace via the tool which would create a tablespace with an initial size of 2GB+ and with greater autoextend facility (such as autoextend on 500M) rather than 100M so that there are fewer autoextends.
    Also, in your point 2, are you saying to turn off autoextend only for the import and set it back on by alter tablespace....?
    Thank you.

  • Best size for previews

    What is the best size for standard previews when working with a 27 inch iMac? screen size 2560 by 1440
    Also would you go high quality preview or just low.
    Stepping back a little - here's my work flow
    Import
    Convert to DNG fast load previews
    render embedded and Sidecar
    applying a preset to auto set lens corrections
    assessing in library
    view / select - 1st run thru check images through larger thumbnails
    weed out - full screen / 100%zoomed in images
    Develop modeThis assessing is where things fall down, often the rendering takes 4-8 seconds, sometimes starting with a totally pixellated image.
    files and LR data are stored on firewire 800 RAID 5 external hard drive
    Lightroom 2 Catalog-2-2 Previews.lrdata
    Lightroom 2 Catalog-2-2.lrcat
    Lightroom 2 Catalog-2-2.lrcat-journal
    Lightroom 2 Catalog-2-2.lrcat.lock
    images
    cache is on iMac set at 50 Gb
    So - any thoughts on the below would be appreciated
    size for standard previews
    render - embed and sidecar or standard
    Thanks
    hamishNIVENPhotography

    Rob, you read the Help??
    For archived files 1:1 is completely unnecessary and you should have noticed, I have the space.
    Have you noticed that if you zoom in on an archived image with a standard preview a 1:1 is automatically generated, too easy!
    If you are wanting to recover from previews then you need to look at your back up strategies. Or just export full sized jpegs!!
    Rob Cole wrote:
    The points in having 1:1 previews for archived images are:
    * So you can zoom in if you want.
    * To maintain the potential for recovery.
    * So you don't have to bother computing an optimal size for standard preview, nor wonder if you computed it correctly or not, nor remember to recompute it when you buy a new monitor...
    Granted, if you don't have enough space, or you'd rather use the space for other things, then yes: standard preview size matters. But since I've never been faced with such constraint, I've never computed an optimal preview size. The general principal though is to save a preview that will fit nicely in the area you will be using to view it. So if I were to compute an optimum, I would:
    * Compute viewing area.
    * Figure out how willing Lightroom is to upsize an existing preview before rendering a larger version (if image is online), and how willing I am to view reduced quality upsampled image if Lightroom is willing to upsize some (or if image is offline).
    And from that one could derive the optimum size for standard preview on their system and workflow.
    UPDATE: From the Lightroom help file:
    Standard Preview Size
    Specifies the maximum pixel dimension for the rendered preview. Choose the size that accommodates the display you’re working with: select a standard preview size that is equal to or larger than the longest edge of your screen resolution. For example, if your screen resolution is 1920 x 1200 pixels, choose Standard Preview Size > 2048 Pixels. If your screen resolution exceeds 2048 pixels, Lightroom generates a 1:1 preview instead.
    Rob

Maybe you are looking for