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.
Related
We are using a one-time merge query in oracle 12c which fetches around "22633334" records of data and updates it in the target table, but every time when the query run's it throws "ORA-01652: unable to extend temp segment by 64 in tablespace TEMP" issue, the DBA has already extended it to 60 GB. Can anyone tell me how this can be resolved or what would be the ideal temp space to be allocated for this volume of data?
Oracle uses that space to build temporary result sets and perform sorts. The amount of space required depends on the precise explain plain of your query (check it out and it should give you some clues), but could be several times the actual amount of data in the tables if there are joins. The number of records matters not at all; it's about the size of the records and what Oracle is trying to do with them. You want to avoid full table scans, unnecessary sorts, and that sort of thing. Make sure your table statistics are up to date. In the end, it needs what it needs and all you can do is increase your TEMP tablespace size until it works.
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!!
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.
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 would like to know if dropping Oracle index and recreating them will pose any data issues if assuming these are done during scheduled downtime.
Recently discovered that some indexes were parked on incorrect table space, would like to correct it by dropping the index and recreating it on the correct table space.
Please kindly advise.
I don't see a problem with that, but instead of drop/create you could also use the syntax below:
alter index <INDEX_NAME> rebuild tablespace <TABLESPACE_NAME>
To address what you asked in the comment below, the alter index rebuild should be faster. The reason for that is when you drop the index and create it again, index tree will be built from the table itself. But with alter index rebuild, Oracle reads the index itself, thus resulting in a smaller amount of I/O.