Make your DBA's day..

I tend to find that Network Admin's and DBA's are the most territorial within IT Departments. They take more time to win over and always blame the "developer for bad code" when the database is questioned, or we get a response like "its not the network" when searching for a cause over TCP/IP. Both domains typically are secured to their group only, do not share the same priorities, goals or even tools.

 

Its time to change, Appinternals should be for for everyone!  No more silo's, share your tools and you will move in the same direction much quicker than ever. When I started using APM tools over 10 year ago, the main user groups were application support, we were guilty ourselves of not sharing our tools with other team members as it was a skill only we had or could even begin to understand.  Even in those days, Oracle, SQL or DB2 DBA's were very difficult to convince that anything was wrong with their databases...they took it personal, felt threatened, were used to being the goto person with all the answers or who saves the day! Times have changed huh!

 

10 years on, some departments are still like this and working in silo's - Appinternals has something for everyone,  so, give your DBA access, give them some simple queries to get them started and I assure you that the world will be a happier place. The network guys can use AppResponse if you have it...they'll like IP and Ports much better. AppInternals can help though. Get them to logon, type sql in the search bar and away they go...

 

This week I gave a small 30 minute intro to AppInternals for a set of DBA's and it took me back to my Wily days 10 years ago. The session was not to tell them they are doing a bad job, running poor plans, could do things any better as that will have got me nowhere - instead, it was about sharing.(my kids always say sharing is caring to me!)  They'd heard Riverbed can provide SQL performance information, that we can tell which application or instance has SQL related performance issues, we'd been on a few technical bridges together with every other technical expert from various teams. But they didn't have much idea how we knew...as far as they were concerned, they had the all the tools they needed to represent "database": OEM, Hotspot, Microsoft Management Tools, splunk/kibana and so on.

 

In 30 minutes, once I understood their challenges...which was mainly being blamed for everything(10 years ago they would have saved the day), I started to show them the in's and out's of AppInternals. The breadth of the data being collected spanned across multiple silo's and in a single UI could expose OS metrics, Application Instance performance, Network Conversations, Business Transaction Performance and break it all down into any combination we could think of...by server, by instance, by sql server, by user, by url, by webservice, by remote address, by class or method......how many, how long they took, how many exceptions...it gave them the source to their destination! The team did not realise they had piece missing to their jigsaw puzzle, so it was time to reshape the picture to fit it in.

 

The fact that we could precisely capture every SQL query, detect every exception, any ORA- or SQL Response Code, the time it was taking and then show them which class, method or parameter literally blew them away. They had the very proof that bad developer forms or validation in the application was the cause for so many bad SQL experiences or reports in logs files...furthermore, they could see when it started, to quickly correlate release or change etc.

 

We ran a few simple queries for ORACLE, this took up the rest of the session:

 

exception = '*ora-*' | timeseries -group_by exception -limit 10

(Show me the top 10 transactions, response time, count and exceptions with an ora- response code)

 

 

sql.png

 

Do the same with sql instead of exceptions:


exception = '*ora-*' | timeseries -group_by exception -limit 10


sql2.png


We did the same in a few combinations to show the power of slicing and dicing, performed the same queries over a week and a month etc:

exception = '*ora-*' | timeseries -group_by instance -limit 10

exception = '*ora-*' | timeseries -group_by server -limit 10

exception = '*ora-*' | timeseries -group_by class.method -limit 10

exception = '*ora-*' | timeseries -group_by remoteaddr -limit 10


The fact we could slice and dice so easily, look at the data over a huge time window so quickly at any angle - I assure you, will get your DBA's on side and make them feel empowered, they can find things for themselves and identify when behaviour changed. They'll feel like they did 10 years ago when they had all the answers!

 

We have another longer session planned next week where I'll show them the power of mapping transactions with SQL query. Imagine it, mapping transaction types to the queries, procedures or tables that they know better than anyone, I'll configure a few alerts and traps into ServiceNow so they are kept informed, whilst the agents do all the work.....I feel beers coming my way!


Note: Timeseries is just one of many cool analysis operators in appInternals, but its a great introductory operator by leveraging easy to understand measurements like transaction count, exception count and response times...three very important measurements, to start with anyway


Happy Thanks Giving.

 

This document was generated from the following discussion: Make your DBA's day..