Never release the temp space

It seems my oracle database never release temp space.
The usage of temp space kept at 99.8% ,but there was no alarm in alert.log.
It is not acceptable to shutdown the machine (7*24).
It is said that oracle do not use temp space if the memory for sorting can hold processing statement.
But there is no large work load on the machine and whenever
select * from v$sort_usage
no record
what s wrong?
how can i release temp space without shutting down the server?
Sun fire v880 4 cpu at 1050Mhz Memory 8G
Solaris 8 0202
Oracle 92

You do not need to worry about it, unless you are getting "Unable to allocate ... in table TEMP" messages.
I believe that the space will be released if you bounce the database.
The 99% you are seeing is like a high water mark, which says that at some point 99% of your TEMP space was used. However no rows in v$sort_usage means that no space is currently being used.
So, relax!

Similar Messages

I was charged to increase my icloud storage, but never received the new space

I recieved a message on my I-phone that I needed more storage for the cloud. I went into the cloud on my phone and purchased the 10Gb a year. I was charged the $20.00 for it, but didn't get the storage. Is there something else that I need to do?
Thanks,
Christine

I have a similar issue, though it's only been less than a day since the issue cropped up. I received notice that this was an issue through an email from Apple falsely stating that I had downgraded to a free (5 GB) account, when in fact I had already been charged $20.00 for the 15 GB plan. All this and more is explained in a question thread I started about half an hour ago or so.
So far, no replies in my question thread....

Oracle.sql.BLOB.freeTemporary() is not freeing TEMP space in the database

Hi Folks,
We are using oracle.sql.BLOB to store some file information into the database.
Allocation of the temp space is done as below
BLOB blob=BLOB.createTemporary(conn, false, BLOB.DURATION_SESSION); // this results in the usage of TEMP space from database
And subsequent release is done as below
blob.freeTemporary(); // this should have release the space from the database.
This is on Oracle 10g, Java 1.6, ojdbc6.jar There are no exceptions. Even a simple program results in the same.
Anybody faced something similar? Any pointers would be really appreciated.
Thanks,
Deva
Edited by: user10728663 on Oct 11, 2011 5:33 AM

Thanks a lot for the information.
Memory is fine. And I am able to reproduce this within the scope of a simple example as well.
Would you have any reference to the thread which had earlier reported this as a bug. I tried a reasonable amount of search in the forum, but no success.
Thanks very much for any pointers.

When is temp space freed

I have a problem between 2 executions of my application. The sequence is:
Stop application.
Start the 2nd run.
One second into the 2nd run, I get a TEMP space full error. When is temp space freed?
Thanks

Yes, that's essentially correct. Note that there are different uses of space within Temp. Many uses are transaction, cursor or connection specific (locks, sort space, materialised results etc.) and are freed when the associated transaction/cursor/connection is closed. Some uses (prepared command cache) are not connection specific and will not be freed until the datastore is unloaded from memory (though there are limits on how large the prepared command cache can grow so it should never result in Temp space exhaustion).
If you suspect that Temp space is not being freed when it should be then you should log an SR so that support can investigate in case there is some obscure bug at work.
Regards,
Chris

Problem with temp space allocation in parallel query

Hello
I've got a query which matches two large result sets (25m+ rows) against each other and does some basic filtering and aggregation. When I run this query in serial it takes about 30 mins and completes successfully. When I specify a parallel degree of 4 for each result set, it also completes successfully in about 20 minutes. However, when I specify that it should be run in parallel but don't specify a degree for each result set, it spawns 10 parallel servers and after a couple of minutes, bombs out from one of the parallel servers with:
ORA-12801: error signaled in parallel query server P000
ORA-01652: unable to extend temp segment by 64 in tablespace TEMPThis appears to be when it is about to perform a large hash join. The execution plan does not change whether the parallel degree is specified or not, and there is several GB of temp space available.
I'm at a bit of a loss as to how to track down specifically what is causing this problem. I've looked at v$sesstat for all of the sessions involved and it hasn't really turned anything up. I've tried tracing the main session and that hasn't really turned up much either. From what I can tell, one of the sessions seems to try to allocate massive amounts of temp space that it just does not need, but I can figure out why.
Any ideas of how to approach finding the cause of the problem?
David

Hello
I've finally resolved this and the resolution was relatively simple - and was also the main thing that Mark Rittman said he did in his article: reduce the size of the hash join.
After querying v$sql_workarea_active I could see what was happening which was that the sum of the temp space for all of the parallel slaves was exceeding the total amount of temp space available on the system. When run in serial, it was virtually at the limit. I guess the extra was just the overhead for each slave maintaining it's own hash table.
I also made the mistake of misreading the exectuion plan - assuming that the data being pushed to the hash join was filtered to eliminate the data that was not of interest. Upon reflection, this was a rather stupid assumption on my part. Anyway, I used sub query factoring with the materialize hint to ensure that the hash join was only working on the data it should have been. This significantly reduced the size of the hash table and therefore the amount of temp space required.
I did speak to oracle support and they suggested using pga_aggregate_target rather than the separate *area_size parameters. I found that this had very little impact as the problem was related to the volume of data rather than whether it was being processed in memory or not. That said, I did try upping the hash_area_size for the session with some initial success, but ultimately it didn't prove to be scalable. We are however now using pga_aggregate_target in prod.
So that's that. Problem sorted. And as the title of Mark Rittman's article suggests, I was trying to be too clever! :-)
HTH
David

SQL query using lot of Temp space

I have sql query which is using lot of temp space , please suggest some ways to reduce this
SELECT A.POSITION_NBR, TO_CHAR(B.EFFDT,'YYYY-MM-DD'), rtrim( A.SEQNO), A.EMPLID, B.REG_REGION, A.MANAGER_ID, A.REPORTS_TO, case when A.POSITION_NBR = A.REPORTS_TO THEN 'POS reports to same position' else 'Positions with multiple Emp' End Case
FROM PS_Z_RPTTO_TBL A, PS_POSITION_DATA B, PS_POSTN_SRCH_QRY B1
WHERE B.POSITION_NBR = B1.POSITION_NBR AND B1.OPRID = 'MP9621Q' AND ( A.POSITION_NBR = B.POSITION_NBR AND ( A.REPORTS_TO = A.POSITION_NBR AND B.EFFDT =
(SELECT MAX(B_ED.EFFDT)
FROM PS_POSITION_DATA B_ED
WHERE B.POSITION_NBR = B_ED.POSITION_NBR) AND A.POSITION_NBR <> '00203392') OR ( B.EFFDT =
(SELECT MAX(B_ED.EFFDT)
FROM PS_POSITION_DATA B_ED
WHERE B.POSITION_NBR = B_ED.POSITION_NBR AND B_ED.EFFDT <= SYSDATE) AND B.MAX_HEAD_COUNT <>
(SELECT Count( C.EMPLID)
FROM PS_Z_RPTTO_TBL C)) ) UNION
SELECT F.POSITION_NBR, TO_CHAR(F.EFFDT,'YYYY-MM-DD'), '', '', F.REG_REGION, '', F.REPORTS_TO, ''
FROM PS_POSITION_DATA F, PS_POSTN_SRCH_QRY F1
WHERE F.POSITION_NBR = F1.POSITION_NBR AND F1.OPRID = 'MP9621Q' AND ( F.EFFDT =
(SELECT MAX(F_ED.EFFDT)
FROM PS_POSITION_DATA F_ED
WHERE F.POSITION_NBR = F_ED.POSITION_NBR AND F_ED.EFFDT <= SYSDATE) AND F.EFF_STATUS = 'A' AND F.DEPTID IN
(SELECT G.DEPTID
FROM PS_DEPT_TBL G
WHERE G.EFFDT =
(SELECT MAX(G_ED.EFFDT)
FROM PS_DEPT_TBL G_ED
WHERE G.SETID = G_ED.SETID AND G.DEPTID = G_ED.DEPTID AND G_ED.EFFDT <= SYSDATE) AND F.REG_REGION = G.SETID AND G.EFF_STATUS = 'I') )
Thanks in Advance
Rajan

use {noformat}<your code here>{noformat} tags to format your code.
I have sql query which is using lot of temp space , please suggest some ways to reduce thisIf your sort_area_size is not set sufficient oracle used temp space for sorting operation. As your code is not readable i cant say much more than this. Check with your DBA if you have to increase the temp space.

How do I reclaim the unused space after a huge data delete- very urgent

Hello all,
How do I reclaim the unused space after a huge data delete?
alter table "ODB"."BLOB_TABLE" shrink space; This couldn't execute with ora 10662 error. Could you please help

'Shrink space' has requirements:
shrink_clause
The shrink clause lets you manually shrink space in a table, index-organized table or its overflow segment, index, partition, subpartition, LOB segment, materialized view, or materialized view log. This clause is valid only for segments in tablespaces with automatic segment management. By default, Oracle Database compacts the segment, adjusts the high water mark, and releases the recuperated space immediately.
Compacting the segment requires row movement. Therefore, you must enable row movement for the object you want to shrink before specifying this clause. Further, if your application has any rowid-based triggers, you should disable them before issuing this clause.
Werner

Temp Space Issue

Hi there folks.
I've been using this forum as a reference point for the last couple of months but this is the first time I've had to post anything because I happen to have a pickle of an issue. In fact, it's that beefy, even my company's development team is stumped... Yeah.
So, a quick bit of background. The current client I'm working for is a Government agency related to Health & Public Services. The database we use works as a go-between with Siebel CAM and Business Objects. As the two don't naturally speak to each other, occasionally we get inevitible data incosistencies. We had an Informatica CDC issue a little while ago which left a lot of stale data, primarily relating to tasks which should have been closed or naturally expired. To clear up the backlog and return consistency to the DB, we've been working on updating a workflow which will refresh the tasks across the entire DB and bring everything in line.
Now, when the DB was designed, Task_Refresh was created and worked when tested as the DB was getting loaded with data. The problem is, when it was tested initially, there was only a few hundred thousand records to filter through. Now that the DB is in full swing, there's 22 million records and we're encountering issues. Essentially when we run the workflow in Informatica, it gets as far as the Source Qualifier and fails, having chewed through the available 16gb of temp space in the space of an hour.
I've been working for weeks trying to tune the SQL code for the source qualifier and, along with the development team, I'm now well and truly stuck. Here is the query:
SELECT
    a.1,
    a.2,
    a.3,
    a.4,
    a.5,
    a.6,
    a.7,
    a.8,
    a.9,
    a.10,
    a.11,
    a.12,
    a.13,
    a.14,
    a.15,
    a.16,
    a.17,
    a.18,
    a.19,
    a.20,
    a.21,
    a.22,
    a.23,
    a.24,
    a.25,
    a.26,
    a.27,
    c.1,
    c.2,
    c.3,
    c.4,
    c.5,
    b.1,
    f.1,
    e.1,
    f.2,
    f.3,
    f.4,
    f.5,
    f.6,
    f.7,
    f.8,
    f.9,
    f.10,
    f.11,
    f.12
    FROM PARENT_TABLE a, CHILD_TABLE2 c, CHILD_TABLE1 b, PARENT_TABLE2 e, PARENT_TABLE3 f
    WHERE   a.1 = b.PAR_ROW_ID(+)
    AND     a.1 = c.PAR_ROW_ID(+)
    AND     a.1 = e.PAR_ROW_ID(+)
    AND     a.TARGET_PER_ID = f.ROW_ID(+)
    AND
    (a.LAST_UPD < TO_DATE('9/30/2011 00:00:00','mm/dd/yyyy hh24:mi:ss')
    AND a.LAST_UPD >= TO_DATE('9/23/2011 00:00:01','mm/dd/yyyy hh24:mi:ss'))
    or
    (c.LAST_UPD < TO_DATE('9/30/2011 00:00:00','mm/dd/yyyy hh24:mi:ss')
    AND c.LAST_UPD >= TO_DATE('9/23/2011 00:00:01','mm/dd/yyyy hh24:mi:ss'))
    or
    (b.LAST_UPD < TO_DATE('9/30/2011 00:00:00','mm/dd/yyyy hh24:mi:ss')
    AND b.LAST_UPD >= TO_DATE('9/23/2011 00:00:01','mm/dd/yyyy hh24:mi:ss'))
    or
    (e.LAST_UPD < TO_DATE('9/30/2011 00:00:00','mm/dd/yyyy hh24:mi:ss')
    AND e.LAST_UPD >= TO_DATE('9/23/2011 00:00:01','mm/dd/yyyy hh24:mi:ss'))
   );We are running this on 10g 10.1.0.5.0 - 64bi
So, obviously I've replaced the table names and most of the column names, but a.1 is the primary key. What we have is the primary key compared to the PAR_ROW_ID column in each of the child tables and one of the other main tables, looking for matching IDs down the whole of the PARENT_TABLE. In this database, tasks can be entered in any of the five tables mentioned for various different reasons and functions. The dates in the last section are just arbitrary dates we have been working with, when the query works and is running into production, the dates will change, a week at a time based on a parameter file in Informatica.
In troubleshooting, we found if we remove the left outer joins in the WHERE clause, then the query will return data, but not the right amount of data. Basically, PARENT_TABLE is just too massive for the temp space we have available. We can't increase the temp space and we can't get rid of the joins because that changes the functionality significantly. We have also tried restructuring the query by filtering on the dates first but that doesn't help, though I suspect that the order of the WHERE clause is being ignored by Oracle due to it's own performance related decisions. I have tried restructuring the query into 5 smaller queries and using Unions to tie it all together at the end, but still nothing.
We have even tried setting the date and time for an hour's worth of entries and that was still too big.
I'm stuck in a catch 22 here because we need to get this working, but the client is adamant that we should not be changing the functionailty. Is there any possible solution any of you can see for this?
Thank you in advance for any help you can offer on this.
(also, we are providiing support for the applications the database uses [CAM, BO], so we don't actually run this db per se, the client does. We've asked them to increase the temp space and they wont.
The error when we run the workflow is: ORA-01652: unable to extend temp segment by 128 in tablespace BATCH_TEMP)

938041 wrote:
I have tried restructuring the query into 5 smaller queries and using Unions to tie it all together at the end, but still nothing.
Technilcally you should be able to rewrite this query as a UNION ALL of 4 separate parts, providing you remember to include a predicate in the 2nd, 3rd and 4th query blocks that eliminate rows that have already been reported by the earlier query blocks.
Each part will be driven by one of the four range based predicates you have - and for the three parts that drive off child tables the join to the parent should NOT be an outer join.
Effectively you are trying to transform the query manually using the CONCATENATION operator. It's possibly (but I suspect very unlikely) that the optimizer will do this for you if you add the hint /*+ use_concat */ to the query you currently have.
Regards
Jonathan Lewis

How much TEMP space needed for datapump import?

How does one accurately predict how much TEMP table-space is needed prior to starting a data-pump import (via impdp)? I need a way to predetermine this BEFORE starting the import. It is my understanding that in data-pump imports, temp table-spaces are primarily used for the building of indexes among other operations.

Yes, I could use autoextend but that just shifts the problem of checking the logical table-space size to checking the physical space to see that it has enough room to extend.
I was really hoping for a formula to calculate the amount of TEMP space it would take up. For example, RichardHarrison's post above about setting the TEMP table-space size to be twice as large as the largest index, but wasn't sure on the accuracy of that statement. I was hoping someone has encountered this kind of scenario before and found an accurate way to predict how much space is really needed, or a good estimate to go by.
I will try out the idea of setting the TEMP space size to be twice the size of the largest index and see how that goes, as it doesn't seem there is a practical way of accurately determining how much space it really needs.
Thanks everyone.
Ben.

About The TEMP Tableplace

I create only one temp tablespace which is 100M . It is engrossed only 0.08% at the begin.When I exec a SQL (Select a big table ) ,the TEMP tableplace is engrossed 99.8%.When I exit my client which exec the 'big' SQL ,the state is remain as before .When I exec the 'big' SQL again ,the TEMP tablespace increase to 203M and is engrossed 99.8%(of 203M ). When I exit my client which exec the 'big' SQL ,the state is remain as before .How to release the TEMP tablespace ?Thanks !!
If you have any answer ,please EMAIL to : vipgsp@sina. com

Good suggeestions above.
I'd just add that the tablespace doesn't have to be locally managed to have the segments marked free and left available for reuse. That is a function of declaring the tablespace as a type of "TEMPORARY". When you do this, once segments are allocated, they are, as noted, marked free when no longer in use. They are intentionally NOT deallocated. This avoids having to incur the overhead of deallocating and some time later, reallocating the segments (reduces the overhead). Using locally managed is a good idea since it avoids the overhead associated with updating the data dictionary when the segments are initially allocated.
Deallocation only takes place upon shutdown/startup of the database.

HT1687 Got a replacement phone, says I have to enter a voicemail password though I never had one. I got the temp one and now it says "to retrieve VM enter password and message" where do I do that?

Got a replacement phone, says I have to enter a voicemail password though I never had one. I got the temp one and now it says "to retrieve VM enter password and message" where do I do that?

http://support.apple.com/kb/ht1687

A download, iPhoto, Version 9.4.2, released November 2012; has been on my download page for three weeks. Despite a half dozen attempts to install it, it has never completed the download. Near the end it always says an error has occurred. What can I do?

A download, iPhoto, Version 9.4.2, released November 2012; has been on my download page for three weeks. Despite a half dozen attempts to install it, it has never completed the download. Near the end it always says an error has occurred. What can I do? The unit onto/into which I am attempting to install this is a new MacBook Air.
thank you.
Otto

Thanks LN.
I tried. It would not download. A drop down notice said an error had occurred and to return to the purchase page; which I have done on numerous occasions. (What I am to do on the purchase page I am not sure, other than to click on purchases and see that the same iPhoto download is available. By the way, this was not purchased. It just showed up with two other items free items, which did download nicely.)
Otto

Release the space from Tools tablespace

Hi,
I have found that TOOLS tablespace is 99%.
The tools tablespace is typically used for collecting database statistics – not part of the application. These include Quest and Perfstat. How can I check at the objects in the tools tablespace to see what has grown and then determine if we need to purge data and reorg the objects.
The mount point for this database is only 8 gig and is 84% used so we should not add “overhead” space unless absolutely necessary. The tools tablespace is already large for the size of the rest of the database.
/dev/orabwelv 8388608 7011424 1377184 84% /ORACLE/BWEBPRD
These are the contents in the tablespace
OWNER TABLE_NAME OBJECT_TYPE TABLESPACE_NAME
ORACLE PLAN_TABLE TABLE TOOLS
ORACLE_APP STPL_DBAPRVS_PENDINGL TABLE TOOLS
ORACLE_APP STPL_DBAPRVS_ACTIVITY_LOGL TABLE TOOLS
ORACLE T_WEBBPRD TABLE TOOLS
POSTD PLAN_TABLE TABLE TOOLS
MONITORER TABLESPACE_GROWTH TABLE TOOLS
MONITORER SEGMENT_GROWTH TABLE TOOLS
OWNER TABLE_NAME OBJECT_TYPE TABLESPACE_NAME
PERFSTAT STATS$PGA_TARGET_ADVICE TABLE TOOLS
PERFSTAT STATS$SQL_WORKAREA_HISTOGRAM TABLE TOOLS
PERFSTAT STATS$SHARED_POOL_ADVICE TABLE TOOLS
PERFSTAT STATS$STATSPACK_PARAMETER TABLE TOOLS
PERFSTAT STATS$INSTANCE_RECOVERY TABLE TOOLS
PERFSTAT STATS$PARAMETER TABLE TOOLS
PERFSTAT STATS$IDLE_EVENT TABLE TOOLS
PERFSTAT STATS$PGASTAT TABLE TOOLS
PERFSTAT STATS$SEG_STAT_OBJ TABLE TOOLS
PERFSTAT STATS$SEG_STAT TABLE TOOLS
PERFSTAT STATS$SQL_PLAN TABLE TOOLS
OWNER TABLE_NAME OBJECT_TYPE TABLESPACE_NAME
PERFSTAT STATS$SQL_PLAN_USAGE TABLE TOOLS
PERFSTAT STATS$UNDOSTAT TABLE TOOLS
PERFSTAT STATS$DLM_MISC TABLE TOOLS
PERFSTAT STATS$RESOURCE_LIMIT TABLE TOOLS
PERFSTAT STATS$SQL_STATISTICS TABLE TOOLS
PERFSTAT STATS$SQLTEXT TABLE TOOLS
PERFSTAT STATS$SQL_SUMMARY TABLE TOOLS
PERFSTAT STATS$ENQUEUE_STAT TABLE TOOLS
PERFSTAT STATS$WAITSTAT TABLE TOOLS
PERFSTAT STATS$BG_EVENT_SUMMARY TABLE TOOLS
PERFSTAT STATS$SESSION_EVENT TABLE TOOLS
OWNER TABLE_NAME OBJECT_TYPE TABLESPACE_NAME
PERFSTAT STATS$SYSTEM_EVENT TABLE TOOLS
PERFSTAT STATS$SESSTAT TABLE TOOLS
PERFSTAT STATS$SYSSTAT TABLE TOOLS
PERFSTAT STATS$SGASTAT TABLE TOOLS
PERFSTAT STATS$SGA TABLE TOOLS
PERFSTAT STATS$ROWCACHE_SUMMARY TABLE TOOLS
PERFSTAT STATS$ROLLSTAT TABLE TOOLS
PERFSTAT STATS$BUFFER_POOL_STATISTICS TABLE TOOLS
PERFSTAT STATS$LIBRARYCACHE TABLE TOOLS
PERFSTAT STATS$LATCH_MISSES_SUMMARY TABLE TOOLS
PERFSTAT STATS$LATCH_PARENT TABLE TOOLS
OWNER TABLE_NAME OBJECT_TYPE TABLESPACE_NAME
PERFSTAT STATS$LATCH_CHILDREN TABLE TOOLS
PERFSTAT STATS$LATCH TABLE TOOLS
PERFSTAT STATS$TEMPSTATXS TABLE TOOLS
PERFSTAT STATS$FILESTATXS TABLE TOOLS
PERFSTAT STATS$DB_CACHE_ADVICE TABLE TOOLS
PERFSTAT STATS$SNAPSHOT TABLE TOOLS
PERFSTAT STATS$LEVEL_DESCRIPTION TABLE TOOLS
PERFSTAT STATS$DATABASE_INSTANCE TABLE TOOLS
Please Suggest
Message was edited by:
user592074

Thanks Chandra!
Request you to kindly suggest me how to release the sapce from tool table. Database version is 9.2.0.6 (64 bi Please find the output below.
SEGMENT_NAME SIZE_MB
PLAN_TABLE .125
SEGMENT_GROWTH 25
STATS$BG_EVENT_SUMMARY 2
STATS$BG_EVENT_SUMMARY_PK 2
STATS$BUFFER_POOL_STATISTICS 1
STATS$BUFFER_POOL_STATS_PK 1
STATS$DATABASE_INSTANCE 1
STATS$DATABASE_INSTANCE_PK 1
STATS$DB_CACHE_ADVICE 2
STATS$DB_CACHE_ADVICE_PK 1
STATS$DLM_MISC 1
STATS$DLM_MISC_PK 1
STATS$ENQUEUE_STAT 2
STATS$ENQUEUE_STAT_PK 2
STATS$FILESTATXS 3
STATS$FILESTATXS_PK 3
STATS$IDLE_EVENT .125
STATS$IDLE_EVENT_PK .125
STATS$INSTANCE_RECOVERY 1
STATS$INSTANCE_RECOVERY_PK 1
STATS$LATCH 25
STATS$LATCH_CHILDREN 1
STATS$LATCH_CHILDREN_PK 1
STATS$LATCH_MISSES_SUMMARY 1
STATS$LATCH_MISSES_SUMMARY_PK 1
STATS$LATCH_PARENT 1
STATS$LATCH_PARENT_PK 1
STATS$LATCH_PK 22
STATS$LEVEL_DESCRIPTION .125
STATS$LEVEL_DESCRIPTION_PK .125
STATS$LIBRARYCACHE 1
STATS$LIBRARYCACHE_PK 1
STATS$PARAMETER 21
STATS$PARAMETER_PK 24
STATS$PGASTAT 1
STATS$PGA_TARGET_ADVICE 1
STATS$PGA_TARGET_ADVICE_PK 1
STATS$RESOURCE_LIMIT 1
STATS$RESOURCE_LIMIT_PK 1
STATS$ROLLSTAT 2
STATS$ROLLSTAT_PK 1
STATS$ROWCACHE_SUMMARY 3
STATS$ROWCACHE_SUMMARY_PK 3
STATS$SEG_STAT 3
STATS$SEG_STAT_OBJ 1
STATS$SEG_STAT_OBJ_PK 1
STATS$SEG_STAT_PK 1
STATS$SESSION_EVENT 1
STATS$SESSION_EVENT_PK 1
STATS$SESSTAT 1
STATS$SESSTAT_PK 1
STATS$SGA 1
STATS$SGASTAT 3
STATS$SGASTAT_U 5
STATS$SGA_PK 1
STATS$SHARED_POOL_ADVICE 1
STATS$SHARED_POOL_ADVICE_PK 1
STATS$SNAPSHOT 1
STATS$SNAPSHOT_PK 1
STATS$SQLTEXT 5
STATS$SQLTEXT_PK 1
STATS$SQL_PGASTAT_PK 1
STATS$SQL_PLAN 5
STATS$SQL_PLAN_PK 1
STATS$SQL_PLAN_USAGE 5
STATS$SQL_PLAN_USAGE_HV 1
STATS$SQL_PLAN_USAGE_PK 1
STATS$SQL_STATISTICS 1
STATS$SQL_STATISTICS_PK 1
STATS$SQL_SUMMARY 17
STATS$SQL_SUMMARY_PK 8
STATS$SQL_WORKAREA_HISTOGRAM 1
STATS$SQL_WORKAREA_HIST_PK 1
STATS$STATSPACK_PARAMETER .125
STATS$STATSPACK_PARAMETER_PK .125
STATS$SYSSTAT 21
STATS$SYSSTAT_PK 25
STATS$SYSTEM_EVENT 3
STATS$SYSTEM_EVENT_PK 4
STATS$TEMPSTATXS 1
STATS$TEMPSTATXS_PK 1
STATS$UNDOSTAT 1
STATS$UNDOSTAT_PK 1
STATS$WAITSTAT 1
STATS$WAITSTAT_PK 2
STPL_DBAPRVS_ACTIVITY_LOG .0625
STPL_DBAPRVS_PENDING .0625
STPL_DBAPRVS_PENDING_PK .0625
TABLESPACE_GROWTH .3125
T_WEBBPRD .0625
90 rows selected.
Message was edited by:
user592074

Windows 8.1 Storage Spaces... won't release the space

So I have a Storage Space in Windows 8.1, it a 7 drive Pool in Parity mode with 3x 4TB drives and 4x 3TB drives. Things had been working well until I had a 3 TB drive fail, and had it RMA'd by Seagate. One of those 4TB drives was added just now also as
an upgrade.
The actual drive sizes add up to 24TB with a Formatted size of 21.77TB (3.63TB and 2.72TB respectively for 4TB and 3TB drives).
When I added the 2 new drives into the array, I thought things would work well. Since Storage Spaces doesn't have anything built in yet to redistribute the data after adding a new drive, I did a copy and then a delete of the data. This is the best recommendation
that I've currently been able to find to redistribute the data.
However, I ran out of space. Weird, since I have ample free space.
So I started moving the data off the array/space. I've now cleared the array down to just 2.62TB, with the Windows Properties reading 13.3 TB free (Parity Capacity is 15.9 TB, roughly 2/3 or the total space, which was expected). However, in the Storage Spaces
listing, my drives are listed as 90% full. This is true EVEN NOW that I've move everything but 2.72TB left.
Quick math: 2.72TB / 15.9 TB is 17.1% used, leaving 82.9% free.
However, I can't seem to "release" the space. Again, copying the data over did NOT work. and Deleting the data from the array/space DID NOT work. I can't fathom how when I delete the data from the array, it still lists it as 90% full.
Any help or ideas?

Hi,
Which method did you use to create Storage pool, simple spaces, mirror spaces, or parity spaces?
Would you please capture a screenshot of your Storeage pool?
Kate Li
TechNet Community Support

Unable to extend the temp segment by 2560 in table space TEMP

Hi,
I am running the procedure, it aggregate the data, it's taking minimum 1 hour to complete. B4 complete it throw an error:
ORA-01652 - Unable to extend the temp segment by 2560 in table space TEMP.
Note: Tround 5GB disk space is there.
Please help and give me your suggestions.
Thanks
Sathya

Well, I'll go out on a limb and suggest that the problem is that the procedure ran out of TEMP space. It's relatively easy to generate 5 GB of intermediate results to sort in the space of an hour. If other sessions were using TEMP space at the same time, that would obviously reduce the amount available to this procedure.
Your two options would be to decrease the amount of sorting that the procedure needs to do or to allocate more TEMP space for it.
Justin

Never release the temp space

Similar Messages

Maybe you are looking for