Re: infoworld call
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "Riyaj Shamsudeen" <riyaj.shamsudeen@xxxxxxxxx>, <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
- Date: Sat, 21 Jan 2012 13:18:56 -0000
Riyaj,
Thanks for the link - I think that probably answers Chris' question.
The point I was making, without spelling out the details, is that I can set
my SCN to any arbitrarily high value that doesn't quite reach the breaking
point(which - ignoring timezone effects - is a universal breaking point for
all oracle systems) on my system and then push that value into your
system - but your system still won't break unless it then carries on
generating new SCNs at a rate higher than the limit that Oracle has coded,
which is 16,384 per second.
So it doesn't matter what the absolute value of the limit is, what matters
is whether or not one of your systems generates SCNs faster than Oracle
expects.
Riyaj,
On a trivial note - we don't need a special process, we already have the
AWR capture going on reading lots of data from dynamic performance views on
a regular basis; adding in a query against v$database would be sufficient,
recording the result and reporting it in the AWR would be a useful
diagnostic, and getting an alert if the jump is too high (in the log, and
via OEM) would be sufficient warning.
I don't think you can set an arbitrary limit at which the a jump will be
disallowed - but if you tried you would have to decide (implicitly) how
many SCNs per second was the legal maximum, so the current strategy (but
using a much larger limit) ought to be sense. A 64-bit SCN with an assumed
maximum of 1 billion (2^30) SCNs per second would give you 2^34 seconds of
life - which is about 545 years.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Oracle Core (Apress 2011)
http://www.apress.com/9781430239543
----- Original Message -----
From: "Riyaj Shamsudeen" <riyaj.shamsudeen@xxxxxxxxx>
To: <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
Cc: <jonathan@xxxxxxxxxxxxxxxxxx>; <oracle-l@xxxxxxxxxxxxx>
Sent: Friday, January 20, 2012 9:36 PM
Subject: Re: infoworld call
| Chris
| JL is talking about SCN soft limit. I blogged about SCN here:
| http://orainternals.wordpress.com/2012/01/19/scn-what-why-and-how/
|
| I think, to fix this issue completely, Oracle code should limit
| allowable SCN jump; Limit the jump to a day of SCN activity
| (24*16384*60*60). Risk with that approach is that a less activity
database
| might not connect to highly active database for a day or week. At that
time
| of a distributed transaction between these two databases, SCN jump might
| exceed few billions in the less active database and there will be ORA-600
| errors.
|
| Or may be that we need to have few thresholds: 4 hours of SCN jump (235
| million) a warning written to alert log, 12 hours of SCN jump ~700
million,
| an ORA- error written to alert log but not to the user, 24 hours of SCN
| jump reject it. There is a problem with this approach also, as a
malicious
| intruder will trigger the SCN jumps in increment of 200 million injecting
| the poison slowly and consistently. May be, another control that will not
| allow a cumulative SCN jumps over a certain limit :)
|
| Further, that SCN allocation part of the code executed highly
frequently.
| Any slowness will have massive performance issues too.
|
| Since, there are many (mostly unknown?) background processes anyway, we
| should get one more background process to monitor SCN growth :)
|
| Cheers
|
| Riyaj Shamsudeen
| Principal DBA,
| Ora!nternals - http://www.orainternals.com - Specialists in Performance,
| RAC and EBS
| Blog: http://orainternals.wordpress.com
| OakTable member http://www.oaktable.com and Oracle ACE Director
|
| Co-author of the books: Expert Oracle
| Practices<http://tinyurl.com/book-expert-oracle-practices/>,
| Pro Oracle SQL, Expert PL/SQL
| Practices<http://tinyurl.com/book-expert-plsql-practices>
|
|
|
| On Fri, Jan 20, 2012 at 1:17 PM, Taylor, Chris David <
| ChrisDavid.Taylor@xxxxxxxxxxxxxxx> wrote:
|
| > Jonathan,
| >
| > Can you clarify what you meant about 'your only protection'. I didn't
| > quite follow that piece.
| >
| > Thanks!
| >
| > Chris Taylor
| > Sr. Oracle DBA
| > Ingram Barge Company
| > Nashville, TN 37205
| >
| > "Quality is never an accident; it is always the result of intelligent
| > effort."
| > -- John Ruskin (English Writer 1819-1900)
| >
| > CONFIDENTIALITY NOTICE: This e-mail and any attachments are
confidential
| > and may also be privileged. If you are not the named recipient, please
| > notify the sender immediately and delete the contents of this message
| > without disclosing the contents to anyone, using them for any purpose,
or
| > storing or copying the information on any medium.
| >
| >
| > -----Original Message-----
| > From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
| > On Behalf Of Jonathan Lewis
| > Sent: Friday, January 20, 2012 11:03 AM
| > To: oracle-l@xxxxxxxxxxxxx
| > Subject: Re: infoworld call
| >
| >
| > Raising the limit to 2^64 won't help unless they also remove the
feature
| > that allows you to set the current SCN to an arbitrary multiple of
2^32, or
| > scale up the number of SCN increments so that a "genuine" job can't
| > possibly make them happen fast enough.
| >
| >
| > My laptop can advance the SCN about 150,000 times per second - which
means
| > it will take slightly less than 8 hours to get through 4 billion -
which
| > means that's the longest time it will take for me to prepare my laptop
to
| > be a threat. Your only protection comes from knowing confident that
your
| > system can't increment the SCN faster than Oracle's limiting rate
because I
| > have to start by injecting a value that is "behind" a critical value
and
| > let you run on from there.
| >
| >
| > Regards
| >
| > Jonathan Lewis
| > http://jonathanlewis.wordpress.com
| > Oracle Core (Apress 2011)
| > http://www.apress.com/9781430239543
| >
| >
| > ----- Original Message -----
| > From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
| > To: <dedba@xxxxxxxxxx>; <oracle-l@xxxxxxxxxxxxx>
| > Sent: Friday, January 20, 2012 3:46 PM
| > Subject: RE: infoworld call
| >
| >
| > They do indicate that this is in the plans at the bottom of MOS
1376995.1
| >
| > -----Original Message-----
| > From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
| > On Behalf Of De DBA
| >
| > <snip>
| > I would like to think that the hard limit in future versions will be
put at
| > a bit higher than a 48-bit integer...
| > <snip>
| >
| >
| > ________________________________
| >
| > Privileged/Confidential Information may be contained in this message or
| > attachments hereto. Please advise immediately if you or your employer
do
| > not consent to Internet email for messages of this kind. Opinions,
| > conclusions and other information in this message that do not relate to
the
| > official business of this company shall be understood as neither given
nor
| > endorsed by it.
| > --
| > //www.freelists.org/webpage/oracle-l
| >
| >
| >
| >
| > -----
| > No virus found in this message.
| > Checked by AVG - www.avg.com
| > Version: 2012.0.1901 / Virus Database: 2109/4754 - Release Date:
01/19/12
| >
| >
| > --
| > //www.freelists.org/webpage/oracle-l
| >
| >
| >
| >
| > --
| > //www.freelists.org/webpage/oracle-l
| >
| >
| >
|
|
|
| -----
| No virus found in this message.
| Checked by AVG - www.avg.com
| Version: 2012.0.1901 / Virus Database: 2109/4755 - Release Date: 01/20/12
--
//www.freelists.org/webpage/oracle-l
Other related posts:
