I noticed today that SQL command that is used to shrink LOBs in oracle does not work in 12c.
ALTER TABLE SAMPLE_TABLE MODIFY lob (LOB_COLUMN) (SHRINK SPACE)
This returns oracle error
ORA-10635: Invalid segment or tablespace type
In the oracle documentation it is mentioned that the SHRINK option is not supported for SecureFiles LOBs.
I want to know how blob compresses in secure files. Does oracle handles that internally?
Thanks
ALTER TABLE SAMPLE_TABLE MOVE LOB(LOB_COLUMN) STORE AS (TABLESPACE USERS)
Note: this is, unlike how it can be read, a move lob operation. It is a move TABLE operation, and while at it, moving a lob too.
This is why it invalidates indexes, - because it moves the whole table not just the lob. And of course it can take a very long time and it will consume 2x space during the operation, because oracle makes a copy of the data and only after it's complete it frees the old segments.
If you want to shrink LOBs using SecureFiles, use this statement:
ALTER TABLE SAMPLE_TABLE MOVE LOB(LOB_COLUMN) STORE AS (TABLESPACE USERS)
Be careful using it - this command invalidates all indexes on SAMPLE_TABLE, so you should rebuild them after you're finished with LOBs:
ALTER INDEX <index_name> REBUILD;
Related
I have a friend who has a website and asked me for help.
I often use MySQL databases but never Oracle databases.
And unfortunately he has an Oracle database, so I can't find a solution.
The available disk space is slowly decreasing... I delete a lot of lines from the table but that doesn't solve his problem.
The database continues to take up disk space slowly.
I read that LOB files do not return disk space, even if you delete data.
How can I reorganize LOB files easily with a simple request?
(or/and) How can I recover disk space on Oracle?
SELECT DISTINCT VERSION FROM PRODUCT_COMPONENT_VERSION
12.1.0.1.0
The BLOB column exists within the table blocks along with data even after deletion. It is only marked as unused. You can use the following command to free up space from the BLOB table:
ALTER TABLE <YOUR_TABLE_NAME> MODIFY
LOB <LOB_COLUMN_NAME>
( SHRINK SPACE );
Now, Table must have released some space and it is now available to be used within the tablespace.
Further, you can just alter the data file and reduce the size of the data file accordingly to free up space from Disk. (Note: Space allocated to the data file will not be automatically reduced. It must be done manually)
Cheers!!
The documentation is clear about how to purge an Oracle AQ:
dbms_aqadm.purge_queue_table()
However, what happens to the storage, especially the high water marks of the queue table, the indexes and of the LOB segments? Is it necessary to shrink the table, too?
In production, the queues are nearly always empty (as they should), but in our test system, they fill up to millions of rows for various reasons, so they need to be emptied sometimes.
Is it neccessary to look at the underlying tables and indexes or is this taken care of automatically?
Many thanks!
DBMS_AQADM.PURGE_QUEUE_TABLE it is equivalent for truncate table. Also look at this error message when you try truncate queue table
ORA-24005: Inappropriate utilities used to perform DDL on AQ table %s.%s
*Cause: An attempt was made to use the SQL command DROP TABLE or TRUNCATE
TABLE or ALTER TABLE on queue metadata or tables.
*Action: Use the DBMS_AQADM.DROP_QUEUE_TABLE to DROP TABLE,
DBMS_AQADM.PURGE_QUEUE_TABLE to TRUNCATE TABLE.
ALTER TABLE redefinition based on only ALTER_TABLE_PROPERTIES and
ALTER_TABLE_PARTITIONING clauses are allowed.
Tom Kyte has already written info about often truncating table https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:47911859692542
I need to compress a table. I used alter table tablename compress to compress the table. After doing this the table size remained the same.
How should I be compressing the table?
To compress the old blocks of the table use:
alter table table_name move compress;
This will reinsert the records in another blocks, compressed, and discard old blocks, so you'll gain space. And invalidates the indexex, so you will need to rebuild them.
Compress does not affect already stored rows. Please, check the official documentation:
" You specify table compression with the COMPRESS clause of
the CREATE TABLE statement. You can enable compression for an existing
table by using this clause in an ALTER TABLEstatement. In this case,
the only data that is compressed is the data inserted or updated after
compression is enabled..."
ALTER TABLE t MOVE COMPRESS is a valid answer. But if you use different non default options, especially with big data volume, do regression tests before using ALTER TABLE ... MOVE.
There were historically more problems (performance degradations and bugs) with it. If you have access, look Oracle bug database to see if there are known problems for features and version you use.)
You are on safer side if you: create new table insert data from original (old) table drop old table rename new table to old table name
I am not a database administrator by any means so I might be wrong in stating some of the things here.
In SQL Server, when we add a large amount of data in the database and then when we delete it, the size of the data files (.mdf file) or database (or whatever it is called) does not get reduced to the original size. We need to shrink it.
Do the same fundamentals work in Oracle? If yes then how should I go about shrinking an Oracle 11g database?
Full explanation from the Oracle Documentation: Reclaiming Wasted Space. For the short version:
"You can shrink space in a table, index-organized table, index,
partition, subpartition, materialized view, or materialized view log.
You do this using ALTER TABLE, ALTER INDEX, ALTER MATERIALIZED VIEW,
or ALTER MATERIALIZED VIEW LOG statement with the SHRINK SPACE
clause."
So, after running the Oracle Segment Advisor to recommend areas to shrink, something like the following will shrink space in a table named mytable.
SQL> alter table mytable enable row movement;
Table altered
SQL> alter table mytable shrink space;
Table altered
I have a similar case for a table size 28 Gb, when I deleted data from it, I saw no change occurred.
after I created another table from this table and dropped the first one, the size shrunk by 10 Gb to be 18Gb.
CREATE TABLE NEW_TBL AS SELECT * FROM OLD_TBL
How can we shrink temp tablespace in oracle? And why it is increasing so much like upto 25 GB since there is only one schema in the database for the application and data table space size is 2 GB and index table space size is 1 GB used.
Oh My Goodness! Look at the size of my temporary table space!
Or... how to shrink temporary tablespaces in Oracle.
Yes I ran a query to see how big my temporary tablespace is:
SQL> SELECT tablespace_name, file_name, bytes
2 FROM dba_temp_files WHERE tablespace_name like 'TEMP%';
TABLESPACE_NAME FILE_NAME BYTES
----------------- -------------------------------- --------------
TEMP /the/full/path/to/temp01.dbf 13,917,200,000
The first question you have to ask is why the temporary tablespace is so large.
You may know the answer to this off the top of your head. It may be due to a
large query that you just run with a sort that was a mistake (I have done that
more than once.) It may be due to some other exceptional circumstance. If that
is the case then all you need to do to clean up is to shrink the temporary
tablespace and move on in life.
But what if you don't know? Before you decide to shrink you may need to do some
investigation into the causes of the large tablespace. If this happens on a
regular basis then it is possible that your database just needs that much space.
The dynamic performance view
V$TEMPSEG_USAGE
can be very useful in determining the cause.
Maybe you just don't care about the cause and you just need to shrink it.
This is your third day on the job. The data in the database is only 200MiB
if data and the temporary tablespace is 13GiB - Just shrink it and move on.
If it grows again then we will look into the cause. In the mean time I am
out of space on that disk volume and I just need the space back.
Let's take a look at shrinking it. It will depend a little on what version
of Oracle you are running and how the temporary tablespace was set up.
Oracle will do it's best to keep you from making any horrendous mistakes
so we will just try the commands and if they don't work we will shrink
in a new way.
First let's try to shrink the datafile. If we can do that then we get back
the space and we can worry about why it grew tomorrow.
SQL>
SQL> alter database tempfile '/the/full/path/to/temp01.dbf' resize 256M;
alter database tempfile '/the/full/path/to/temp01.dbf' resize 256M
*
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value
Depending on the error message you may want to try this with different sizes
that are smaller than the current site of the file. I have had limited
success with this. Oracle will only shrink the file if the temporary tablespace
is at the head of the file and if it is smaller than the size you
specify. Some old Oracle documentation (they corrected this) said that
you could issue the command and the error message would tell you what
size you could shrink to. By the time I started working as a DBA this was
not true. You just had to guess and re-run the command a bunch of times
and see if it worked.
Alright. That didn't work. How about this.
SQL> alter tablespace YOUR_TEMP_TABLESPACE_NAME shrink space keep 256M;
If you are in 11g (Maybee in 10g too) this is it! If it works you may want
to go back to the previous command and give it some more tries.
But what if that fails. If the temporary tablespace is the default temporary
that was set up when the database was installed then you may need to do a
lot more work. At this point I usually re-evaluate if I really need that
space back. After all disk space only costs $X.XX a GiB. Usually I don't want
to make changes like this during production hours. That means working at 2AM
AGAIN! (Not that I really object
to working at 2AM - it is just that... Well I like to sleep too. And my wife
likes to have me at home at 2AM... not roaming the downtown streets at 4AM trying
to remember where I parked my car 3 hours earlier. I have heard of that "telecommuting"
thing. I just worry that I will get half way through and then my internet connectivity
will fail - then I have to rush downtown to fix it all before folks show up in the
morning to use the database.)
Ok... Back to the serious stuff...
If the temporary tablespace you want to shrink is your default
temporary tablespace, you will have to first create a new temporary
tablespace, set it as the default temporary tablespace then drop
your old default temporary tablespace and recreate it. Afterwords
drop the second temporary table created.
SQL> CREATE TEMPORARY TABLESPACE temp2
2 TEMPFILE '/the/full/path/to/temp2_01.dbf' SIZE 5M REUSE
3 AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Tablespace created.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;
Database altered.
SQL> DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
SQL> CREATE TEMPORARY TABLESPACE temp
2 TEMPFILE '/the/full/path/to/temp01.dbf' SIZE 256M REUSE
3 AUTOEXTEND ON NEXT 128M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Tablespace created.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
Database altered.
SQL> DROP TABLESPACE temp2 INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
Hopefully one of these things will help!
The options for managing tablespaces have got a lot better over the versions starting with 8i. This is especially true if you are using the appropriate types of file for a temporary tablespace (i.e. locally managed tempfiles).
So, it could be as simple as this command, which will shrink your tablespace to 128 meg...
alter tablespace <your_temp_ts> shrink space keep 128M;
The Oracle online documentation is pretty good. Find out more.
edit
It would appear the OP has an earlier version of the database. With earlier versions we have to resize individual datafiles. So, first of all, find the file names. One or other of these queries should do it...
select file_name from dba_data_files where tablespace_name = '<your_temp_ts>'
/
select file_name from dba_temp_files where tablespace_name = '<your_temp_ts>'
/
Then use that path in this command:
alter database datafile '/full/file/path/temp01.dbf' resize 128m
/
You should have written what version of Oracle you use. You most likely use something else than Oracle 11g, that's why you can't shrink a temp tablespace.
Alternatives:
1) alter database tempfile '[your_file]' resize 128M; which will probably fail
2) Drop and recreate the tablespace. If the temporary tablespace you want to shrink is your default temporary tablespace, you may have to first create a new temporary tablespace, set it as the default temporary tablespace then drop your old default temporary tablespace and recreate it. Afterwards drop the second temporary table created.
3) For Oracle 9i and higher you could just drop the tempfile(s) and add a new one(s)
Everything is described here in great detail.
See this link: http://databaseguide.blogspot.com/2008/06/resizing-temporary-tablespace.html
It was already linked, but maybe you missed it, so here it is again.
It will be increasing because you have a need for temporary storage space, possibly due to a cartesian product or a large sort operation.
The dynamic performance view V$TEMPSEG_USAGE will help diagnose the cause.
Temporary tablespaces are used for database sorting and joining operations and for storing global temporary tables. It may grow in size over a period of time and thus either we need to recreate temporary tablespace or shrink it to release the unused space.
Steps to shrink TEMP Tablespace
alter database datafile 'C:\ORA_SERVER\ORADATA\AXAPTA\AX_DATA.ORA' resize 40M;
If it doesn't help:
Create new tablespace
Switch to new temporary tablespace
Wait until old tablespace will not be used
Delete old tablespace
I don't bother with dropping the alternate temp in case i need to reclaim storage again in the future...
from temp group set default to stand-alone temp
wait awhile, then resize members of temp group
set default back to temp group
wait awhile, resize stand alone temp. there's no rush to do the last step