I have a very large table in my database and I am starting to get this error
Could not allocate a new page for
database 'mydatabase' because of
insufficient disk space in filegroup
'PRIMARY'. Create the necessary space
by dropping objects in the filegroup,
adding additional files to the
filegroup, or setting autogrowth on
for existing files in the filegroup.
How do you fix this error? I don't understand the suggestions there.
If you're using SQL Express you may be hitting the maximum database size limit (or more accurately the filegroup size limit) which is 4GB for versions up to 2005, 10GB for SQL Express 2008 onwards. That size limit excludes the log file.
There isn't really much to add - it pretty much tells you what you need to do in the error message.
Each object (Table, SP, Index etc) you create in SQL is created on a filegroup. The default filegroup is PRIMARY. It is common to create multiple filegroups that span over many disks. For instance you could have a filegroup named INDEXES to store all of your Indexes. Or if you have one very large table you could move this on to a different filegroup.
You can allocate space to a filegroup, say 2GB. If Auto Grow is not enabled once the data in the filegroup reaches 2GB SQL Server cannot create any more objects. This will also occur is the disk that the filegroup resides on runs out of space.
I'm not really sure what else to add - as I said previously, the error message pretty much tells you what is required.
If you are using client tools (MSDE) then the data in the filegroup reaches 2GB, SQL Server cannot create any more objects.
Use DBCC shrinkfile statement to shrink file...
USE databasename ;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE databasename
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (databasename_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE databasename
SET RECOVERY FULL;
GO
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
Does Oracle make use of temp tables during backup procedures?
This has brought up many conversations in the break room, but we are limited in our expertise.
I'm pretty sure, please correct me if i am wrong, but to fully qualify for ACID - you need a way to store the data when the database is taken offline, even for a moment.
SQL Server writes to the transaction log, then will catch up after the DB comes back online - but i am not sure if Oracle follows the same idea.
thank you
If you mean with "Backup" that a Tablespace or the whole database is taken to backup-mode with ALTER TABLESPACE tbname BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP the database is not offline but the tablespace resp. the datafiles on the disk are not written into.
This is necessary to prevent a backup of the datafiles in an inconsistent state (fractured block). The blocks changed (called "dirty") during this process are written to the redo-logfile and applied later when ALTER DATABASE END BACKUP is issued.
Backups done with RMAN (Recovery Manager) dont need backup mode at all.
We have a shell script that perform a physical backup of our oracle database (tar + compress of all our database files). Recently, we created a tablespace containing tables that we dont need to backup its contents.
Is it possible to ignore data files relative to this tablespace and have a valid backup?
PS: we don't want to use RMAN.
I preface my remarks here with a note: this is NOT the normative pattern. Normally, we use RMAN to backup ALL the datafiles in the database. With that said...
Yes, it may be possible to restore and recover the database from a backup with a m ssing datafile. But the recovery will require that the tablespace be dropped when the database is restored.
For the simple case of a dropping a tablespace that contains a single datafile: first restore the database files, then:
STARTUP NOMOUNT;
ALTER DATABASE MOUNT ;
ALTER DATABASE DATAFILE '<complete_path_to_datafile>' OFFLINE DROP ;
ALTER DATABASE OPEN ;
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS ;
Then, continue with database recovery ( RECOVER DATABASE ; )
Obviously, the tablespace_name you provide in the DROP TABLESPACE command would be the one related to the datafile that is dropped.
Obviously, this wouldn't work for the SYSTEM tablespace. And I wouldn't dare try this on other tablespaces like UNDO, SYSAUX, USERS. And there's different syntax for dropping and adding TEMPORARY TABLESPACES.
I don't know of any "gotchas" with the 'DROP TABLESPACE ... INCLUDING CONTENTS', but consider that objects in other tablespaces could be impacted. (Consider that the dropped tablespace might have indexes for tables in other tablespaces, impacts on foreign key constraints, impacts on stored procedures, and so on.)
And it goes without saying, that you would need to test this type of restore procedure in a test environment before you rely on this technique in production.
Without testing, you would be much better served by using RMAN to backup ALL of the datafiles.
NOTE: I have not done anything like this since Oracle 8, possibly Oracle 7.3 (back when we had to roll our own hotbackup scripts). Since we've started using RMAN, I haven't had a need to test anything like this.
NOTE: The RECOVER DATABASE may need to be run before the ALTER DATABASE OPEN. I think you may get an exception warning about "datafile needing more recovery", like you do when you start the database when a tablespace has been left in BEGIN BACKUP mode...
I have question regarding sql system database that what purpose of these database of msdb and msdb.
Thanks in advance.
Check MSdn : System Databases and Data : http://msdn.microsoft.com/en-us/library/aa174522%28v=sql.80%29.aspx
Microsoft® SQL Server™ 2000 systems have four system databases:
* master
The master database records all of the system level information for a SQL Server system. It records all login accounts and all system configuration settings. master is the database that records the existence of all other databases, including the location of the database files. master records the initialization information for SQL Server; always have a recent backup of master available.
* tempdb
tempdb holds all temporary tables and temporary stored procedures. It also fills any other temporary storage needs such as work tables generated by SQL Server. tempdb is a global resource; the temporary tables and stored procedures for all users connected to the system are stored there. tempdb is re-created every time SQL Server is started so the system starts with a clean copy of the database. Because temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down, there is never anything in tempdb to be saved from one session of SQL Server to another.
By default, tempdb autogrows as needed while SQL Server is running. Unlike other databases, however, it is reset to its initial size each time the database engine is started. If the size defined for tempdb is small, part of your system processing load may be taken up with autogrowing tempdb to the size needed to support your workload each time to restart SQL Server. You can avoid this overhead by using ALTER DATABASE to increase the size of tempdb.
* model
The model database is used as the template for all databases created on a system. When a CREATE DATABASE statement is issued, the first part of the database is created by copying in the contents of the model database, then the remainder of the new database is filled with empty pages. Because tempdb is created every time SQL Server is started, the model database must always exist on a SQL Server system.
* msdb
The msdb database is used by SQL Server Agent for scheduling alerts and jobs, and recording operators.
We have a weekly maintenance plan to shrink all user databases and rebuild their indexes. This has working fine until we created a read-only database, now each time the plan runs it fails when it starts processing this database due to its read only state.
As far as I can see we have two options remove the read only flag from the database, this is possible but as the database is only updated once a quarter it makes sense from a performance point of view to make use of the read-only feature. Or manually select the database that the plan should run for i.e. all the users databases apart from the read only one, this then requires people to remember to add any new databases into the plan.
Does anyone have any suggestions of a better way of doing this?
Thanks
Neil
why are you shrinking the database in the first place?
also there's no need to maintain read opnly db's like that.
I'd remove the read only flag if you don't want to customise the maint plan.
Why are you shrinking DBs too? If the database grows to a given size, then this is probably it's natural current size.
Also remember that an index rebuild (rule of thumb) require free space of 120% of target table size. Eg 500 MB table needs 600 MB free space.
It's pointless to shrink then rebuild... and you'll have horrendous file fragmentation too
I suppose could modify the maintenance plan to start with a 'Execute T-SQL Statement' step, which removes the readonly flag (ALTER DATABASE database-name SET READ_WRITE) and add a final step to reset it:
ALTER DATABASE database-name SET READ_ONLY