I have some cache tables that are already empty by a delete, if I try to truncate a table with the DROP STORAGE option, the memory will be free?
From the documentation:
By default, Oracle Database also performs the following tasks:
Deallocates all space used by the removed rows except that specified by the MINEXTENTS storage parameter
The DROP STORAGE option has exactly the same effect as it is the default.
Related
We have a log table in our production database which is hosted on Azure. The table has grown to about 4.5 million records and now we just want to delete all the records from that log table.
I tried running
Delete from log_table
And I also tried
Delete top 100 from log_table
Delete top 20 from log_table
When I run the queries, database usage jumps to 100% and the query just hangs. I believe this is because of the large number of records in the table. Is there a way we can overcome the issue?
To delete all rows in a big table, you can use the truncate table command.
This command is used to remove all rows from a table, and it is a faster operation than using the DELETE command
Ex:
TRUNCATE TABLE table_name;
In an Azure SQL database, you have several options to choose from, for you to control the size of your database and its log file. First of all, let's start with some defenitions:
Data space used is the amount of space used to store database
data. Generally, space used increases (decreases) on inserts
(deletes). In some cases, the space used does not change on inserts
or deletes depending on the amount and pattern of data involved in
the operation and any fragmentation. For example, deleting one row
from every data page does not necessarily decrease the space used.
Data space allocated is the amount of formatted file space made
available for storing database data. The amount of space allocated
grows automatically, but never decreases after deletes. This behavior
ensures that future inserts are faster since space does not need to
be reformatted.
Data space allocated but unused represents the maximum amount of free
space that can be reclaimed by shrinking database data files.
Data max size is the maximum amount of space that can be used for
storing database data. The amount of data space allocated cannot grow
beyond the data max size.
In Azure SQL Database, to shrink files you can use either DBCC SHRINKDATABASE or DBCC SHRINKFILE commands:
DBCC SHRINKDATABASE shrinks all data and log files in a database using a single command. The command shrinks one data file at a time, which can take a long time for larger databases. It also shrinks the log file, which is usually unnecessary because Azure SQL Database shrinks log files automatically as needed.
DBCC SHRINKFILE command supports more advanced scenarios:
It can target individual files as needed, rather than shrinking all files in the database.
Each DBCC SHRINKFILE command can run in parallel with other DBCC SHRINKFILE commands to shrink multiple files at the same time and reduce the total time of shrink, at the expense of higher resource usage and a higher chance of blocking user queries, if they are executing during shrink.
If the tail of the file does not contain data, it can reduce allocated file size much faster by specifying the TRUNCATEONLY argument. This does not require data movement within the file.
Now going on to some useful SQL queries:
-- Shrink database data space allocated.
DBCC SHRINKDATABASE (N'database_name');
-- Review file properties, including file_id and name values to reference in shrink commands
SELECT file_id,
name,
CAST(FILEPROPERTY(name, 'SpaceUsed') AS bigint) * 8 / 1024. AS space_used_mb,
CAST(size AS bigint) * 8 / 1024. AS space_allocated_mb,
CAST(max_size AS bigint) * 8 / 1024. AS max_file_size_mb
FROM sys.database_files
WHERE type_desc IN ('ROWS','LOG');
-- Shrink database data file named 'data_0` by removing all unused at the end of the file, if any.
DBCC SHRINKFILE ('data_0', TRUNCATEONLY);
GO
When it comes to the log file of a database, you can use the following queries:
-- Shrink the database log file (always file_id 2), by removing all unused space at the end of the file, if any.
DBCC SHRINKFILE (2, TRUNCATEONLY);
... and to set the database log file to automatically shrink itself and keep a certain amount of space, you may use:
-- Enable auto-shrink for the current database.
ALTER DATABASE CURRENT SET AUTO_SHRINK ON;
For reference purposes, I didn't get this information myself, but extracted it from this official article in Microsoft Docs
I'm new to this Oracle Database. Today I ran DROP TABLE table1; and tried to FLASHBACK it. But the Script Output returned this :
FLASHBACK TABLE TABLE1 TO BEFORE DROP
Error report -
ORA-38305: object not in RECYCLE BIN
38305. 00000 - "object not in RECYCLE BIN"
*Cause: Trying to Flashback Drop an object which is not in RecycleBin.
*Action: Only the objects in RecycleBin can be Flashback Dropped.
I thought that the recyclebin was somehow disabled. So I opened another connection and input this command :
ALTER SESSION SET recyclebin = ON;
and repeated the process again, the result was still the same. There was nothing in the recyclebin when I ran SELECT * FROM RECYCLEBIN;
Did I unintentionally mess up anything ?
The technique you're using is Oracle Flashback Drop. It's enabled when satisfying the following three conditions:
Parameter RECYCLEBIN='on'
Data not being stored in SYSTEM tablespace
Data must be stored in a locally managed tablespace
I guest that you're simulating your examples under SYS user (which has the default tablespace SYSTEM) leading to you can't flachback at all.
I did try to login as SYS user and simulating a small example as yours and do get the same error output as yours.
Try your lab under another user which default tablespace not SYSTEM.
You can verify the conditions by checking:
Recleclebin='on' with SQL*PLUS SQL> SHOW PARAMETER RECYCLEBIN;
Default Tablespace not SYSTEM with SQL> select default_tablespace
from dba_users where username='input_username';
Tablespace datafile is locally managed with SQL>select
extent_management from dba_tablespaces where
tablespace_name='input_tablespace_name';
you didn't mess up anything with the command ALTER SESSION SET recyclebin = ON; but it's late to invoke that command. I think your problem is due your default tablespace to be SYSTEM for tables.
Oracle Flashback Drop reverses the effects of a DROP TABLE operation. It can be used to recover after the accidental drop of a table. Flashback Drop is substantially faster than other recovery mechanisms that can be used in this situation, such as point-in-time recovery, and does not lead to any loss of recent transactions or downtime.
The table and its dependent objects will remain in the recycle bin until they are purged from the recycle bin. You can explicitly purge a table or other object from the recycle bin with the command:
DROP TABLE some_table PURGE;
Dropped objects are kept in the recycle bin until such time as no new extents can be allocated in the tablespace to which the objects belong without growing the tablespace. This condition is referred to as space pressure. Space pressure can also arise due to user quotas defined for a particular tablespace. A tablespace may have free space, but the user may have exhausted his or her quota on it.
When space pressure arises, the database selects objects for automatic purging from the recycle bin. Objects are selected for purging on a first-in, first-out basis, that is, the first objects dropped are the first selected for purging.
There is no fixed amount of space preallocated for the recycle bin. Therefore, there is no guaranteed minimum amount of time during which a dropped object will remain in the recycle bin.
To view only objects in the recycle bin, use the USER_RECYCLEBIN and DBA_RECYCLEBIN views.
I have a problem when it comes to delete a large table from my database (170GB).
When i "elete this large table by right click > delete I do not get the storage space free again. Of course the table is off the database but the database needed space does not shrink
Can anyone tell me what is wrong?
Tables are stored in table spaces. These are allocated to the database, regardless of whether the space is actually used to store tables (or indexes or anything else).
When you delete the table, you have freed space in the table space. The space is available to the database for your next table (or whatever). You need to either drop or shrink the table space to release the space back to the operating system.
A place to start is with dbcc shrinkfile, documented here.
Short answer:
Run sp_clean_db_free_space, before shrinking. My assumption is that you've tried shrinking the files, but if not that question has been answered.
Parenthetical statement:
You shouldn't shrink databases if you can avoid it.
Long answer: The behavior you see is the result of Ghost Records. To understand more about this at a system level read this article: Inside the Storage Engine: Ghost cleanup in depth.
I am trying to drop a varchar(100) column of a 150 GB table (4.6 billion records). All the data in this column is null. I have 30GB more space in the database.
When I attempt to drop the column, it says "no more room in database XY". Why does such an action needs so much space?
The ALTER TABLE statement needs a temporary storage for the altered version before overwriting the original table. I guess the the table that you are trying to alter occupies at least 1/3 of your total storage size
This could happen for a variety of reasons. It's possible that one of the AMP's in your database are full, this would cause that error even with a minor table alteration.
try running the following SQL to check space
select VProc, CurrentPerm, MaxPerm
from dbc.DiskSpace
where DatabaseName='XY';
also, you should check to see what column your primary index is on in this very large table. if the table is not skewed properly, you could also run into space issues when trying to alter a table or by running a query against it.
For additional suggestions I found a decent article on the kind of things you may want to investigate when the "no more room in database" error occurs - Teradata SQL Tutorial. Some of the suggestions include:
dropping any intermediary work or "sandbox" tables
implementing single value or multi-value compression.
dropping unwanted/unnecessary secondary indexes
removing data in dbc tables like accesslog or dbql tables
remove and archive old tables that are no longer used.
I have a test database with 1 table having some 50 million records. The table initially had 50 columns. The table has no indexes. When I execute the "sp_spaceused" procedure I get "24733.88 MB" as result. Now to reduce the size of this database, I remove 15 columns (mostly int columns) and run the "sp_spaceused", I still get "24733.88 MB" as result.
Why is the database size not reducing after removing so many columns? Am I missing anything here?
Edit: I have tried database shrinking but it didn't help either
Try running the following command:
DBCC CLEANTABLE ('dbname', 'yourTable', 0)
It will free space from dropped variable-length columns in tables or indexed views. More information here DBCC CLEANTABLE and here Space used does not get changed after dropping a column
Also, as correctly pointed out on the link posted on the first comment to this answer. After you've executed the DBCC CLEANTABLE command, you need to REBUILD your clustered index in case the table has one, in order to get back the space.
ALTER INDEX IndexName ON YourTable REBUILD
When any variable length column is dropped from table, it does not reduce the size of table. Table size stays the same till Indexes are reorganized or rebuild.
There is also DBCC command DBCC CLEANTABLE, which can be used to reclaim any space previously occupied with variable length columns. Here is the syntax:
DBCC CLEANTABLE ('MyDatabase','MySchema.MyTable', 0)WITH NO_INFOMSGS;
GO
Raj
The database size will not shrink simply because you have deleted objects. The database server usually holds the reclaimed space to be used for subsequent data inserts or new objects.
To reclaim the space freed, you have to shrink the database file. See How do I shrink my SQL Server Database?