Re: OT Discussion- Priority of Performance Tuning...

  • From: Kellyn Pot'vin <kellyn.potvin@xxxxxxxxx>
  • To: Fuad Arshad <fuadar@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 26 Oct 2011 11:00:02 -0700 (PDT)

I am often told I say what people need to hear, not what they want to hear and 
for a very good reason do I take this approach.  All too often, due to a short 
release window, an inaccurate estimate on development time required, etc. where 
I can foresee us doing something twice instead of doing it right and it is 
quite the pet peeve of mine.  I know they will be looking to the DBA's to "fix 
it, it's slow" soon enough.  I also agree that the database is always guilty 
until proven innocent.  It interacts with everything in the environment- 
hardware, network, application and the dreaded user... :)  I spend a lot of 
time with the developers helping them stop issues in development so it doesn't 
become a production database issue.  
I have a split environment where some products do not have a high impact if 
they take a bit longer to deliver, where our online products do have SLA's to 
respond with results in a certain amount of seconds.  If we take longer than 
that, doesn't matter if it's due to the fault of the ISP or other network 
issues, it's the database's fault.  Building right to begin with in this area 
is one where we have a tendency to demand... :)

Irony is, I just was given an employee award for some performance tuning that 
eased everyone's mind on delivery for our third quarter, where I had to admit, 
I felt others deserved it more because they released new products that 
delivered new revenue...  Even I am guilty of it... :)
 
Kellyn Pot'Vin
Sr. Database Administrator and Developer
DBAKevlar.com


________________________________
From: Fuad Arshad <fuadar@xxxxxxxxx>
To: kellyn.potvin@xxxxxxxxx; "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, October 26, 2011 11:46 AM
Subject: Re: OT Discussion- Priority of Performance Tuning...

I think its timelines and poor infrastructure .  i absolutely agree that 90% 
of 
performance tuning is politics.
when  developers are given 1 week timeline and very little design time to 
build 
an app .  App UI becomes priority not backend code.
I was once told by someone that its Capex that matters not Opex.  People want 
the upfront cost of an app to be low since its capital expenditure for  large 
projects.
the bug fixes and performance tuning  gets put into more operational 
expenditure 
and sometimes actually hides the true cost of a project.
Most of the times developers developer in a smaller environment  and have no 
access to how their app is going to look like to scale .
This  makes a select *  from x an  easier solution then a select * from x 
where 
x=y  since  it is only one row.
The problem is as DBA's we have to care about performance. We are the first 
line 
of questioning when the business says its slow.  They dont say the app is slow 
they say the db is slow since it retrieval or an update function that is 
happening . 

Often but not DBA's are caught in the cross fire of why wasnt this caught in 
dev 
or test  but not many realize that  a 2 row table with no indexes and a 2 
million row with no indexes will have a different data retrieval time.
Which is why i believe it is the DBA's business to be concerned about 
performance even if no one else is.





----- Original Message ----
From: Kellyn Pot'vin <kellyn.potvin@xxxxxxxxx>
To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Sent: Wed, October 26, 2011 12:16:42 PM
Subject: OT Discussion- Priority of Performance Tuning...

I am about to approve this comment out on my blog from one of my favorite DBA 
God's:
"Yep, like Cary is saying " 90% of performance tuning is politics". I am 
paraphrasing. Don't hold me to the exact quote or percentage.I don't understand 
"priorities for the business may not be the same as a priority for the 
DBAâ??s". 
If it is not a priority for the business why should it be a priority for the 
DBA? Politics work both ways. You are skating close to CTD. If nobody else 
cares 
about performance why should you?"
I respect his opinion and it did get me thinking about where performance tuning 
falls in the priority of tasks for most database environments.  I commonly am 
brought into places that have a history of bringing code/designs to production 
in a short time-span, business requirements and/or revenue demanding that 
everything works being more important than it working efficiently or performing 
well, then my job is to go in and correct this "little oversight".  

I honestly don't think it's intentional by the business to move poor performing 
or code that will only be able to sustain the business for a short period of 
time into production, it's just due to the demands of the business for many 
companies.  This does, however, make performance tuning a lesser priority in 
many environments, (and keeps me in demand and well employed... :))

As I specialize in this area, I now question the kind DBA's on the list to see 
if you also find performance tuning a lesser priority in the environments 
you've 
worked in.  I'm also curious what kind of environment it is, (private sector, 
retail, banking, government, etc..)  Just like disaster recovery and other 
tasks 
that DBA's may put a higher priority on, the business, as it does not always 
directly correspond to revenue, does not view as part of the goal...

Please feel free to email me directly if you wish to remain anonymous..


Kellyn Pot'Vin
Sr. Database Administrator and Developer
DBAKevlar.com
--
//www.freelists.org/webpage/oracle-l

--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 10-2011