Rarely are reports based off large snapshot variances helpful to a DBA unless you come across an odd situation such as this one…Better yet, we need to know a little bit about our AWR tables behind our reports so we can piece together what the reports leave out…:) Scenario: After-hours support has killed a session after high temp usage has occurred. You, as the primary DBA, are left to look into the issue the next day. Your first attempt to inspect the issue is through Enterprise Manager, (OEM) and you are surprised that very little activity is actually showing up…
-
-
I’ve spent the week updating, packing and communicating in preparation for my trip to Oracle Open World 2011. As with most folks that are attending, there is a lot to prepare for, but I have that added challenge of three kids who find this a fine opportunity to drive their father to distraction, as my ex-husband is responsible with managing their week, which he is unaccustomed to. Although I’m thankful for Google calendar that will tell my ex where and when each child has to be at all times, what homework, social events, etc., it is not a lot of fun for…
-
Users complained that a monthly financial report would no longer run SQLServer Reporting Services, (SSRS.) Upon investigation, it was found that this was a stored procedure that ran from one Annex database, sourcing from another and outer joins to a SQLServer database on a remote server through a linked server configuration. In attempts to run the report, my SQL Server Profile traces on both the source SQL Server and the remote SQLServer resulted in consistent sp_reset_connection results from the source and no activity in the remote. I ran my trusty and favorite script to tell me what processes were…
-
“Oh what tangled web we weave when complexity is added we can’t see…” How many times has complexity of design in an application, outside of the database, lead to the database blamed for slow performance? This is where a manager thanks the technical Gods for a DBA with great Sherlock Holmes skills to track down and prove the database not only innocent, but figure out what the real problem is. The database is guilty until proven innocent, we all know that, so when user’s come to the DBA and demands, “Why can’t I run this report? I should be able…