I have virtualbox with oracle database. So, I had 5 gb space left. I tried to import 2gb something dmp file, and it failed after disk became full. So, I tried to drop it by using "DROP USER ABC";
The username was dropped but the space was not recovered.
Please let me know I would be able recover this space?
Thank you.
Did you use the "CASCADE" option? If the user dropped without that option, then it didn't own any database objects and would not have recovered any space. There are other ways you could have lost the space, too, besides from the data itself: archived transaction logs, space for indexes (that don't store data in the dmp files), and the growth of the TEMP tablespace come immediately to mind.
Use the DBA_SEGMENTS view to establish which objects are actually taking up space in your database, which users own them, and which tablespaces they're located in:
https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/DBA_SEGMENTS.html
http://dba-oracle.com/t_dba_segments.htm
Also check your archivelog location, automatic diagnostic repository (ADR) for log and trace file growth, and see if you can reduce the size of your TEMP tablespace (if it seems to have grown).
Related
While deleting a large number of records, I get this error:
The transaction log for database 'databasename' is full
I found this answer very helpful, it recommends:
Right-click your database in SQL Server Manager, and check the Options page.
Switch Recovery Model from Full to Simple
Right-click the database again. Select Tasks Shrink, Files Shrink the log file to a proper size (I generally stick to 20-25% of the size of the data files)
Switch back to Full Recovery Model
Take a full database backup straight away
Question: in step 3, when I go to shrink > files and choose log from the file type dropdown menu, it tells me that 99% of the allocated space is free.
Out of ~4500MB of allocated space, there is ~4400MB free (the data file size is ~3000MB).
Does that mean I'm good to go, and there is no need to shrink?
I don't understand this. Why would that be the case, given the warning I received initially?
I'm not one for hyperbole, but there are literally billions of articles written about SQL Server transaction logs.
Reader's digest version: if you delete 1,000,000 rows at a time, the logs are going to get large because it is writing those 1,000,000 deletes in case it has to roll back the transaction. The space needed to hold those records does not get released until the transaction commits. If your logs are not big enough to hold 1,000,000 deletes, the log will get filled, throw that error you saw, and rollback the whole transaction. Then all that space will most likely get released. Now you have a big log with lots of free space.
You probably hit a limit on your log file at 4.5gb and it wont get any bigger. To avoid filling your logs in the future, chunk down your transactions to smaller amounts, like deleting 1,000 records at a time. A shrink operation will reduce the physical size of the file, like from 4.5gb down to 1gb.
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-2017
I have a PostgreSQL (10.0 on OS X) database with a single table for the moment. I have noticed something weird when I'm importing a csv file in that table.
When the import fails for various reasons (e.g. one extra row in the csv file or too many characters in a column for a given row), no rows are being added to the table but PostgreSQL still claims that space on my hard disk.
Now, I have a very big csv to import and it failed several time because the csv was not compliant to begin with - so I had tons of import fails that I fixed and tried to import again. What I've realized now is that my computer storage has been reduced by 30-50 GB or so because of that and my database is still empty.
Is that normal?
I suspect this is somewhere in my database cache. Is there a way for me to clear that cache or do I have to fully reinstall my database?
Thanks!
Inserting rows into the database will increase the table size.
Even if the COPY statement fails, the rows that have been inserted so far remain in the table, but they are dead rows since the transaction that inserted them failed.
In PostgreSQL, the SQL statement VACUUM will free that space. That typically does not shrink the table, but it makes the space available for future inserts.
Normally, this is done automatically in the background by the autovacuum daemon.
There are several possibilities:
You disabled autovacuum.
Autovacuum is not fast enough cleaning up the table, so the next load cannot reuse the space yet.
What can you do:
Run VACUUM (VERBOSE) on the table to remove the dead rows manually.
If you want to reduce the table size, run VACUUM (FULL) on the table. That will lock the table for the duration of the operation.
I have a table called test i insert 40000 records in it ,I split my database file into two file groups like this :
The size of both files based on round robin algorithm increased 160 mb as you can see .
after this i delete the data in my table .but the size of both file (FileGroup)
remains on 160 mb .Why ?
This is because SQL Server is assuming that if your database got that large once, it is likely it will need to do so again. To save having to go through the overhead of requesting space from the operating system each time SQL Server wants to use some more disk space, it will simply hold on to what it has and fill it back up as required unless you manually issue a SHRINK DATABASE command.
Due to this, using shrink is generally considered a bad idea, unless you are very confident your database will not need that space at some point in the future.
I need to delete some old logs from the database, however due to lack of space in the physical hard disk, there isn't enough space to sustain the growth of transaction log resulting from the delete activity.
My question is:
If i were to write a cursor to delete the data, would this action still contribute to the transaction log growth from this activity? I think yes, but just to confirm.
If #1 is not an option, then what else can I try? Physical disk space increase is not an option either.
Hope I've provided sufficient information to get some help. Please let me know if more is required.
Thanks in advance for any help received.
#GarethD is this a viable solution?
Perform full backup of the entire database into a remote location – ensure that this backup copy can be restored successfully.
Assuming that you wish to retain the data from years 2012 to present day, export out ONLY all the data that you wish to retain from UGCALL.
Ensure that this export can be imported into an empty table successfully and the data is not corrupted.
Truncate the UGCALL table. Check the disk space once truncate operation has been completed.
Re-import the data exported in step (2) into the UGCALL table and verify that the import is successful.
Check the disk space usage once more to see if remaining space is sufficient.
Yes, deleting row-at-a-time by a cursor will cause the same problem.
As noted, only a TRUNCATE TABLE will delete all rows without logging them individually. It uses less log space, but still some.
I have a SQL Server database of size 270GB. Almost 91% of the space is showing up as UNUSED in space report. I know unused space is space allocated to a particular object. App team did a purge operation on the DB but we couldn't really claim space with that.
I have checked index fragmentation on the table but they look good.. What else i need to be checking and what is that i should do to release that space. The DB is not going to use that space anytime in future.
As per my understanding DBCC SHRINKFILE releases only unallocated space. I've read about DBCC CLEANTABLE and DBCC SHRINK DATABASE but not sure if it's good enough to perform.
How to effectively release unused space from objects.
So to my understanding, you first need to shrink the files, then you can shrink the DB:
Using SQL Server Management Studio:
Shrink the files: r-click on DB, 'Tasks', 'Shrink', 'Files': Then pick a new file size value slightly larger than the 'Minimum is' value given in the dialog.
Shrink the database: r-click on DB, 'Tasks', 'Shrink', 'Database' (tick the 'Reorganize files checkbox)
With this, I was able to reduce the percentage of 'unused' space in the Disk report. There is still quite some left though (20%) .. I think 'reorganizing' some indices might help.
If there are only indexes in your database then you can drop your old filegroup after creating a new filegroup and moving all indexes into it.you can move the indexes using CREATE INDEX ... WITH DROP_EXISTING