Product Usage Scenarios

These critical issues cannot be solved ever without SQL CheckUp ...

Case 1

The IT director called his DBA John and said: Our business unit was extremely frustrated that the database was awfully slow in the morning. They couldn't access a vital information and the conference call with a critical client was ruined. They tried to divert the client, but eventually the client simply dropped off. What the heck was going on, John, with our databases? The case was escalated to VP. You have 15 minutes to report back with explanations ...
Two versions of the DBA's answer:
The DBA (in 15 minutes): ... I'm sorry, I don't know...
... or ...
The DBA (in 5 minutes, a relaxed tone): ... I found that actually the database server was absolutely ok, rather idle during the meeting time. First, there were no blocks on the system. Then, there was a low CPU utilization, much lower than the baseline, a low disk activity. You can see the charts in the email I just sent ...
Also I noticed that BatchRequests/sec on the server was way below the baseline ...
This makes us to conclude that there was an issue with the application server. There is a nice feature in SQL CheckUp called "Alert on deviation below baseline". I'm going to set it up to get alerted and to inform the application team if their server had issues ...
The IT director thanked the DBA for the very thorough report ...

Case 2

The DBA James got a low disk space alert on a drive hosting log file for critical applications. It was a warning initially and then a critical alert. The free space is going down rapidly. If not acting fast and appropriately, the critical applications might go down with all the sad consequences ...
Two versions of the DBA's actions:
The DBA starts sp_who and sees a bulk of connections and tries to figure out who is the culprit. The time is running fast and 3 web sites serving for critical applications are down. The phone starts ringing and he has no answers ... He feels like a nerd ...
... or ...
The DBA looks in SQL CheckUp in the drive properties and sees 3% of free space remaining, then looks in the list of database files on the drive and find that 5 of the files use 220 GB of the disk space with 215 GB being free inside the files. Because the used space is low, the SHRINKFILE is done in 60 seconds. Now the volume has 250 GB (23%) of free space and there is time to do some analysis at an easy pace and to identify the culprit. He sees that the log file space was growing rapidly in the last 15 minutes on a database called ServicesMarketing that is allocated on the drive. He looks in the list of Active Processes and sees that a stored procedure spUpdateClientList started to run 15 minutes ago against the database.
The DBA has now enough free space on the disk to allow the sp to proceed and a number of options to undertake if it keeps eating the free space. Also the DBA knows what application team to work with to prevent the issue with spUpdateClientList from happening again ...

Back to Top

Case 3

The IT manager asked his DBA Ryan to give him a report on when during the last week the database server ABC was down. He said that one of the applications complained that recently their Web Site was down too often. The worst part is that the web site is very popular and the application's criticality is too high ...
Two versions of the DBA's actions:
The DBA looks in SQL Server log trying to figure out when the database server might have been having issues and not responding. The more time he was spending the more he was scratching his head realizing that he can't provide exact answers ...
... or ...
The DBA looks in SQL CheckUp Responsiveness report and sees that the server was down once, 3 days ago on Sunday 5:34 am for 3 minutes...
He found that there was a memory issue and the server failed over to another node. Other than this case the server wasn't down a single time. The DBA even provided a by-minute response time report for the entire requested time frame. Though the IT manager was concerned about the Sunday morning issue, he was impressed with the sound report provided by his DBA. The IT manager noticed that recently his DBA Ryan always gives very exact answers supported by numbers rather than answers like "I guess...", "I think..." or "It seems to me..." ...

Back to Top

Case 4

An application team called and told the DBA Jason that their procedure just crashed with an error indicating that one table in the application database is missing. They asked if something was done with the database as somebody must've dropped the table...
Two versions of the DBA's actions:
The DBA says: "I have no idea". He hates to be in a defensive position, but all he can say is childish: "I did not do anything...". The app team replies that they would never drop the table. They call a meeting including high management to discuss the incident...
... or ...
The DBA looks in SQL CheckUp DB Usage reports for yesterday and sees that the table wasn't there yesterday either. He clicked on "BackInHistory" button few times and finally he found that the table was in place the last time 2 weeks ago.
It took 30 seconds to identify the day when the table was dropped. He checks the application calendar and sees that on that day the application had an implementation. Also in ActiveProcesses he found a batch with a statement dropping the table. When the application team folks checked their implementation scripts they found that the script mistakenly contained a code dropping the table. The application team manager called the DBA and thanked him for his help ...

Back to Top

Case 5

An application team asked the DBA Jeff to help in resolving an issue. The last night at 3:30 am their application crashed with a db error 1204 "The SQL Server cannot obtain a LOCK resource at this time". The application is highly critical as live users in other time zones use it. The application cannot afford another crash ...
Two versions of the DBA's answer:
The DBA says: Sorry, I don't know. I see the message "cannot obtain a LOCK resource" in the SQL Server log, but I can say nothing more... The application team asks the DBA's manager to help because the DBA is not able ...
... or ...
The DBA checks the memory map in SQL CheckUp and sees that the lock memory starts to increase gradually at 3:24 am and peaks at 3:40 am. It drops abruptly in 4 minutes...
He checks Active Processes log and sees an SP spGetCustomerList's start and end time perfectly corresponds with the lock memory deviation. Also the DBA sees in Active Processes details that executed command was INSERT. He locates the statement in the SP code to find what table the statement was working against. The table appeared having lock escalation disabled. The error has never happened before only because there had not been such high volume of data processed until now... The issue is solved in a matter of few minutes. The application team reported to the DBA's manager that his skill is superior and they are going to nominate him for the corporative The Best Expert award ...

Back to Top

Here is a video on simple 1-2-3 DBA's checks when addressing complaints about a SQL Server slowness. Within a couple of minutes the DBA does the checks and writes an email with details and illustrations on what he has discovered.

You might need to switch to Full screen for better perception.
This video shows how with SQL CheckUp the DBA can use the set up alerts, monitor disk space, drill down to the disk database files, see the files total and used space and find the quickest way to free the disk space under the time pressure. To understand why the disk space was used up so rapidly the DBA can jump to see the recent or historical performance counters for the drive, drill to the list of top IO consuming queries of the timeframes when the drive was experiencing the high activity. Also the DBA can see the charts of the drive and each drive database space usage trends. .

Watch more SQL CheckUp video demonstrations ...






Contact Us | Terms of Use | Privacy Policy | Site Map


Copyright 2010, VG Software. All Rights Reserved