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!!
Related
While migrating from MySQL to ORAcle using AWS DMS servcie, In the source side(MySQL DB instance), some huge column (mediumtext) values are empty for 75% of rows in a table. Whereas in the target (Oracle ), its migrated with some other value (Not Junk values) . For me it looks like the column values are copied incorrectly between rows.
Wherever there is empty values in the source side columns, it copied some other data. Around 75% of table data for some of the clob columns with empty values in source side, are incorrectly mapped with some other data in the oracle side. We used FULL LOB mode and 10000Kb as chunk size.
Some questions or requests -
1. Could you share the table DDL from source and target?
2. Are you sure there is no workload running on the target that could change values in the table outside the DMS process?
3. Full LOB mode migrates LOBs in chunks. Why are we specifying such a high LOB chunk size? Also, do we not know the max LOB size to use limited LOB mode.
4. Could you paste the task ARN here? I work for AWS DMS and can look to see what is going on? Once I find the root cause, I will also make sure I post an analysis here for all stackoverflow users.
Let me know.
I have reached the file size limit on my SQL Server 2008 R2 Express database which I believe is 10Gb. I know this because I see Event ID 1101 in the event log.
Could not allocate a new page for database 'ExchangeBackup' because of insufficient disk space in filegroup 'PRIMARY'
I have removed some historic data to work around the problem for now but it is only a temporary fix. One table (PP4_MailBackup) is much larger than the others so when I created this database 12 months ago, I converted this table to be a Filestream table and the data is stored outside the FileGroup in the File System. This appeared to be working successfully until I received the error and new data was no longer being added to my database.
When I do a report on table sizes I see the Reserved(KB) column adds up to almost 10GB.
The folder that holds my FileStream data is 176 GB
The database .mdf file is indeed 10GB.
Does anyone have any idea why the table PP4_MailBackup is still using nearly 7GB?
Here is the "Standard Reports -> Disk Usage report" for this database:
Thanks in advance
David
Update
Here is some more info.
There are 868,520 rows in this table.
This cmd returns 1 so I'm assuming Ansipadding is on. I have never changed this from the default.
SELECT SESSIONPROPERTY('ANSI_PADDING')
The columns are defined like this
Even if every record for every column filled the full record size, by my rough calculation the table would be around 4,125,470,000 bytes. I understand that the nvarchar columns only use the actual space required.
I'm still missing a lot of space.
Not really an answer but more of a conclusion.
I have given up on this problem and resided myself to remove data to stay under the 10GB Primary file size limit. I figured out that the nvarchar columns store 2 bytes per character in order to deal with Unicode characters although they do only use the space required and don't pad out the column with spaces. So this would account for some of the space I can't find.
I tried to convert my char(500) columns to varchar(500) by adding new columns with the correct type copying data into them and then removing the old column. This worked but the table actually got bigger because removing the column is only a Meta data change and does not actually remove the data. To recover the space I would need to create a new table and copy the data across then remove the old table of course I don't have enough space in the primary file to do that.
I thought about copying the table to temp db removing the original table then copying it back but temp db doesn't support filestream columns (at least to my knowledge) so I would need to hold all 170GB within the temp db table. This sounded like a dubious solution and my test server didn't have enough space on the partition where temp db was stored. I couldn't find anything on the files size limit of tempdb on sql 2008 Express, but at this point it was all getting too hard.
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;
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
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.