RE: performance questions

I guess the issue is never that simple, but it seems that in the ideal world...

1. The company would define the SLA - It's the level of service they expect and require to operate their business successfully. Note: They define "successfully". For example the SLA might be "database recovery must complete within 8hrs of hardware becoming available" - the "hardware becoming available" is important if the SLA only applies to the DBA group since hardware availability is out of their control and should be covered under an SLA negotiated with the appropriate group.
2. The service provider can either accept the SLA or decline the contract.
3. If the company has done something which makes it impossible for the service provider to maintain the SLA then re-negotiation is required. Perhaps the service provider should have requested disclaimers on the SLA but I realise this never covers everything.

I think you need to firstly evaluate if the SLA's are appropriate for the relationship and responsibilities between the service provider and company. Perhaps they are too vague or poorly worded. If not, perhaps you need to refine the process of ensuring that new activities don't invalidate SLA's.

Regards,

      Mark.

PS: I guess I'm lucky that I'm not dealing with SLA's currently.

                                                                                                                                      
                      Sai Selvaganesan                                                                                                
                      <ssaisundar_at_sbcgl        To:       Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>                  
                      obal.net>                cc:                                                                                    
                      Sent by:                 Subject:  RE: performance questions                                                    
                      root_at_fatcity.com                                                                                                
                                                                                                                                      
                                                                                                                                      
                      04/06/2003 10:29                                                                                                
                      Please respond to                                                                                               
                      ORACLE-L                                                                                                        
                                                                                                                                      
                                                                                                                                      

hi
here is where the issue is:
"perhaps tuning is reqd,perhaps more hardware is reqd,perhaps SLA is wrong". exactly what i am trying to find. i do this when i "feel" that SLA is not viable ..but it would be great if i get stats on paper.

how do we renegotiate SLA? or how do we get a new value for SLA?

thanks
sai

• Mark Richard <mrichard_at_transurban.com.au> wrote:
  > I agree totally... Adding more databases to a
  > server doesn't invalidate a
  > negotiated SLA. If you can't meet the SLA then
  > someone has a problem.
  > Perhaps tuning is required, perhaps more hardware is
  > required, perhaps the
  > SLA is wrong and can be renegotiated. The issue
  > revolves more around
  > defining the SLA carefully and defining how to
  > resolve an SLA which is not
  > being met.
  >
  > If, for example, the networking guys destroy a
  > routing table and your
  > performance falls through the floor then the DBA
  > shouldn't be totally
  > responsible. The DBA might help to diagnose the
  > problem though.
  >
  > Personally I think the best way is to keep the SLA's
  > at a high level when
  > possible, such as "user can search for customer
  > within 5 seconds". The SLA
  > is realistic - it has a direct impact on someone's
  > ability to perform their
  > work, it is measurable - search for a customer, and
  > several things can be
  > done to help meet the SLA - add hardware, tune,
  > modify network config,
  > purge old data, etc.
  >
  > Regards,
  > Mark.
  >
  >
  >
  >
  >
  >
  >
  > DENNIS WILLIAMS
  >
  >
  > <DWILLIAMS_at_LIFETO To:
  > Multiple recipients of list ORACLE-L
  > <ORACLE-L_at_fatcity.com>
  > UCH.COM> cc:
  >
  >
  > Sent by:
  > Subject: RE: performance questions
  >
  > root_at_fatcity.com
  >
  >
  >
  >
  >
  >
  >
  >
  > 04/06/2003 01:24
  >
  >
  > Please respond to
  >
  >
  > ORACLE-L
  >
  >
  >
  >
  >
  >
  >
  >
  >
  >
  >
  >
  > Sai - I think the whole point is to open this up for
  > discussion /
  > negotiation. My suggestion would be to agree with
  > the business users on a
  > "typical" query and the response time they expect.
  > Ideally response time is
  > measured at the user's terminal. But if necessary
  > just for the database,
  > you
  > might get agreement on a typical query and the
  > response time.
  > As far as adding more stuff to the server, that
  > is the whole point. If
  > you can add more stuff and the SLA is maintained,
  > great! Everybody's happy.
  > But if you add users/instances/etc., and the SLA
  > suffers, now you have a
  > discussion point for the users. Either somebody can
  > buy another server, or
  > somebody can agree to a higher SLA, etc. The point
  > is that you're talking,
  > getting issues aired, rather than you guys saying
  > @#$% users and the users
  > saying @#$% DBAs.
  >
  >
  >
  > Dennis Williams
  > DBA, 80%OCP, 100% DBA
  > Lifetouch, Inc.
  > dwilliams_at_lifetouch.com
  >
  > -----Original Message-----
  > Sent: Tuesday, June 03, 2003 12:05 AM
  > To: Multiple recipients of list ORACLE-L
  >
  >
  > hi gurus
  >
  > this is a kind of query i have faced a few times in
  > the recent past and
  > which has really forced me to start this thread.
  >
  > as everyone knows, there is always what we call a
  > SLA or in other words a
  > service level agreement (may be called differently
  > in different places)
  > which infact means defining a time for any
  > transaction to go thru in the
  > database. This is very important in emvironments
  > which handle transactions
  > affecting sales or just normal queries against huge
  > databases which helps a
  > sales force or a front office customer support
  > force.. Defining this is
  > always a difficult task and i believe will keep
  > changing as time goes on -
  > factors like number of records,the number of
  > databases running on a
  > box(probably SLA was defined initially on a single
  > box-single db kind of
  > env
  > and now the same box has more
  > databases),memory,network,disk
  > performance,number of transactions or can i say the
  > load profile et al.
  > there have been cases where i have been asked
  > questions like why this query
  > took more time than SLA when it was running ok
  > sometime back. i find it
  > very
  > difficult to convince saying that ther! e are
  > factors affecting this and
  > not
  > just explain plan et al(correct me if i am wrong) or
  > in other words a
  > scenario that says my test environment is running
  > faster than prod
  > (everything on the db side are the same except the
  > way the disks are
  > configured or the load profile on both dbs).
  >
  > here is my question? is there a way to determine
  > this SLA. since it keeps
  > changing how do we really determine it. there is a
  > soltuion that comes
  > right
  > out saying abenchmark can help u do this but how do
  > we extrapolate or
  > assume
  > that there was no benchmark done at the beginning
  > how do we
  > validate/dtermine this magic number.
  > i have some ideas on this but nothing is very
  > concrete.
  >
  > can someone give me some feedback on this..if u feel
  > that this is not a
  > right question to be put in this forum i apologize
  > but i would like to take
  > this up with someone who is interested and i wouldnt
  > use this mailing list
  > for the same.
  >
  > thanks for ur time
  > sai
  >
  > --
  > Please see the official ORACLE-L FAQ:
  > http://www.orafaq.net
  > --
  > Author: DENNIS WILLIAMS
  > INET: DWILLIAMS_at_LIFETOUCH.COM
  >
  > Fat City Network Services -- 858-538-5051
  > http://www.fatcity.com
  > San Diego, California -- Mailing list and web
  > hosting services
  >
  

  ---

  
  > To REMOVE yourself from this mailing list, send an
  > E-Mail message
  >
  === message truncated ===

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Sai Selvaganesan
  INET: ssaisundar_at_sbcglobal.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   Privileged/Confidential information may be contained in this message.
          If you are not the addressee indicated in this message
       (or responsible for delivery of the message to such person),
            you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
           by reply e-mail or by telephone on (61 3) 9612-6999.
   Please advise immediately if you or your employer does not consent to
                Internet e-mail for messages of this kind.
        Opinions, conclusions and other information in this message
              that do not relate to the official business of
                         Transurban City Link Ltd
         shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mark Richard
  INET: mrichard_at_transurban.com.au

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).