Hey Guys,
I don't know much about SQL Server maintenance. Any tips for me?
The problem we have most often is that the log file grows really quickly and needs to be manually truncated by myself.
Usually when there's barely any room left.

Any pointers, things i should lookout for?  I read about SQL Mail, so i will have to figure out how to set that up.

Thanks

Not sure about maintenance but one tip a SQL guy gave me is always update your tables if you have speed issues.  I think that is what he said, anyone able to correct me if I got that wrong?

---

cheers
Andy

murcielago:

Hey Guys,
I don't know much about SQL Server maintenance. Any tips for me?
The problem we have most often is that the log file grows really quickly and needs to be manually truncated by myself.
Usually when there's barely any room left.

Any pointers, things i should lookout for?  I read about SQL Mail, so i will have to figure out how to set that up.

Thanks

Without any real knowledge of the database, I would suggest against manually truncating the log.  For reliability reasons mostly.  If you back up the database it will truncate the log for you.  Backup the database in the Maintenance Plan, that way you have reliability.

---

Steve Syfuhs
www.syfuhs.net
--
An expert is one who knows more and more about less and less, until they know absolutely everything about absolutely nothing.

AndyJG247:

Not sure about maintenance but one tip a SQL guy gave me is always update your tables if you have speed issues.  I think that is what he said, anyone able to correct me if I got that wrong?

Close.  Depends a lot on the design of the database.  The best design can run like crap on slow hardware, and the worst design WILL run slow on fast hardware.

[EDIT:]  Wow...just realized when this topic was created...lol.

---

Steve Syfuhs
www.syfuhs.net
--
An expert is one who knows more and more about less and less, until they know absolutely everything about absolutely nothing.

No probs, it is easily done. How close was it? It was said in the manner of "I got paid a fortune to go to a clients site and all I had to do was..." style

---

cheers
Andy

AndyJG247:

No probs, it is easily done. How close was it? It was said in the manner of "I got paid a fortune to go to a clients site and all I had to do was..." style

The idea is that 9 times out of 10 the tables are the reason for performance issues.  The data isn't normalized properly within the tables.  i.e. The Person's table has an address column that contains "123 fake street, Toronto Ontario, M8V2L2, Canada", whereas most times you want seperate columns for street, city, province/state, postal code, and country.  In the first case, if you needed just the postal code, you would have to do some string manipulation behind the scenes, which will ALWAYS take more time than say "SELECT PostalCode From Persons".  Doing manipulation on one entry doesn't use too much overhead, but doing it on a 1000, or a million, then it becomes an issue.

 So you were pretty much right on...going back to the "it depends" mentality though :)

 

Cheers

---

Steve Syfuhs
www.syfuhs.net
--
An expert is one who knows more and more about less and less, until they know absolutely everything about absolutely nothing.

So, having "Toronto Ontario" in your SQL tables slow everything down?

 

I worked for a time in a rather well-known DotCom that relied heavily upon SQL. I left after 8 months because I realized just how much I hated databases.

That being said, I just left the copnsulting biz where I had to do my fair share of fixing the "my database server seems slow" type of things and it was usually due to the Maintenance Plan not being enabled. Making that active and letting it truncate everything usually solved the problem.

---

"Buy the ticket, take the ride."
-HST

Heh, nice.  If that were the case I should have put Ottawa.  The problems with databases is that they are all different.  Yes there are best practices out there that kinda fit the mold of your database, but never perfectly.  You have to understand the inner workings of the database to apply best practices to it properly in some cases.  "The database is slow" can have millions of reasons why.  It's not usually any one specific thing.  It can be attributed to table structure or data normalization, or long running Maintenance Plans.  The answer to why databases run slow is "it depends".

---

Steve Syfuhs
www.syfuhs.net
--
An expert is one who knows more and more about less and less, until they know absolutely everything about absolutely nothing.