In my database on SQL 2008 Express Advanced
Recovery Model is full
AutoShrink is false
When I ran sp_spaceused, I got the following;
database_name db_size unallocated_space
FreeLearningTuts 1398.13 MB 0.73 MB
reserved data index_size unused
211216 KB 207024 KB 2944 KB 1248 KB
Out of this, the size of the tables is 150MB but db size shows 1398.13. It's probably the size of the log file. Can you tell what should I do to reduce the size of the Database.
Does anything look wrong with my DB from the figures above or are these the figures that a healthy db shows?
Do you do regular log backups? If not, the log will keep growing until you hit the maximum db size for SQL Express.
Related
I'm executing very large SQL files (100-200 GBs) to import data into SQL Server on a Windows 10 computer. Execution is going well with no errors so far but disk usage is much lower than I expect it to be.
For example I executed 3 SQL files full of inserts with about 50 GBs of total size but SQL Server is showing that 6.5 GB is used by the database. Is this normal or is there something funny going on?
Disk is a 1 TB NVME M2 SSD.
Thanks in advance.
I have a strange situation on a SQL Server 2014 Express edition server. The database reached 10 GB limit, but it continued to auto-grow the data file to a current size of 80 GB. There are a lot of auto-growing events.
I checked sp_spaceused and I have a few unallocated MB, also checked sys.master_files. In logs, I get the error:
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 10240 MB per database.
How can the data file grow beyond 10 GB? What am I missing?
I have SQL database and I have sent the same database to other place for further development (there may be or may not changes in Schema). I created a a backup file and restored it on another SQL Server.
I found the log file size is very huge (14GB) even though I only have 4 tables with 1000 rows and will not grow two much. Currently I run query and found (Size is in MB).
data_size data_used_size log_size log_used_size
801.00 2.06 14220.75 55.63
What I did:
I have shrunk the log files using SQL Management Studio and also kept SIMPLE mode recovery, as we have only few updates to this database that can be done again if transaction fails at any point. I created a backup and restored same and found size of log file has decreased considerably and here is here under.
total_size data_size data_used_size log_size log_used_size
802.00 801.00 2.06 1.00 0.46
Question 1: Since the database size very less should we decrease the initial size of database
Question 2: Is this ok now to send this .bak file for restoring database at another location
Answer to Q1:
It is always a good idea to estimate your data growth and set an initial size for your database. The reason is simply to avoid the SQL Data file from performing Auto Growth operations which are very expensive. If you are not expecting any data growth, then whether or not you set Initial Size, it does not matter.
Answer to Q2:
You can send the Backup file to any location as long as your SQL Server version on which you restore the file is of similar or higher version. Only point to note is the data in the backup file - consider encryption if you have sensitive data.
There is a problem with SharePoint database "WSS_Content_"
I've got a simple document library in my SharePoint site. when I add a file of specific size(e.g 1MB),SharePoint stores the file in .mdf file 10 times of the original(1GB). I got it by checking the file size in AllDocs Table. As a reult, the original database size has grown up to 240 GB from 78 GB.
Also shrinking database couldn't be useful.
Any idea to fix my SharePoint database is greatly appreciated.
You should expect the database to be larger than the sum of your content. The physical database size includes not just content (which itself includes deleted documents/items that haven't been flushed from site recycle bins), but also transaction logs, permissions, table metadata, the database schema, indexes, and any pre-allocated space for future growth.
A database of 240 GB for only 78 GB of content does seem quite large (68% overhead sounds excessive), so you might want to look into defragmentation and shrink operations. You should verify how your SQL Server is configured in terms of pre-allocation of space; this can cause sudden large spikes in storage consumption when SQL decides it needs more storage for future growth (even though it's not consuming it with data just yet).
All that being said, your screenshot suggests that your math is off by a factor of ten; 1457664 bytes is only 1.457664 MB, not very close to 1 GB.
By the way, you can save much more space in database if you turn off versioning, because for one document it stores all its versions sepereately
I have a database with 468 MB.
I deleted all tables and the size of this database is the same.
Why size of this database is the same?
You need to Shrink or Compact the database to reclaim the empty space in the database file.
See this blog post: SqlCeEngine/ISSCEEngine: Shrink Vs Compact