Regarding Oracle SCN Issue/Infoworld article
- From: "Taylor, Chris David" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
- To: "'pioro1@xxxxxxxxx'" <pioro1@xxxxxxxxx>, "'rjoralist2@xxxxxxxxxxxxxxxxxxxxx'" <rjoralist2@xxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 20 Jan 2012 07:21:39 -0600
Marcin - are you saying that you confirmed a local created copy of an oracle
database could generate the SCN problem on a remote database?
A coworker asked me about this same scenario:
- Malicious user creates a local Oracle database (say, XE) and connects it to a
remote corporate database via database link
- User then artificially raises the SCN in his local database and connects to
the remote, corporate database
- User creates a transaction to the remote database
In *theory* the remote Oracle database should REJECT this transaction because
the SCN number is now too high and return an error back to the remote database.
Oracle metalink note: 1376995.1 basically says as much:
"...
...
Generally if the database does try to exceed the current maximum SCN value, the
transaction that caused this event would be cancelled by the database, and the
application would see an error. The next second the limit increases, so
typically the application then continues with a slight hiccough in processing."
...
...
So in some cases, databases experienced rapidly decreasing SCN headroom not
because of a bug in that specific database, but because the bug was active in
one or more of the databases that database was connected to. Since the database
always rejects SCNs that exceed the current maximum SCN, the provision of being
able to run Oracle Databases for more than 500 years was not affected in any of
the cases."
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 Marcin Przepiorowski
Sent: Wednesday, January 18, 2012 9:15 AM
To: rjoralist2@xxxxxxxxxxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: infoworld call
On Tue, Jan 17, 2012 at 6:00 PM, Rich Jesse
<rjoralist2@xxxxxxxxxxxxxxxxxxxxx<mailto:rjoralist2@xxxxxxxxxxxxxxxxxxxxx>>
wrote:
> Ray writes:
>
>> infoworld say this bug is really ugly.
>
> Well that certainly does sound potentially ugly. And it describes the
> reason behind the 16K/s transaction limitation that was discussed here
> a few years back.
>
> At least I have my SCN growth patterns for about a year now and we
> won't even hit 80B in the next 10 years. At current rates. Provided
> nothing else changes. Ever...
I think it is ugly - I was able to prepare new XE database with quite huge SCN
(MOS check from [ID 1393363.1] reported Result: C - SCN Headroom is low) and
after that simple DB link allow me to propagate that SCN to other database
using user account.
regards,
--
Marcin Przepiorowski
http://oracleprof.blogspot.com
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
