January 23, 2015 at 5:40 am
No :blush:
I think I should Know more about these tools and performance Basics.
Thank you
January 23, 2015 at 11:43 am
sm_iransoftware (1/23/2015)
No :blush:I think I should Know more about these tools and performance Basics.
Thank you
If you really want to get into all that, I'd suggest picking up a copy of my book on query tuning.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 23, 2015 at 12:40 pm
Grant Fritchey (1/23/2015)
sm_iransoftware (1/23/2015)
No :blush:I think I should Know more about these tools and performance Basics.
Thank you
If you really want to get into all that, I'd suggest picking up a copy of my book on query tuning.
I've read the earlier version (actually, versions from two different publishers) of that book and did a "book report" on it... 5-by-5 all the way. It's a must read/must have so far as I'm concerned.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2015 at 12:58 pm
Jeff Moden (1/23/2015)
Grant Fritchey (1/23/2015)
sm_iransoftware (1/23/2015)
No :blush:I think I should Know more about these tools and performance Basics.
Thank you
If you really want to get into all that, I'd suggest picking up a copy of my book on query tuning.
I've read the earlier version (actually, versions from two different publishers) of that book and did a "book report" on it... 5-by-5 all the way. It's a must read/must have so far as I'm concerned.
Thank you sir!
We rearranged the newest version, breaking apart the chapters, so they're smaller, as well as adding a number of specific topics (I was doing the review of it last year when I realized I had only about 2 pages on bad parameter sniffing. I was mortified. Fixed that. Ha!). I think it's now a better book, but if anyone that reads it has feedback, I'm all ears.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 23, 2015 at 3:45 pm
sm_iransoftware (1/23/2015)
No :blush:I think I should Know more about these tools and performance Basics.
Thank you
Take a look at my previous post. It talks about a simple built-in tool to help find such queries. It's not the end-all to be all but it's a place for a person to start.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 24, 2015 at 1:00 am
I don't what these other guys are doing, but I would think the first step is finding Mr. Daniels a home before anything else. 😛
January 27, 2015 at 9:54 pm
SSC Rookie:
"1- Which Counters Do I control in performance monitor in first step?"
I use the Performance Monitor Data Collector Sets with a wide range of actual counters. I log these to a SQL table and then have custom stored procedures that pivot the data to what i need to focus on in that instance.
(everything from General Statistics to Wait Statistics to Network/CPU/Mem...lots)
"2- how to Use sql profiler for this check performance ?"
I have custom trace files that execute inside a SQL Job. These kick off every 15 minutes and collect data until x sized trace file if filled. Then dump that to a SQL table for analysis & alerts trigger if thresholds passed from prior data.
"3- what is spid performance ?"
I received a stored procedure from a Microsoft Engineer on a case i worked with them a couple years ago. It returns active SPID's related data. I log that to a SQL table and have alerts trigger off that also. Gives a real-time view into any issues.
February 12, 2015 at 6:42 am
IMHO I follows theses:
1- The DBA job was posted for a business reason. What it is? What management worries the most right now from their own eyes.
2- Next depending of the expected outcome (what you're in charge of), what are the greatest threat that could occurs that would put at risk the company.
I will probably get blame or flame at but depending of #1 & 2, backups are not always the first thing I would check first because I've not always been in a position that I was required to take care of the data.
For instance, supporting developers, one time, was my prime prerequisites. Backups were managed by someone else. I didn't bother a nanosecond with backups. I wasn't hire for that task.
Backup is usually the first answer because it supposed you're hire to maintain physical integrity and logical integrity of the data and a company without one of it's most valuable asset (data) is out of market. (Critical threat)
As I said this is my opinion, and my alone. You should know best why you've been hire for. If you feel management have overlook some issues, be proactive and write a small report telling what are the risks you've identified, how they are going to impact the business and how you propose to fix them or greatly lower the risk. Let then management choose what are the risks level they would accept and what consequences they are willing to take.
As an example for backups: most would say "are they taken" fine. Next step are the backup tested to be "restore-able" No? What are the risk not validating that?
Next, is there a procedure to take backups? Restore them? What would occurs when a disaster would occurs (when everyone's loosing head?) etc etc etc.
Have a nice day!
February 12, 2015 at 7:46 am
Under the Examine backups first area(I agree), I would recommend that you do restores as well. Fumbling around with EVERYONE looking over your shoulder is not the best impression. Build a little cheat sheet.
February 12, 2015 at 8:29 am
The first thing I would want is an inventory of the servers I am supposed to support. This could be as simple as a spreadsheet, an inventory database, or access to the CMDB if the shop has one. Also, I would want to know who my contacts are for server, storage, and network, security, and datacenter operations.
February 12, 2015 at 12:48 pm
I will first try to understand the environment I will manage, such as how many sql instances, SSAS/SSRS/SSIS instances I need to take care of, what are their version / editions. Then I will check other things, are there replications (if so, what types, merge, peer-to-peer etc?), log-shipping, mirroring, HAGs? In short, I need to know the environment from a high-level architecture perspective. Then I will do more detailed reviews, such as server-level/database-level configurations, backup plans, security, performance, # of dbs, size of dbs, table partition (if exists) maintenance etc.
In short, it will be of great use if you can do an inventory review of the environments you manage.
February 12, 2015 at 5:16 pm
Megistal (2/12/2015)
IMHO I follows theses:1- The DBA job was posted for a business reason. What it is? What management worries the most right now from their own eyes.
2- Next depending of the expected outcome (what you're in charge of), what are the greatest threat that could occurs that would put at risk the company.
I will probably get blame or flame at but depending of #1 & 2, backups are not always the first thing I would check first because I've not always been in a position that I was required to take care of the data.
For instance, supporting developers, one time, was my prime prerequisites. Backups were managed by someone else. I didn't bother a nanosecond with backups. I wasn't hire for that task.
Backup is usually the first answer because it supposed you're hire to maintain physical integrity and logical integrity of the data and a company without one of it's most valuable asset (data) is out of market. (Critical threat)
As I said this is my opinion, and my alone. You should know best why you've been hire for. If you feel management have overlook some issues, be proactive and write a small report telling what are the risks you've identified, how they are going to impact the business and how you propose to fix them or greatly lower the risk. Let then management choose what are the risks level they would accept and what consequences they are willing to take.
As an example for backups: most would say "are they taken" fine. Next step are the backup tested to be "restore-able" No? What are the risk not validating that?
Next, is there a procedure to take backups? Restore them? What would occurs when a disaster would occurs (when everyone's loosing head?) etc etc etc.
Have a nice day!
Understood and no blame or flame. Like you said, just my humble opinion. Even if I'm hired as "just" an Application DBA, I want to first know what the condition of the backups are because they will soon be preserving the work that I've just done. It will also give me a "lay of the land" so that I understand which servers are where.
If I'm hired as "just" a Database Developer, then I'm not so concerned although, having a full service bit of concern, I might still ask.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 12, 2015 at 5:17 pm
jeffrey yao (2/12/2015)
I will first try to understand the environment I will manage, such as how many sql instances, SSAS/SSRS/SSIS instances I need to take care of, what are their version / editions.
I find that checking for backups pretty much tells me all of that. Kills two birds with one stone.
Again... just an opinion.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 12, 2015 at 5:31 pm
Also, in addition to the excellent 7 point checklist and other suggestions above, I would check such things as:
TempDB being on a separate set of fast disk spindles.
TembDB not running close to being out of space.
Log files being on yet another set of fast disk spindles.
Run a query to find missing indexes. You can find more than one example of that online, but I run two different ones and compare.
I believe that Brent Ozar's Blitz.exe or sp_blitz will tell you such things as missing foreign key constraints, but if not, you may need to inquire about that and examine the databases for such things.
February 13, 2015 at 1:53 am
Adding to all the above, make sure I've an accessible but secure location to store my library of SQL scripts (every DBA should have one) and get them onto the system ready for use.
Then create server specific (and for the main databases, database specific) backup and restore scripts with the right drives for backup files, data and transaction logs - it saves time and blushes when you have to do one in a rush and forget that the data goes on K not D on this particular server and that there are twenty orphaned users to reconnect!
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply