On this table that contains BLOBs and up to today filled up a 32GB tablespace, I removed a large percentage of BLOBs by setting them to NULL with an UPDATE statement (leaving the remaining columns untouched of course). No space was actually freed so I had to add a 2nd datafile, 4GB, in order to allow INSERT queries to work. I did a "alter table X move", no benefit. I did a "alter table X shrink space", it actually increased the occupancy of the 2nd datafile and left the 1st one unaffected.
I found a utility on the net that calculates how much space can be saved, and it gives me that the USERS ts has just 4004MB that can be freed, when I'd expect at least 10GB (4GB from the 2nd datafile that should be basically empty plus at least 6GB from the 1st datafile that was initially filled to capacity=32GB).
It seems impossible to free up space. Was setting to NULL a bad idea? Why is Oracle refusing to see any space as reclaimable?
Please advise.
Check if this helps:
http://www.dba-oracle.com/t_update_blob_reclaim_space.htm
Answer: The LOB/BLOB column still exists within the table blocks, and the data is still there. It is only marked as unused. To free up the space, use this command:
alter table
my_tab
modify lob
event_data
(shrink space);
Remember, you must shrink lob or move, after updating column as null or empty_blob.
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!!
for the archiving purpose i need to delete the data from a table but as delete will not free up space a lot of data is occupied .To save this i have figured out a solution to use shrink space command provided by oracle.
But this requires row movement to be enabled.
So my question are below:
1. is it a good idea to enable row movement for using shrink space command.
2. Can we just enable the row movement for running shrink space command and then disable it again
3. or we should leave row movement enabled and run shrink space command as and when required(say once a week).
Are you deleting all of the data on the table or just some part of it? If you are deleting all of it you could just truncate it, freeing up all of the space allocated for the tables and indexes in a very fast way:
truncate table t;
If you are not deleting of all it, the row movement approach should be ok (any of the 3 options) but you would have to test concurrent access to this table. Is there a chance someone else would try to update/insert this table at the same time of your maintenance? My guess is that this could be a problem.
So another approach could be partition the table based on your purge criteria. For example, if you will erase the data older than 3 months, you could have the table partitioned by month and delete only the partitions you wont't need anymore. This is in fact what partitions were made for, to easy maintenance of data.
I want more file system space. so I truncate all tables in oracle ,but the higher water mark still so high, I shrink my tables; I had google it ,shrink only cut dowen the space higher than hwm It reduce some space, but It help less.and I find that tablespace is only used 1% space.how can I free the space in my file system.
Finally, We find that we get a droped table in the end of the segment, so the hwm is high, we purge the tablespace , then alter table datefile resize.
One way to do it is to export the database at user level using exp. Then drop and recreate the user. Then do an import. This should free up some space.
You can also use alter database datafile to reduce one of your datafiles (these are the physical files on your hard drive used by the db).
There is a great overview of how to reclaim datafile space in this article. TL DR - export, drop user, alter datafile, import.
http://oracle-base.com/articles/misc/reclaiming-unused-space.php
I am using basic compression in Oracle to archive seemingly unused tables as a first step to dropping them. I used these commands:
alter table table1 compress basic;
alter table table1 move;
The move invalidates the index. Does the invalid index still take up space? The index no longer shows up in a query of the USER_SEGMENTS table.
This would be useful to know whether I need to drop or rebuild and compress the index to save even more space.
ALTER TABLE ... MOVE marks the indexes built on that table UNUSABLE.
In earlier versions, UNUSABLE indexes still had their segments and the allocated space was not freed up. Starting from version 11.2, UNUSABLE index segments are automatically removed.
A non-existent segment consumes less space than a compressed index segment :)
If you want to use those indexes again, you have to rebuild them. Otherwise, just drop them.
My boss has a concern that creating LOB columns in our database tables could result in effectively permanent storage overhead if we do not partition the table and drop the partitions over time (as opposed to just deleting the records). He thinks that data for the LOB will be stored separately when the record is created, which seems to be correct, but that Oracle may not delete the data for the LOB column when the row is deleted.
Is this correct or even possible? I find it hard to believe that the DBMS would handle object storage so poorly. We are using Oracle 11g if that changes anything.
I eventually found this ask tom question which covers the same topic.
When the database creates an extent to store the LOBs it is associated directly with the table. When rows containing those LOBs are deleted, the LOBs are removed from the extent which remaining the same size (it does not shrink just because a LOB was removed). However, the table is able to reuse the space from the removed LOB as one would expect.
So while the database at large is not able to reuse the free space in an extent created for a table's LOB storage, the space IS free for use by the table. The extent will exist (and therefore take up space that would otherwise be completely available to the database) until table is dropped or truncated, or the extent is explictly deallocated.
In the end, unless the extent(s) remaining allocated to the table is a concern (or there are other concerns that may be addressed through partition), creating partitions solely for this purpose is unnecessary.