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).
Received on Tue Jun 03 2003 - 19:29:39 CDT
