Re: infoworld call
- From: Riyaj Shamsudeen <riyaj.shamsudeen@xxxxxxxxx>
- To: ChrisDavid.Taylor@xxxxxxxxxxxxxxx
- Date: Fri, 20 Jan 2012 15:36:39 -0600
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
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
