i am having recently came to know that sql server if i delete one column or modify it acquires space at backend so i need to reindex and shrink the database and i have done it and my datbase size reduced to
2.82 to 1.62
so its good like wise so now i am in a confusion
so in my mind many questions regarding this subject occurs pls help me about this one
1. So it is necessary to recreate indexes(refresh ) after particular interval
It is necessary to shrink database after particular time so performance will be up to date?
If above yes then what particular time should i refresh (Shrink) my database?
i am having no idea what should be done for disk spacing problem i am having 77000 records it takes 2.82gb dataspace which is not acceptable i am having two tables of that one only with one table nvarchar(max) so there should be minimum spaces to database can anyone help me on this one Thanks in advance
I am going to simplify things a little for you so you might want to read up about the things I talk about in my answer.
Two concepts you must understand. Allocated space vs free space. A database might be 2GB in size but it is only using 1GB so it has allocated 2GB with 1GB free space. When you shrink a database it removes the free space so free space should be about 0. Dont think smaller file size is faster. As you database grows it has to allocate space again. When you shrink the file and then it grows every so often it cannot allocate space in a contiguous fashion. This will create fragmentation of the files which slows you down even more.
With data files(.mdb) files this is not so bad but with the transaction log shrinking the log can lead to virtual log file fragmentation issues which can slow you down. So in a nutshell there is very little reason to shrink your database on a schedule. Go read about Virtual Log Files in SQL Server there are a lot of articles about it. This is a good article about shrink log files and why it is bad. Use it as a starting point.
Secondly indexes get fragmented over time. This will lead to bad performance of SELECT queries mainly but will also affect other queries. Thus you need to perform some index maintenance on the database. See this answer on how to defragment your indexes.
Update:
Well the time you rebuild indexes is not clear cut. Index rebuilds lock the index during the rebuild. Essentially they are offline for the duration. In your case it would be fast 77 000 rows is nothing for SQL server. So rebuilding the indexes will consume server resources. IF you have enterprise edition you can do online index rebuilding which will NOT lock the indexes but will consume more space.
So what you need to do is find a maintenance window. For example if your system is used from 8:00 till 17:00 you can schedule maintenance rebuilds after hours. Schedule this with SQL server agent. The script in the link can be automated to run.
Your database is not big. I have seen SQL server handle tables of 750GB without taking strain if the IO is split over several disks. The slowest part of any database server is not the CPU or the RAM but the IO pathways to the disks. This is a huge topic though. Back to your point you are storing data in NVARCHAR(MAX) fields. I assume this is large text. So after you shrink the database you see the size at 1,62GB which means that each row in your database is about 1,62/77 000 big or roughly 22Kb big. This seems reasonable. Export the table to a text file and check the size you will be suprised it will probably be larger than 1,62GB.
Feel free to ask more detail if required.
Related
I have a database which is around 20GB in size but actually free space is around 17GB. This has happened because I have moved out quite a few audit tables that were large in size to another database altogether.
I mistakenly tried to perform a shrink database whilst in business hours but didn't realise the time it would take it to complete this so managed to stop it.
I've now done some research on this and I've read articles where shrinking a database shouldnt be done because it can cause "massive" index fragmentation. I'm no SQL guru but this does ring alarm bells.
People have suggested using a shrink with truncate only.
Are there any sql experts out there that can help me out with the right thing to do here??
Shrinking a database after you remove a large amount of data in a one-time operation is proper. You want to leave plenty of free space, as re-growing can be expensive. And you want to rebuild indexes after shrinking, to remove the fragmentation.
But here the database is only 20GB, so shrinking it won't really solve any problems. If you wanted to shrink it to 6GB or so, that would be fine. But I would just leave it at 20GB.
I have to shrink and backup a database every week which is about 100+ GB of size.
Normally it takes 2-3 hours to shrink. This is quite frustrating especially when management wants this database to be deployed quickly.
My question is
1-Is there some way to shrink a huge database quickly.
2-Instead of shrinking, if I do a backup with shrink option enabled, does it do the same, like removing unnecessary pages.
Thanks
1: no, in generally you do not shrink "real" databases (of size). specially given that SQL Server backup will not back up pages in the database not used, so a backup of an empty 1000gb database is VERY small, it makes no sense to shrink. How you think people do real backups of IMPORTANT stuff (where you run a delta backup like every 15 minutes)? Generally do not use autogrow, do not use shrink on anything that has a large size.
2: moot as per 1. Do not shrink.
Why do you think you need to shrink the database in the first place? Btw., 100gb is quite small - things get runny once you hit 1000gb and larger.
Hi all i'm completely new to maintenance tasks on SQL Server. I've set up a datawharehouse, that basically reads a load of xml files and imports this data into several tables using an SSIS. Now i've set indexes on the tables concerned and optimized my ssis. However i know that i should perform some maintenance tasks but i dont really know where to begin. We are talking about quite a bit of data, we are keeping data for up to 6 months and so far we have 3 months worth of data and the database is currently 147142.44 MB with roughly 57690230 rows in the main table. So it could easily double in size. Just wondering what your recommendations are?
While there is the usual index rebuild and statistics update which are part of normal maintenance, I would look at all of the currently long running queries and try to do some index tuning, before the data size grows. Resizing the database also forms part of a normal maintenance plan, if you can predict the growth and allocate enough space between maintenance runs then you can avoid the performance hit of space auto allocation (which will always happen at the worst possible time)
Does performance of a database (SQL Server 2005) decrease if I shrink it?
What exactly happen to the mdf and ldf files when shrink is applied (Internals???)
When shrinking a database it will consume resources to shrink the DB. Where it runs into issues is when the DB needs to grow again, and assuming you have auto grow set, it will consume more resources to auto grow. Constant auto shrink (or shrink as part of maintenance plan) will cause physical disk fragmentation.
If you have auto grow enabled and it is set to the default of 1MB then constant auto grows will consume a lot of resources.
It is best practice to size your database to a size that is suitable, expected initial size plus expected growth over a period (month, year, whatever period you see fit). You should not use auto shrink or use shrink as part of a maintenance program.
You should also set your auto grow to MB (not a % of the database as when auto growing it needs to calculate the % first, then grow the database). You should also set the auto grow to a reasonable amount to ensure that it isnt going to be growing every 10 mins, try and aim for 1 or two growths a day.
You should also look at setting Instant Initialisation for your SQL Server.
Good luck,
Matt
It's important to understand that when you shrink a database, the pages are re-arranged. Pages on the end of the data file are moved to open space in the beginning of the file, with no regard to fragmentation.
A clustered index determines the physical order of data in a table. So, imagine that you just created a clustered index, which would have re-ordered the data in that table, physically. Well, then when you execute a shrink command, the data that had just been neatly ordered during the creation of the clustered index will now potentially be out of order, which will affect SQL's ability to make efficient use of it.
So, any time you do a shrink operation you have the potential of impacting performance for all subsequent queries. However, if you re-do your clustered indexes / primary keys after the shrink, you are helping to defragment much of the fragmentation that you may have introduced during the shrink operation. If performance is critical but you are also forced to do shrinks regularly, then in an ideal world you'd want to re-do your indexes after each shrink operation.
Yes it could affect performance a bit. When a database is in operation it doesn't care to much about its diskspace usage, more about efficient data retrieval/persistance.
I have a problem with a large database I am working with which resides on a single drive - this Database contains around a dozen tables with the two main ones are around 1GB each which cannot be made smaller. My problem is the disk queue for the database drive is around 96% to 100% even when the website that uses the DB is idle. What optimisation could be done or what is the source of the problem the DB on Disk is 16GB in total and almost all the data is required - transactions data, customer information and stock details.
What are the reasons why the disk queue is always high no matter the website traffic?
What can be done to help improve performance on a database this size?
Any suggestions would be appreciated!
The database is an MS SQL 2000 Database running on Windows Server 2003 and as stated 16GB in size (Data File on Disk size).
Thanks
Well, how much memory do you have on the machine? If you can't store the pages in memory, SQL Server is going to have to go to the disk to get it's information. If your memory is low, you might want to consider upgrading it.
Since the database is so big, you might want to consider adding two separate physical drives and then putting the transaction log on one drive and partitioning some of the other tables onto the other drive (you have to do some analysis to see what the best split between tables is).
In doing this, you are allowing IO accesses to occur in parallel, instead of in serial, which should give you some more performance from your DB.
Before buying more disks and shifting things around, you might also update statistics and check your queries - if you are doing lots of table scans and so forth you will be creating unnecessary work for the hardware.
Your database isn't that big after all - I'd first look at tuning your queries. Have you profiled what sort of queries are hitting the database?
If you disk activity is that high while your site is idle, I would look for other processes that might be running that could be affecting it. For example, are you sure there aren't any scheduled backups running? Especially with a large db, these could be running for a long time.
As Mike W pointed out, there is usually a lot you can do with query optimization with existing hardware. Isolate your slow-running queries and find ways to optimize them first. In one of our applications, we spent literally 2 months doing this and managed to improve the performance of the application, and the hardware utilization, dramatically.