Andrew Calvett - All Comments

Log Buffer #120: a Carnival of the Vanities for DBAs

Log Buffer #120: a Carnival of the Vanities for DBAs — Fri, 24 Oct 2008 16:25:12 GMT

Pingback from Log Buffer #120: a Carnival of the Vanities for DBAs

re: The overhead of a non-unique clustered index

ACALVETT — Wed, 22 Oct 2008 11:38:49 GMT

Hi Christian,

Thanks for your input. I've updated the post to make sure that its clear!

Cheers

Andrew

re: The overhead of a non-unique clustered index

Christian — Tue, 21 Oct 2008 18:52:14 GMT

Hi Andrew,

Its probably worth re-iterating that the uniqueifier (you have to love the MS devs for inventing new words) is only applied to non-unique rows not EVERY row.

I didn't know about the variable offset though, good call!

Christian Bolton

sqlblogcasts.com/.../christian

re: MS SQL Server Book of Wisdom

steveh99999 — Thu, 22 May 2008 10:53:30 GMT

A few more...

always put your transaction log on the same disk as your data. the disk has less distance to move then....

RAID mean redundant disks. Why waste money on disks which are redundant ?

Regularly test your DR plan but randomly pulling disks on your production system

instead of buying expensive new hardware. Use virtual server and allocate your databases extra disks this way...

SQL injection is only a problem if you insert data into your database. Disable all your triggers to get around this...

DBCC Checkdb - this is a really old command, no-one uses it anymore..

High availability is a waste of time and slows down performance.

adventureworks is important. never delete it...

SQL is more efficient if you write as much as your query on one line as possible. it's faster to parse....

re: MS SQL Server Book of Wisdom

robcarrol — Thu, 22 May 2008 10:27:38 GMT

LOL, very funny post :-)

re: MS SQL Server Book of Wisdom

ACALVETT — Thu, 22 May 2008 10:20:58 GMT

Or maybe we just don't get out enough. :D

re: MS SQL Server Book of Wisdom

steveh99999 — Thu, 22 May 2008 10:09:02 GMT

Your friend is a comedy genius ;)

Log Buffer #92: a Carnival of the Vanities for DBAs

Log Buffer #92: a Carnival of the Vanities for DBAs — Fri, 11 Apr 2008 16:48:43 GMT

Pingback from Log Buffer #92: a Carnival of the Vanities for DBAs

re: The Job whose owner kept coming back......

Larry Baldridge — Fri, 21 Mar 2008 13:56:10 GMT

This was spot on! My problem came because we use offshore consulting for management and we switched vendors, thus disabling old Windows Accounts. God, what a mess when you support 90 SQL Server 2005 boxes.

Thanks!

re: The Job whose owner kept coming back......

Eric — Tue, 05 Feb 2008 16:09:28 GMT

Nice! I had not thought of looking in syspackages90 for this info. Thanks!

re: The Job whose owner kept coming back......

Brian — Thu, 31 Jan 2008 21:42:05 GMT

Thanks for the solution, handy stuff. To think the owner of a maintenance plan can't be changed without this skulduggery, truly Microsoft-like.

re: My old mate sp_recompile

ACALVETT — Tue, 16 Oct 2007 12:57:29 GMT

Hi Damian,

Below is an extract for "Recompiling a Stored Procedure" in BOL.

It also occurs if an underlying table used by the stored procedure changes. But if a new index is added from which the stored procedure might benefit, optimization does not automatically happen (until the next time the stored procedure is run after SQL Server is restarted).

So basically, recompile never happens for index changes. They do for tables (which i do not make clear in my post) but i would still run recompile on tables.

re: My old mate sp_recompile

DamianMulvena — Tue, 16 Oct 2007 09:44:43 GMT

I thought the recompile was automatic when you changed an object or index. When is that not the case?

re: Server level VLF report

GrumpyOldDBA — Thu, 26 Jul 2007 09:04:28 GMT

Paul Randal covered this in April this year " crucial database main..." , sure you were there Tony ????? It can be quite difficult to bring this figure down on a production database - sometimes the only way is to actually remove the log file / drop the database into simple - not an easy task if your database is large or is almost 7 x 24. Paul indicated any figure over 50 was bad as far as I can remember.

re: Server level VLF report

tonyrogerson — Thu, 26 Jul 2007 06:39:43 GMT

Very useful Andrew - definitely be using that in the future - thanks.

My entry on VLF came from last weeks user group evening where somebody mentioned it was actually good to have lots of VLF's and use the default autogrowth settings - I just had to show that was wrong.

See you tomorrow evening at the SQLBlogsters meal!

Tony