Temporay tablespace grows rapidly. . .

Dear All,
When I run a large query the temporary tablespace grows continuously.
The max size of temporary tablespace is 6G.
I set Autoextend on, next size is 10m and maxsize is 6291456M.
Also I set the SORT_AREA_SIZE = 256m.
How to stop the rapid growth of temporary tablespace.
Thanks in advance,
PratHamesh.

If your Oracle version is 9i you can set your PGA_AGGREGATE_TARGET into a appropriate value(i.e. PGA_AGGREGATE_TARGET=1G to avoid sorting on TEMP tablespace.
Frequently sorting happens on your DB and it supposed to shrink.
You can also think of allocating other users to an specific TEMP tablespace but you have to identify which users it is.

Similar Messages

  • PSAPSID tablespace grows rapidly

    Hi All,
    We are having a BI7[SP11] system on oracle. All were normal operations till the 1 month past. This month, we have been observing that the PSAP<SID> tbspc has been growing rapidly very much. When checked with functionals no extra loads were used.
    Now I can monitor from DB02 on the tbspc by checking the history, when more delta occured, but I wanted to see which table, related to which data, all that delta happened, so that i can check with functionals.
    Is there anyway to still dig this and get the proof. Can any body please help..
    Thanks a lot
    VR.

    Hi Vera,
    I would recommend to you if you wish to see the table, via the table space name, in transaction DB02, and then relate that to the table in your BW system.
    I would use the following steps
    Monitor in DB02 and then get your table space name
    Under DB02 you should see under the "Space" drill down a option called "Tables and Indexes" double click on this option
    Hopefully your basis team would of Reorged the tables so you have the latest stats
    Hit continue then enter your table space name as selection criteria
    From here you can get the table space name,
    Take your table space name and enter this into the table SE16 RSTSODS you should be able to get the generic PSA name that is being wrote to
    Other wise if it is not in this table you should have a very good idea of what sort of data is being recorded by the naming convention.
    Thanks
    Ben
    **Please assign points if helpful**

  • APPS_TS_MEDIA tablespace growing rapidly

    Hi,
    The APPS_TS_MEDIA tablespace stores all the attached documents in Oracle Applications. But it is growing at a very rapid rate.
    Is there a way to delete the old attachments from this tablespace?
    When users raise a PO/PR, they attach the document along with the PR. But once the PR is closed, we no longer require those attachments.
    Could someone please let me know if there is any way of deleting those old files from APPS_TS_MEDIA tablespace?
    Thanks!

    OWNER     SEGMENT_NAME          SEGMENT_TYPE     SIZ
    APPLSYS     SYS_LOB0000057442C00004$$     LOBSEGMENT     53,561,262,080
    APPLSYS     FND_LOBS               TABLE          114,294,784
    APPLSYS     SYS_IL0000057442C00004$$     LOBINDEX     22,544,384
    APPLSYS     FND_LOBS_N1          INDEX          2,359,296
    APPLSYS     FND_LOBS_U1          INDEX          2,097,152
    CSF     CSF_MD_LYR_METADATA     TABLE          131,072
    CSF     CSF_MD_RD_SEGS          TABLE          131,072
    CSF     CSF_TDS_BINARY_TILES     TABLE          131,072
    CSF     CSF_TDS_SEGMENTS          TABLE          131,072
    CSF     SYS_IL0000060656C00011$$     LOBINDEX     131,072
    CSF     SYS_IL0000061938C00007$$     LOBINDEX     131,072
    CSF     SYS_IL0000061011C00013$$     LOBINDEX     131,072
    CSF     SYS_LOB0000060628C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060628C00011$$     LOBSEGMENT     131,072
    CSF     CSF_LF_ROADSEGMENTS     TABLE          131,072
    CSF     CSF_MD_RAIL_SEGS          TABLE          131,072
    CSF     SYS_IL0000060656C00010$$     LOBINDEX     131,072
    CSF     SYS_IL0000061068C00016$$     LOBINDEX     131,072
    CSF     SYS_IL0000061938C00008$$     LOBINDEX     131,072
    CSF     SYS_IL0000209418C00012$$     LOBINDEX     131,072
    CSF     SYS_IL0000060957C00013$$     LOBINDEX     131,072
    CSF     SYS_IL0000061112C00011$$     LOBINDEX     131,072
    CSF     SYS_IL0000060704C00011$$     LOBINDEX      131,072
    QP     QP_DOCUMENTS_U1          INDEX          131,072
    CSF     SYS_LOB0000060588C00018$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060869C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061979C00003$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000062083C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209422C00011$$     LOBSEGMENT     131,072
    CSF     CSF_LF_NAMES          TABLE          131,072
    CSF     CSF_LF_PLACE_NAMES          TABLE          131,072
    CSF     CSF_LF_POIS          TABLE          131,072
    CSF     CSF_LF_ROADSEGM_PLACES     TABLE          131,072
    CSF     CSF_MD_INST_STYLE_SHTS     TABLE          131,072
    CSF     CSF_MD_NAMES          TABLE          131,072
    CSF     CSF_TDS_ROADBLOCKS     TABLE          131,072
    CSF     CSF_MD_OM_ROADS          TABLE          131,072
    CSF     SYS_IL0000061938C00005$$     LOBINDEX      131,072
    CSF     SYS_IL0000061068C00017$$     LOBINDEX 131,072
    CSF     SYS_IL0000060588C00018$$     LOBINDEX      131,072
    FRM     SYS_IL0000285924C00004$$     LOBINDEX      131,072
    CSF     SYS_LOB0000060588C00017$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060656C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060656C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060704C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061068C00016$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061938C00005$$     LOBSEGMENT     131,072
    CSF     CSF_LF_PLACES          TABLE          131,072
    CSF     CSF_LF_POI_NAMES          TABLE          131,072
    CSF     CSF_LF_ROADSEGM_POSTS     TABLE          131,072
    CSF     CSF_MD_LAND_USES          TABLE          131,072
    CSF     CSF_MD_POI_NM_ASGNS     TABLE          131,072
    CSF     CSF_MD_THEME_METADATA     TABLE          131,072
    CSF     CSF_TDS_CONDITIONS     TABLE          131,072
    CSF     CSF_TDS_TILES          TABLE          131,072
    CSF     CSF_MD_OM_POIS          TABLE          131,072
    FRM     FRM_REPOSITORY_LOBS     TABLE          131,072
    CSF     SYS_IL0000060588C00017$$     LOBINDEX      131,072
    CSF     SYS_IL0000061979C00004$$     LOBINDEX      131,072
    CSF     SYS_IL0000062083C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000209418C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000209420C00012$$     LOBINDEX      131,072
    CSF     SYS_IL0000061112C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000060704C00012$$     LOBINDEX      131,072
    CSF     SYS_LOB0000060897C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061011C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061112C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061156C00028$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061938C00008$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000062261C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209418C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209422C00010$$     LOBSEGMENT     131,072
    CSF     CSF_LF_ROADSEGM_NAMES     TABLE          131,072
    CSF     CSF_MD_ADM_BOUNDS     TABLE          131,072
    CSF     CSF_MD_HYDROS          TABLE          131,072
    CSF     CSF_TDS_BINARY_MAPS     TABLE          131,072
    CSF     CSF_TDS_NODES          TABLE          131,072
    CSF     CSF_TDS_RDBLCK_INTVLS     TABLE          131,072
    CSF     SYS_IL0000062083C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000060628C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000061011C00012$$     LOBINDEX      131,072
    CSF     SYS_IL0000209422C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000060957C00012$$     LOBINDEX      131,072
    CSF     SYS_LOB0000060897C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060957C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060957C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061011C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061938C00007$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061979C00004$$     LOBSEGMENT     131,072
    QP     SYS_LOB0000296934C00002$$     LOBSEGMENT     131,072
    CSF     CSF_MD_LYR_STYLE_SHTS     TABLE          131,072
    CSF     CSF_TDS_COND_SEGS          TABLE          131,072
    CSF     CSF_TDS_INTERVALS          TABLE          131,072
    CSF     SYS_IL0000061979C00003$$     LOBINDEX      131,072
    CSF     SYS_IL0000060628C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000060869C00013$$     LOBINDEX      131,072
    CSF     SYS_IL0000061156C00028$$     LOBINDEX      131,072
    CSF     SYS_IL0000061156C00029$$     LOBINDEX      131,072
    CSF     SYS_IL0000209424C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000209420C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000060897C00012$$     LOBINDEX      131,072
    CSF     SYS_IL0000060897C00013$$     LOBINDEX      131,072
    CSF     SYS_IL0000062261C00014$$     LOBINDEX      131,072
    CSF     SYS_LOB0000061938C00006$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209424C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209424C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209420C00012$$     LOBSEGMENT     131,072
    FRM     SYS_LOB0000285924C00004$$     LOBSEGMENT     131,072
    CSF     CSF_MD_POIS          TABLE          131,072
    CSF     CSF_MD_RDSEG_NM_ASGNS     TABLE          131,072
    CSF     CSF_MD_OM_HYDROS          TABLE          131,072
    CSF     SYS_IL0000061938C00006$$     LOBINDEX     131,072
    CSF     SYS_IL0000060869C00012$$     LOBINDEX     131,072
    CSF     SYS_IL0000062261C00013$$     LOBINDEX     131,072
    FRM     FRM_REPOSITORY_LOBS_N1     INDEX          131,072
    QP     SYS_IL0000296934C00002$$     LOBINDEX     131,072
    CSF     SYS_LOB0000060704C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060869C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061068C00017$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061112C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061156C00029$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209418C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209420C00011$$     LOBSEGMENT     131,072
    CSF     CSF_LF_PLACE_POSTCS     TABLE          131,072
    CSF     CSF_LF_POSTCODES          TABLE          131,072
    CSF     CSF_TDS_RDBLCK_SGMNTS     TABLE          131,072
    CSF     CSF_TDS_SEGM_NODES     TABLE          131,072
    CSF     CSF_MD_OM_ADMINS          TABLE          131,072
    QP     QP_DOCUMENTS          TABLE          131,072
    CSF     SYS_IL0000209424C00010$$     LOBINDEX     131,072
    CSF     SYS_IL0000209422C00011$$     LOBINDEX     131,072
    FRM     FRM_REPOSITORY_LOBS_UK1     INDEX          131,072
    CSF     SYS_LOB0000062083C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000062261C00014$$     LOBSEGMENT     131,072
    I looked into thoe MOS, but nothing seems to help!
    I have raised a TAR with Oracle and they say, this functionality of deleting attachment doesnt exist and they are finding a solution for it.
    Thanks!

  • Temporary Tablespace growing Rapidly

    Hi
    My temporary tablespace is getting too large,now it is about 19GB,
    How can i mange it?How can i decrease it's size?
    Thank You In Advance

    Select from v$session & v$sort_usage to find out who is using the space. If no one is using the space currently the you can rebuild.
    for example:-
    CREATE
    TEMPORARY TABLESPACE "TMP" TEMPFILE
    'C:\oradata\TMP1.dbf' SIZE 2000M REUSE
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 131072K;
    ALTER DATABASE DEFAULT TEMPORARY TABLESPACE "TMP";
    Then drop TEMP including datafiles.
    If the name is needed you could then create a TEMP tablespace and return to the original name. The key to all of this is being able to monitor who is using TEMP space and why.
    N.B. I like setting a large uniform size to ensure most TEMP requests get the space in one hit per segment.

  • SYSAUX Growing Rapidly

    Hi,
    When i configured IC mode the SYSAUX Growing Rapidly.
    Please let me know what happens.
    Thank

    Hello,
    Seems like the log mining server has grow this tables due any reason. May be the execution of a large transacction, a massive UPDATE, DELETE or INSERT.
    Once these tables have grown, no free space.
    Would have to test whether making a shutdown / startup instance these tables are truncated. Since the information they hold, I think, would only be necessary for the Log Miner session.
    Which is the result of this queries:
    SELECT COUNT(*) FROM SYSTEM.LOGMNRC_GTCS  ;
    SELECT COUNT(*) FROM SYSTEM.LOGMNR_COL$ ;
    You can confirm that there is no transaction in the database for long term? You can look at the view v $ TRANSACTION, has a column that specifies the date and time when a transaction began.
    From MOS:
    There is no official way to reclaim the space but as a workaround you can use the DBMS_LOGMNR_D.SET_TABLESPACE routine to recreate all LogMiner tables in an alternate tablespace. For example, the following statement will recreate all LogMiner tables to use the LOGMNRTS tablespace:
    From MOS.
    How to Reclaim Space Used by LogMiner Tables (Doc ID 456814.1)
    SQL> connect / as sysdba
    SQL> EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE ('LOGMINER_DATA');
    However this command requiere stop GG capture process.
    This procedure move the Logminer tables to the tablespace indicated, then, in the move operation the space is compacted.
    May be a good practice using GG IC is to define a dedicated tablespace to Logminer.
    I hope help.
    Regards
    Arturo

  • PSAPUNDO Table space growing rapidly

    Hello
    The tablespace PSAPUNDO is growing rapidly on one of client server how to .
    PSAPUNDO     1,736.13     151.2
    PSAPUNDO     441.125     42.6
    PSAPUNDO     183.125     15
    PSAPUNDO     142.125     12.6
    PSAPUNDO     81.125     5.9
    PSAPUNDO     74.125     3.3
    PSAPUNDO     44.125     1.9
    PSAPUNDO     35.125     1.7
    PSAPUNDO     39.125     0.3
    PSAPUNDO     20.125     0.3
    this growth in six days...? can any one help me as im new to sap

    letzfriend wrote:
    Hello
    >
    > The tablespace PSAPUNDO is growing rapidly on one of client server how to .
    >
    > PSAPUNDO     1,736.13     151.2
    > PSAPUNDO     441.125     42.6
    > PSAPUNDO     183.125     15
    > PSAPUNDO     142.125     12.6
    > PSAPUNDO     81.125     5.9
    > PSAPUNDO     74.125     3.3
    > PSAPUNDO     44.125     1.9
    > PSAPUNDO     35.125     1.7
    > PSAPUNDO     39.125     0.3
    > PSAPUNDO     20.125     0.3
    >
    >
    > this growth in six days...? can any one help me as im new to sap
    Hi,
    Did you check the note 1035137 - Oracle Database 10g: Automatic Undo Retention?
    Best regards,
    Orkun Gedik

  • WF_ITEM_ACTIVITY_STATUSES_H table is growing rapidly in PROD.

    Hi,
    We are noticing one of the table WF_ITEM_ACTIVITY_STATUSES_H size was 6 GB on 20-APR-11. Today it is at 25 GB (in 1 month) with 356 million rows and growing rapidly! any idea.
    Thanks
    Rao

    I have one question for you. How to purge the workflow date where item_type(OEOH,OEOL) specific only. I would really appreciate if you can guide us in the right direction this issue is becoming more and more critical to the business and also it's degrading the whole back groung process too.
    Righ now in prod we are running the "Purge Obsolete Workflow Runtime Data" 21 days Temporary:Y:500:N. i checked the count fro OEOL and OEOH by using below query
    select item_type, count(*)
    from WF_ITEM_ACTIVITY_STATUSES_H group by item_type
    OEOL14982271 14 Million
    OEOH504495652 510 Million
    select count(*) from WF_ITEM_ACTIVITY_STATUSES_H;
    519793016 519 million
    Thanks
    Ganga

  • Undo tablespace grows fast

    How the undo tablespace grows very fast., how can we control on it. When I try to resize it did not allow me, what exact action can i take it.

    >> How the undo tablespace grows very fast., how can we control on it.
    It’s all depending on the DML transaction activities on your database i.e. frequent inserts,updates, and deletes.
    >> When I try to resize it did not allow me, what exact action can i take it.
    How/What you tried to resize it. Can you show the details??
    Moreover, Do take a look at the Oracle Documentation on "Managing the Undo Tablespace"
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm
    Regards,
    Sabdar Syed.
    Added the link.
    Message was edited by:
    Sabdar Syed

  • SYSAUX tablespace grow too quick????

    We have EBS R12.1 on LINUX system. Recently I found our development EBS database SYSAUX tablespace grow very quick. The SYSAUX tablespace has two data files and each data files size is 6GB (total 12 GB). In one month all 12 GB space are gone.
    My questions are:
    1. what objects or reports or ??? take this much space?
    2. how to delete un-need space?
    3. what is reasonable SYSAUX size?
    Thanks.

    I double check SYSAUX space usage and found it only use less than 100MB. Why SYSAUX show all 12 Gb space are gone?
    SQL> l
    1 SELECT occupant_name, schema_name, move_procedure,
    2 space_usage_kbytes
    3 FROM v$sysaux_occupants
    4* ORDER BY 1
    SQL> /
    OCCUPANT_NAME SCHEMA_NAME MOVE_PROCEDURE SPACE_USAGE_KBYTES
    AO SYS DBMS_AW.MOVE_AWMETA 45888
    AUTO_TASK SYS 320
    EM SYSMAN emd_maintenance.move_em_tblspc 0
    EM_MONITORING_USER DBSNMP 0
    EXPRESSION_FILTER EXFSYS 0
    JOB_SCHEDULER SYS 1152
    LOGMNR SYSTEM SYS.DBMS_LOGMNR_D.SET_TABLESPACE 13376
    LOGSTDBY SYSTEM SYS.DBMS_LOGSTDBY.SET_TABLESPACE 1600
    ORDIM ORDSYS 0
    ORDIM/PLUGINS ORDPLUGINS 0
    ORDIM/SQLMM SI_INFORMTN_SCHEMA 0
    PL/SCOPE SYS 640
    SDO MDSYS MDSYS.MOVE_SDO 0
    SM/ADVISOR SYS 198528
    SM/AWR SYS 1006144
    SM/OPTSTAT SYS 10866560
    SM/OTHER SYS 8192
    SMON_SCN_TIME SYS 3328
    SQL_MANAGEMENT_BASE SYS 1728
    STATSPACK PERFSTAT 0
    STREAMS SYS 1216
    TEXT CTXSYS DRI_MOVE_CTXSYS 0
    TSM TSMSYS 256
    ULTRASEARCH WKSYS MOVE_WK 0
    ULTRASEARCH_DEMO_USE WK_TEST MOVE_WK 0
    R
    WM WMSYS DBMS_WM.move_proc 0
    XDB XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE 56192
    XSAMD OLAPSYS DBMS_AMD.Move_OLAP_Catalog 0
    XSOQHIST SYS DBMS_XSOQ.OlapiMoveProc 45888
    29 rows selected.

  • Undo tablespace growing fast

    Hello All
    We are having issues with undo tablespace growing... the oracle version is 10.2.0.1.0
    the table is holding around 400000000 records and this table is also partitioned by range
    any reason for this undo tablespace growing by at an high rate
    regards
    Kedar

    Undo tablespaces are special tablespaces used solely for storing undo information. You cannot create any other segment types (for example, tables or indexes) in undo tablespaces. Each database contains zero or more undo tablespaces. In automatic undo management mode, each Oracle instance is assigned one (and only one) undo tablespace. Undo data is managed within an undo tablespace using undo segments that are automatically created and maintained by Oracle.
    Every Oracle Database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. These records are collectively referred to as undo.
    Undo records are used to:
    Roll back transactions when a ROLLBACK statement is issued
    Recover the database
    Provide read consistency
    Analyze data as of an earlier point in time by using Oracle Flashback Query
    Recover from logical corruptions using Oracle Flashback features
    When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.
    You confuse TEMP with UNDO tablespace.
    Best Regards,
    Francisco Munoz Alvarez
    www.oraclenz.com

  • EBS Database R12.1 temporary tablespace grow too quick??

    we have a EBS R12.1 database on Redhat LINUX server. Recently this database every day Temporary tablespace grow at least 1 GB. This database temporary tablespace (with two temp files) has been grow to 45 GB.
    Does anyone know what wrong?
    How to fix problem?

    I eventually figure out this temporary tablespace grow is cause by OEM.
    SQL statement is:
    /* OracleOEM */ SELECT end_time, status, session_key, session_recid, session_stamp, command_id, start_time, time_taken_
    display, input_type, output_device_type, input_bytes_display, output_bytes_display, output_bytes_per_sec_display
    FROM (SELECT end_time, status, session_key, session_recid, session_stamp, command_id, start_time,
    time_taken_display, input_type, output_device_type, input_bytes_display, output_bytes_di
    splay, output_bytes_per_sec_display FROM v$rman_backup_job_details ORDER BY end_time DESC) WHERE rownum
    = 1;
    ANyone know why this statement will take 30GB temporary space on EBS R12.1?
    Thanks.

  • Temp tablespace grow too big???

    we have EBS R12.1 on LINUX X86_64 with ORACLE database version 11.1.0.7. every week we have temporary tablespace grow too big (> 32 GB) and out of extent.
    Based on our research some some sql statement or report cause this issue. if we 'analyze stratistics", most time problem can fix. It cause us some time need run "analyze statistics" several times in one day.
    Does anyone have solution for this?
    Thanks.

    Please see if these docs help.
    Temporary Segments: What Happens When a Sort Occurs [ID 102339.1]
    Queries to monitor Temporary Tablespace usage [ID 289894.1]
    How Can Temporary Segment Usage Be Monitored Over Time? [ID 364417.1]
    Thanks,
    Hussein

  • Reporting Database growing rapidly

    Hello,
    Is it normal for the reporting database in SSRS to grow so rapidly? I created a new database 2 days ago, and already it has gone from 300 megabytes the first day to 3gb today. Usually, in a matter of 4-5 months, it grows to 30+ gb.
    Is it normal for it to do this? Once it get's too large it starts to slow the nightly refresh of content down and causes it to take much longer. Also, it seems that when it gets large like that, there are noticeable bottlenecks on the SQL box.
    If this is normal, is the solution just to create a new reporting database once in a while? Shrink it? What? I looked online and didn't see much info addressing this topic.

    It all depends on the number of transactions is carried over the database. If space is going to be constraint
    then take a log backup and shrink the log file.
    Refer the below article
    http://technet.microsoft.com/en-us/library/ms178037(v=sql.105).aspx
    -Prashanth

  • Tablespace growing too large

    Good morning gurus,
    Sorry if I sound novice at some point .
    I have this table space vending of size 188,598.6MB.It keeps on growing.I have to give it extra space every week and all is consumed.It is a permanent table space with extent management local and segment space management auto.This table space is the backbone of the database which is 250G.We are currently running oracle 10.2.0.4 on windows.
    Please help
    Regards
    Deepika

    Hi..
    Please do mention the database version and the OS.
    You need to know what are the objects, object_types on such a big tablespace.Which schemas use it waht do they do.Do they do any kind of DIRECT Loading in the database.Are all the tables and the indexes on the same tablespace.What i feel is, you are having all the tables and the indexes on the same tablespace.I would recommend 2 things:--
    1. Do the data purging.Talk to the considered applications team,or who so ever is the concerned person, and the decide data retention period in the database and move the rest of the data to some other database as history.
    2. Keep different tablespaces for the tables and indexes.
    HTH
    Anand

  • Undo tablespace growing without reusing space

    Hi,
    I'm running an Oracle9i database on Solaris. I am using the automatic undo management and I have one undo tablespace. The UNDO_RETENTION value is 900. I have created the undo tablespace this way (clause in create database statement):
    UNDO TABLESPACE "UNDOTBS1" DATAFILE '/u04/oracle/oradata/my_dbname/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
    The undo tablespace datafile is now close to 3G. I have other servers running the same setup, and their undo datafile size is still 200M. There is currently no active transaction in the database. Any idea why this is happening? Is there any tables I can check for clues?
    Many thanks,
    Gloria

    Should Oracle automatically shrink the undo tablespace (datafile) when it is not needed anymore? Say at one point the database really needs 3G of undo tablespace, but afterwards only 10M is needed, would the datafile be 'shrunk' back?
    Also, how can I check if the database really needed the 3G of undo tablespace at one point? (I guess it's checking the level of activities in the database, but how do I do that for past data?)
    I'm trying to decide whether the undo tablespace really grew due to a need at some point or is it a case of Bug 2660394 (documented in metalink note271119.1). The bug basically says that "An auto extensible undo tablespace MAY grow before reusing expired extents leading to more space use than actually needed".

Maybe you are looking for