Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.ms-sqlserver > #1415
| X-Received | by 10.224.185.201 with SMTP id cp9mr7147021qab.6.1363468323290; Sat, 16 Mar 2013 14:12:03 -0700 (PDT) |
|---|---|
| X-Received | by 10.49.85.35 with SMTP id e3mr920594qez.7.1363468323240; Sat, 16 Mar 2013 14:12:03 -0700 (PDT) |
| Path | csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!t2no4027872qal.0!news-out.google.com!k8ni188qas.0!nntp.google.com!dd2no1980267qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail |
| Newsgroups | comp.databases.ms-sqlserver |
| Date | Sat, 16 Mar 2013 14:12:03 -0700 (PDT) |
| In-Reply-To | <XnsA1857FA5E27D7Yazorman@127.0.0.1> |
| Complaints-To | groups-abuse@google.com |
| Injection-Info | glegroupsg2000goo.googlegroups.com; posting-host=94.197.255.137; posting-account=dELd-gkAAABehNzDMBP4sfQElk2tFztP |
| NNTP-Posting-Host | 94.197.255.137 |
| References | <0e799bb4-d98b-422d-8d01-c2f0a0ac5810@googlegroups.com> <XnsA181E6006E85FYazorman@127.0.0.1> <fdcfe50c-6c97-4836-b7c3-bf00c09767a8@googlegroups.com> <XnsA1857FA5E27D7Yazorman@127.0.0.1> |
| User-Agent | G2/1.0 |
| MIME-Version | 1.0 |
| Message-ID | <12f0a067-0608-44d9-bfd7-5b0ea592f5ae@googlegroups.com> (permalink) |
| Subject | Re: Elementary management of many indexes, best practice? |
| From | rja.carnegie@gmail.com |
| Injection-Date | Sat, 16 Mar 2013 21:12:03 +0000 |
| Content-Type | text/plain; charset=ISO-8859-1 |
| Xref | csiph.com comp.databases.ms-sqlserver:1415 |
Show key headers only | View raw
On Saturday, 16 March 2013 11:32:53 UTC, Erland Sommarskog wrote: > (rja.carnegie@gmail.com) writes: > > Well, I know it's wrong, but, as I said, stuck with it. > > This is for EIS and is a ludicrous way to set things up, > > What is EIS? I meant "Enterprise Information System", which I suppose is an out-of-date term: reports for bosses. /Interactive/ reports. > > but I don't have authority to change it. Up to now I > > haven't even got the server (2005, Standard) brought > > up to the latest service pack - but we had a particularly > > bad Friday, so, if I get the chance, what version > > should I ask for? > > Service Pack 4 is the last service pack for SQL 2005. OK... so there aren't any hotfixes or cumulative updates that you'd install as standard? I know we're not /supposed/ to do that. <http://www.sqldbaguru.com/cu-builds> is a catalogue of these, and <http://support.microsoft.com/kb/2494120> is particularly interesting because it fixes a security hole - which I think I remember, from looking at documentation previously, is only in the server admin or client tools, not in the server itself. However, it bumps you from Service Pack 4 (9.00.5000) to 9.00.5057. It was six months ago, when I was told that installing the service pack wasn't going to be scheduled. A problem that we have currently, that may be associated with a particular query, seems to lead to tempdb suddenly inflating to over 250 gigabytes - the size of the separate partition that someone with unusual forethought placed it on. We think this is a completely unreasonable effect. > > What I've got now is worse, though; any program that runs > > slow is liable to have been changed to create table indexes > > on the spot. Having /one/ procedure that creates all > > table indexes - being called separately for each table - > > will keep things more coherent, and maybe even create a > > presumption that a table will /have/ indexes, which > > doesn't cross some of our developers' minds when they (!) > > take it into their head to create one. On the other > > hand, my boss likes under pressure to use the tuning tool > > on a query and then create all of the indexes that it > > proposes, at once, which I /think/ is wrong? > > The purpose of the Database Tuning Advisor is that you collect a > workload for a longer period, say a day, and from this add or drop > indexes. If you feed it a single query it will tune that workload, > and be oblvious to other effects it may have. The trouble that I see with that is that our EIS team only has one SQL server - no, don't leave... The tuning process is liable to block normal use of the server (uh, right?), particularly if you're tuning for a query where performance stinks. My impression has been that tuning recommendations should be treated as alternatives to choose from, rather than a prescribed remedy; I seem to be told to create several indexes and statistics that are quite similar. But perhaps that's a result of asking the tool about just one query - it calculates anything that will help that? Thank you for the advice on statistics. If the white paper descibes them adequately then I suspect it will be difficult to read, but I should apply time to it.
Back to comp.databases.ms-sqlserver | Previous | Next — Previous in thread | Next in thread | Find similar
Elementary management of many indexes, best practice? rja.carnegie@gmail.com - 2013-03-12 07:48 -0700
Re: Elementary management of many indexes, best practice? Erland Sommarskog <esquel@sommarskog.se> - 2013-03-12 22:36 +0100
Re: Elementary management of many indexes, best practice? rja.carnegie@gmail.com - 2013-03-15 19:23 -0700
Re: Elementary management of many indexes, best practice? Erland Sommarskog <esquel@sommarskog.se> - 2013-03-16 12:32 +0100
Re: Elementary management of many indexes, best practice? rja.carnegie@gmail.com - 2013-03-16 14:12 -0700
Re: Elementary management of many indexes, best practice? Erland Sommarskog <esquel@sommarskog.se> - 2013-03-16 23:08 +0100
Re: Elementary management of many indexes, best practice? Mark D Powell <Mark.Powell2@hp.com> - 2013-03-27 11:20 -0700
csiph-web