I'm wondering if updating statistics has helped you before and how did you know to update them?
exec sp_updatestats
Yes, updating statistics can be very helpful if you find that your queries are not performing as well as they should. This is evidenced by inspecting the query plan and noticing when, for example, table scans or index scans are being performed instead of index seeks. All of this assumes that you have set up your indexes correctly.
There is also the UPDATE STATISTICS command, but I've personally never used that.
It's common to add your statistics update to a maintenance plan (as in an Enterprise Manager-defined Maintenance plan). That way it happens on a schedule - daily, weekly, whatever.
SQL Server 2000 uses statistics to make good decisions about query execution so they definitely help.
It's a good idea to rebuild your indexes at the same time (DBCC DBREINDEX and DBCC INDEXDEFRAG).
If you rebuild indexes, then the statistics for those indexes are automatically rebuilt.
If your timeframes allow, then running UPDATE STATISTICS of part of a maintenance plan is a good idea, as frequently as nightly (if your indexes are being rebuilt less frequently than that).
SQL Server: To determine if out of date statistics are the cause of a query performing poorly, turn on 'Query->Display Estimated Execution plan' (CTRL-L) in Management Studio and run the query. Open another window, paste in the same query and turn on 'Query->Display ActualExecution plan' (CTRL-M) in Management Studio and re-run the query. If the execution plans are different then statistics are most likely out of date.
Updating statistics becomes necessary after the following events:
- Records are inserted into your table
- Records are deleted from your table
- Records are updated in your table
If you have a large database with millions of records that gets lots of writes per day you probably should be determining an off-peak time to schedule index updates.
Also, you need to consider your type of traffic. If you have a lot (millions) of records in tables with many foreign key dependencies and you have a larger proportion of writes to reads you might want to consider turning off automatic statistics recomputation (NOTE: this feature will be removed in a future version of SQL Server, but for SQL Server 2000 you should be OK). This tells the engine to not recompute statistics on every INSERT, DELETE, or UPDATE and makes those actions much more performant.
Indexes are no laughing matter. They are the heart and soul of a performant database.
Related
We had a DBA come in a few months ago and setup maintenance plans on our database. Looking at performance stats we are seeing that the task Update Statistics is running overnight and spilling in to operational hours. the vast majority of time it is working on tblAudit, this is a very large table (60Gb) and we don't need it to be part of the maintenance plan but we cannot see a way to exclude this one table. Please see attached pictures.
Is there an easy way to exclude this.
Short (but hesitant) answer: Yes, you could update that task and remove updating statistics for the big table, I'm including a screen shot - not sure why your screen shot does not seem to have anything in the "Object" drop down. I would not recommend this as your solution though and would not do this on any server, personally.
If you do implement certain objects to update and exclude objects, I believe it will make your life even worse because your statistics won't be run on any new objects added to the database - meaning if any new objects are added they would not be covered in this task AND the table being excluded from any update statistics maintenance could lead to a potentially huge performance hit on the big table.
Does that large table get any transactions (updates/inserts/deletes) at all or is it fully static (never changes)? Because if it does have any changes daily, weekly or monthly, it most likely will need updated statistics. There is an internal threshold that gets triggered for automated updating of statistics (if your database is configured with Auto Update and Auto Create), and the more rows/more data you have in a table the more updates to the data are needed to trigger an automated statistic update. What that means is the table could have potentially bad performance, especially over time if you leave it out of any mainteance task for stats updating.
I would suggest you look into implementing Ola Hallengren's maintenance plans instead of what the contract DBA created - which is merely out of the box point and click maintenance plan in your screen shot. It is usually unnecessary to do full scans on all statistics (url: https://ola.hallengren.com/).
If nothing else, perhaps JUST the statistics maintenance pieces of the scripts shared on Ola's site. I've used a modified version of the scripts to do our statistics maintenance using modified guidelines for our workload. A competent DBA would understand your workload, how often the data changes and if fullscan is needed, and when. Perhaps if you have a good maintenance window on the weekend, kick off a update statistics for that large table on the weekend, but leave a nightly script for all other tables.
A synchronization program is syncing data between our SQL server and an online database. Every 5 minutes the program runs query's on all tables, al in the format:
select max(ID) from table
After that, the program retreives information from the online database, using the max(ID) to retreive only newer records.
The query runs fast on small tables, but some tables have millions of records.
The performance can be boosted by using a Where statement:
select max(ID) from table where date >= dateadd(dd,-30,getdate())
Unfortunately it's an old program, which cannot be changed anymore.
(no supplier and no source code)
I read something about Plan Guides, which should give performance boosts to query's.
Can I use a plan guide to alter these query's so they run much faster??
I would try to stay clear of plan guides unless you have tried everything else to help SQL Server choose a better execution plan; reason, you are forcing SQL Server to choose maybe not the best execution plan and if your statistics are right, SQL Server does a heck of a job to provide you with a very good estimation plan.
Sorry if this is going to be long winded but SQL Server performance is based on statistics and if your statistics are off, your query will not perform optimally. This is where I would first start.
I would first run your query and generate an estimated execution plan and actual execution plan. If you have never worked with execution plans, here are a few sites to start you off to understand operators and how to interpret some of the more common operators; Rasanu Consulting (Joins), Microsoft (Joins), Simple Talk (Common Operatiors), Microsoft (All Operators). The execution plans are generated from statistics SQL Server stores on indexes and non-indexed columns. I am assuming your query is stored in a procedure where the initial execution plan is stored. Unfortunately, changes to the query in the stored proc can cause performance issues because of an outdated plan and the proc will need to be recompiled.
Based on the results of your execution plan, you may find a simple clustered index will help performance or find that fine tuning your where clause will result in better carnality estimates. Here are a few sites that do a really good job explaining statistics; Patrick Keisler, Itzik Ben-Gan, Microsoft
You may be wondering "what does this have to do with my question?" which would expect a simple yes or no answer but, effectively correcting query performance starts with an understanding statistics and execution plans.
Hope this helps!
we have an MS SQL query, which is rather complex in terms of joins. It's purpose is to search for specific type of entities. We recently spent some time optimizing it and setting the right indexes.
Though at some points in time (have not noticed any rules, so seems arbitrary) the web application starts timing out when utilizing this query. We then can go into the DB and rebuild the indexes on 2 tables included in the SQL and it gets back to normal... That happens occasionally.
Now pardon my ignorance, should the MSSQL rebuild the indexes itself at the optimum moments of time?
Otherwise, would we need to schedule for the index maintenance to run once we hit some level of fragmentation?
Please feel free to ignore my questions and guide me in the right direction.
Thanks in advance.
Production systems should have regular statistics maintenance and possibly some less frequent index maintenance.
Since SQL Server does not (currently) do this for you out of the box, implement Ola Hallegren's Index and Statistics Maintenance scripts. DBA's use these.
I used to rebuild indexes weekly, but now prefer to update statistics nightly, and perform less frequent index rebuilds.
I implement a weekly rebuild of all fragmented indexes (> 50%) and a nightly job (where required) to maintain heavily used (and heavily inserted into) tables.all fragmented indexes (> 50%) and a nightly job (where required) to maintain heavily used (and heavily inserted into) tables.
Got an issue where i have a complicated sql query that occasionally hangs and doesn't execute on MS SQL. However, when i run update statistics on the tables involved in the query, the query executes normally.
Any idea or pointers on the cause?
Thanks!
SQL Server creates an "execution plan" that uses the statistics info to determine an optimal order to filter the data/reduce access to the database tables.
This execution plan is stored in the database cache and is re-used as long as the database is online; the statistics are not rebuild and the query is not modified.
When you update the indexes, the statistics are updated as well.
As a result, the stored execution plan for your query is no longer optimal and as a result will not be used any more.
I expect SQL Server also closes unused locks and transactions for the table before rebuilding the index. That is an undocumented feature.
I have a very large (100+ gigs) SQL Server 2005 database that receives a large number of inserts and updates, with less frequent selects. The selects require a lot of indexes to keep them functioning well, but it appears the number of indexes is effecting the efficiency of the inserts and updates.
Question: Is there a method for keeping two copies of a database where one is used for the inserts and updates while the second is used for the selects? The second copy wouldn't need to be real-time updated, but shouldn't be more than an hour old. Is it possible to do this kind of replication while keeping different indexes on each database copy? Perhaps you have other solutions?
Your looking to setup a master/child database topology using replication. With SQL server you'll need to setup replication between two databases (preferrably on separate hardware). The Master DB you should use for inserts and updates. The Child will service all your select queries. You'll want to also optimize both database configuration settings for the type of work they will be performing. If you have heavy select queries on the child database you may also want to setup view's that will make the queries perform better than complex joins on tables.
Some reference material on replication:
http://technet.microsoft.com/en-us/library/ms151198.aspx
Just google it and you'll find plenty of information on how to setup and configure:
http://search.aim.com/search/search?&query=sql+server+2005+replication&invocationType=tb50fftrab
Transactional replication can do this as the subscriber can have a number of aditional indexes compared with the publisher. But you have to bear in mind a simple fact: all inserts/updates/deletes are going to be replicated at the reporting copy (the subscriber) and the aditional indexes will... slow down replication. It is actually possible to slow down the replication to a rate at wich is unable to keep up, causing a swell of the distribution DB. But this is only when you have a constant high rate of updates. If the problems only occur durink spikes, then the distribution DB will act as a queue that absorbes the spikes and levels them off during off-peak hours.
I would not take this endevour without absolute, 100% proof evidence that it is the additional indexes that are slowing down the insert/updates/deletes, and w/o testing that the insert/updates/deletes are actually performing significantly better without the extra indexes. Specifically , ensure that the culprit is not the other usual suspect: lock contention.
Generally, all set-based operations (including updating indexes) are faster than non set-based ones
1,000 inserts will most probably be slower than one insert of 1,000 records.
You can batch the updates to the second database. This will, first, make the index updating more fast, and, second, smooth the peaks.
You could task schedule a bcp script to copy the data to the other DB.
You could also try transaction log shipping to update the read only db.
Don't forget to adjust the fill factor when you create your two databases. It should be low(er) on the database with frequent updates, and 100 on your "data warehouse"/read only database.