March 5, 2014 at 4:29 am
Hi Sir,
i am sql dba, in my company i checked with daily(eventvwer,blocking issues,performance motoring,sql error logs and job) and weekly tasks (data base dta file sizes and log file sizes) and monthly i checked and i took the reports to sql security audit reports.
as a dba i am what i needs to verify the sql servers if you have not above any other verify to sql servers could you please tell me daily and weekly and monthly i needs to verify in my company sql servers and could you please tell me commands also. could you plz help me any one.
Thank you.
March 5, 2014 at 5:38 am
There isn't necessarily a list of daily/monthly/weekly tasks for all environments. The list you have is a fine place to keep track of your systems. If you are looking for more, perhaps capturing the queries that use the most resources and try to tune the queries, or experiment with new indexes.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 5, 2014 at 5:52 am
You already seem to have a decent list. But, to provide a means for validation, Jason Strate maintains a monthly checklist that he updates regularly. You can see the latest updates and a link for the list here[/url].
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
March 5, 2014 at 6:14 am
Steve Jones - SSC Editor (3/5/2014)
There isn't necessarily a list of daily/monthly/weekly tasks for all environments. The list you have is a fine place to keep track of your systems. If you are looking for more, perhaps capturing the queries that use the most resources and try to tune the queries, or experiment with new indexes.
I think this is a good idea. One of the things that could be helpful to you as a DBA is to get to know your data. If you know the usage patterns, know the data and have a feel for the code - you will be a better asset to the company.
How do you get to know the usage? By doing what Steve recommended - capturing some queries and identifying resource hogs or higher resource queries.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 5, 2014 at 6:25 am
in my daily task performance monitoring : what i needs to check performance monitoring in server.could you please tell me the performance monitoring list in server.
March 5, 2014 at 6:28 am
There are two things that no one mentioned that I believe are critical.
The first thing should be the backups. You should know when they're being taken and that they can be used if needed. This means figuring out when the full, differential and transaction log backups are taken and where they're being stored. It also means that you occasionally pull a backup and try to restore it. You don't want to restore over the top of the production one, but you do want to know that they're viable backups and can be restored. This will also give you practice doing a restore. Let's face it - you don't want your first restore to be you reading MSDN and fumbling around while the boss is breathing down your neck and you're not sure of anything.
The other thing to verify is drive space. How many servers ever have concerns about drive space? Without space available on the drives, things tend to fail quickly. Logs don't get written and data doesn't get saved. You don't want to overlook something so basic.
I completely agree about the top SQL hogs, and I am going to check out the article, but I think the backups and drive space are the place to start.
March 5, 2014 at 8:33 am
Ed Wagner (3/5/2014)
There are two things that no one mentioned that I believe are critical.The first thing should be the backups. You should know when they're being taken and that they can be used if needed. This means figuring out when the full, differential and transaction log backups are taken and where they're being stored. It also means that you occasionally pull a backup and try to restore it. You don't want to restore over the top of the production one, but you do want to know that they're viable backups and can be restored. This will also give you practice doing a restore. Let's face it - you don't want your first restore to be you reading MSDN and fumbling around while the boss is breathing down your neck and you're not sure of anything.
The other thing to verify is drive space. How many servers ever have concerns about drive space? Without space available on the drives, things tend to fail quickly. Logs don't get written and data doesn't get saved. You don't want to overlook something so basic.
I completely agree about the top SQL hogs, and I am going to check out the article, but I think the backups and drive space are the place to start.
+1 Million
--Jeff Moden
March 5, 2014 at 6:56 pm
I think the ideal situation is to set up automated monitoring to do most of that for you. Let the machines do the work as much as possible and alert you when there is a problem. I use a combination of home grown SQL jobs and Red Gate SQL Monitor, but there are many tools available.
Of course you should audit everything occasionally to make sure your monitors are working but I don't think there is ANYTHING that I do manually on a daily basis. If it's repetitive, it should be automated. Brent Ozar has a great script for auditing a database server which is a good supplement to the scheduled jobs and alerts.
--Andy
March 5, 2014 at 9:02 pm
And....Blitz! :w00t:
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply