FAQ
I'm reading the Directory Service Integration and Deployment Guide
right now. I think we want to move from 3000+ tnsnames files to
centralized naming and integrating with Active Directory seems
plausibly sensible (suggestion as to why to avoid it whilst still
running on Windows welcomed). I come across this table comparing
directory services and relational databases.

Directories - read more frequently than written
Relational Databases - written more frequently than read.

My experience of RDBMS systems is just the opposite. So do folk agree
with the generalisation abve, or do you consider databases to be a
read-mostly environment?

--
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

Search Discussions

  • Nuno Souto at Aug 11, 2004 at 5:58 am

    Niall Litchfield apparently said,on my timestamp of 11/08/2004 8:52 PM:

    Directories - read more frequently than written
    Relational Databases - written more frequently than read.

    My experience of RDBMS systems is just the opposite. So do folk agree
    with the generalisation abve, or do you consider databases to be a
    read-mostly environment?
    Read-mostly. By far.

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Cary Millsap at Aug 11, 2004 at 6:48 am
    Read-mostly, I'd say by 5:1 or greater in most cases.

    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.

    Cary Millsap
    Hotsos Enterprises, Ltd.
    http://www.hotsos.com
    * Nullius in verba *

    Upcoming events:

    - Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte
    - SQL Optimization 101: 8/16 Minneapolis, 9/20 Hartford
    - Hotsos Symposium 2005: March 6-10 Dallas
    - Visit www.hotsos.com for schedule details...

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Nuno Souto
    Sent: Wednesday, August 11, 2004 6:03 AM
    To: oracle-l_at_freelists.org
    Subject: Re: Is it just me

    Niall Litchfield apparently said,on my timestamp of 11/08/2004 8:52 PM:
    Directories - read more frequently than written
    Relational Databases - written more frequently than read.

    My experience of RDBMS systems is just the opposite. So do folk agree
    with the generalisation abve, or do you consider databases to be a
    read-mostly environment?
    Read-mostly. By far.

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Niall Litchfield at Aug 11, 2004 at 7:48 am

    On Wed, 11 Aug 2004 06:52:21 -0500, Cary Millsap wrote:
    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.
    One of our developers, at a previous employer, was employed to write a
    business intelligence system. He did. Then the specifyer of the system
    complained that the system only emitted data that was dependent upon
    what he put into it. I think that Chris had great presence of mind to
    say "Well I *could* write you a system that returns random
    information, but I'm not sure it entirely fits with our corporate data
    management strategy"

    --
    Niall Litchfield
    Oracle DBA
    http://www.niall.litchfield.dial.pipex.com
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Connor McDonald at Aug 11, 2004 at 8:27 am
    Its like the "audit" facility on a system I've recently seen. ins/upd/del on every single table -
    every single row change logged to a single audit table which (in order to handle all tables) has
    columns (renamed to preserve anonymity)

    id number (surrogate key)
    dt date (timestamp)
    typ varchar (ins/upd/del)
    ta varchar2 (tablename)
    c1 varchar2(2000) first column of table

    c2 varchar2(2000) next column of table
    c3 varchar2(2000) next column of table
    ...
    ...
    c200 varchar2(2000) next column of table

    So now there's several hundred million records in there...Also a bit of bummer that pretty much
    any kind of analysis query simply never comes back within reasonable time frames (if it all...).

    Thus its data stored that will never be read :-)

    Niall Litchfield wrote:
    On Wed, 11 Aug 2004 06:52:21 -0500, Cary Millsap
    wrote:
    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.
    Connor McDonald
    Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
    ISBN: 1590592174

    web: http://www.oracledba.co.uk
    web: http://www.oaktable.net
    email: connor_mcdonald_at_yahoo.com

    Coming Soon! "Oracle Insight - Tales of the OakTable"

    "GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day"





    ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
    ----------------------------------------------------------------

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Nuno Souto at Aug 11, 2004 at 8:45 am

    Connor McDonald apparently said,on my timestamp of 11/08/2004 11:30 PM:
    Its like the "audit" facility on a system I've recently seen. ins/upd/del on every single table -
    every single row change logged to a single audit table which (in order to handle all tables) has
    columns (renamed to preserve anonymity)
    :) I can see we are in the same country! I just finished
    one that originally had a single audit table. All ins/upd/del
    PLUS all sel were logged!!!!!!!!! Table, data, user, function
    and screen used. Unreal.

    DB was nearing 100Gb, real data was about 35Gb.
    Needless to say, the deranged idea got knocked on the head
    in the new design. Still, took a while to convince them
    it was ludicrous! Previous Access users...

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Lisa Spory at Aug 11, 2004 at 12:19 pm
    Conner / Nuno,


    I am in the process of designing a audit capability myself and was considering a single table approach. In fact, Tom Kyte has an example of a single table approach on AskTom that I have found to be pretty nifty.


    http://asktom.oracle.com/pls/ask/f?p=4950:8:18330715232256760352::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:59412348055,


    Justification for a single table:


    I can create a configuration table with a list of tables/columns to be audited. Based upon changes to this table, I can dynamically generated new triggers. Our system aggressively pushes out new releases, most of which will introduce new data elements to be audited (and new columns to already audited tables). Therefore, an approach that logs each table history is a custom table will impose a huge sustainment burden.


    The trigger code calls the same package procedure regardless of table because the implementation of logging the audit is the same for every table and column. This allows me to auto-generate the triggers and maintain a single package of audit code.


    The reading of the system audit log will be very infrequent (1-2 times a year) and only supported through a formal customer request. Therefore, I had planned on partitioning the audit table by timestamp and sliding out data pretty frequently. Depending upon the report request, I figure that the required archived partitions could be restored in another location, and manipulated in any way to support the specific request.


    Thoughts? Comments?


    Also - Enjoy a Violet Crumble and some Chicken Twisties for me :-) I lived in WA from 1988-1992 and haven't had a chance to make it back yet, sure do miss it...


    Nuno Souto wrote:
    Connor McDonald apparently said,on my timestamp of 11/08/2004 11:30 PM:
    Its like the "audit" facility on a system I've recently seen. ins/upd/del on every single table -
    every single row change logged to a single audit table which (in order to handle all tables) has
    columns (renamed to preserve anonymity)
    :) I can see we are in the same country! I just finished
    one that originally had a single audit table. All ins/upd/del
    PLUS all sel were logged!!!!!!!!! Table, data, user, function
    and screen used. Unreal.

    DB was nearing 100Gb, real data was about 35Gb.
    Needless to say, the deranged idea got knocked on the head
    in the new design. Still, took a while to convince them
    it was ludicrous! Previous Access users...

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ---------------------------------
    Do you Yahoo!?
    Yahoo! Mail - 50x more storage than other providers!

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Nuno Souto at Aug 12, 2004 at 4:45 am
    Lisa Spory apparently said,on my timestamp of 12/08/2004 3:22 AM:

    Usual disclaimers apply: YMMV, IMHO, NWMD, NAWHTT, etcetc.
    Justification for a single table:
    If all you have to do is log that someone has touched a table,
    then maybe default Oracle auditing is enough?

    More detailed data activity logging (trigger-based) is only
    needed if you need to keep track of actual data moved into
    the table(s).

    I really don't like the idea of *extensive* logging into a single
    table: there is a bottleneck-waiting-to-happen, if I ever heard of 1...
    Note that Tom seems to indicate only light logging. Not data
    audit logging.
    I can create a configuration table with a list of tables/columns to be audited.
    Based upon changes to this table, I can dynamically generated new triggers.
    If you need more detailed logging, I'd look into fine-grained auditing
    in 9i. It does all that plus much more, and is presumably internalised
    (translate: fast, lesser locking issues).
    Our system aggressively pushes out new releases, most of which will introduce
    new data elements to be audited (and new columns to already audited tables).
    Therefore, an approach that logs each table history is a custom table will
    impose a huge sustainment burden.
    You'd be surprised at how easy fine-grained auditing really is nowadays...
    and it can be toggled on/off, changed, etc.
    Word of caution: try before using. I hit a few bugs a while ago in 8ir3
    with FG access control and had to use views plus some contrived authorisations
    to get around obvious breaks in security. The same might apply to FG auditing!
    I do recall restrictions.
    The reading of the system audit log will be very infrequent (1-2 times a year)
    and only supported through a formal customer request.
    In that case, look at auditing via archived redo logs (log miner)?
    And make the customer requesting it pay for the time involved?
    I mean why pay for the audit overhead ALL the time when it is only going
    to be looked at ONCE or twice a year? Just pay for it then? Just keep your
    schema exports and archive logs handy.
    Thoughts? Comments?
    You got them.
    Also - Enjoy a Violet Crumble and some Chicken Twisties for me :-)
    NOW you tawkin! :)

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Lisa Spory at Aug 12, 2004 at 7:46 am

    In response to Nuno's reply, on my timestamp Thu, 12 Aug 2004 19:49:34:


    If all you have to do is log that someone has touched a table,
    then maybe default Oracle auditing is enough?
    No, I need to audit insert, update and delete operations on subset of tables and columns, tracking identity of the user that made the change and the old and new values.

    Note that Tom seems to indicate only light logging. Not data
    audit logging.

    Actually, Tom's example is data audit logging, his table structure defines who, table_name, column_name, and new and old values.

    really don't like the idea of *extensive* logging into a single
    table: there is a bottleneck-waiting-to-happen, if I ever heard of 1...

    I see your point here, however, can't this be addressed via freelists and initrans settings?

    If you need more detailed logging, I'd look into fine-grained auditing
    in 9i.


    Unfortunately, FGA in 9i only monitors Select statements, support for Insert/Update/Delete is not added until 10g. (We can't upgrade yet)

    In that case, look at auditing via archived redo logs (log miner)?
    And make the customer requesting it pay for the time involved?
    I mean why pay for the audit overhead ALL the time when it is only going
    to be looked at ONCE or twice a year? Just pay for it then? Just keep your
    schema exports and archive logs handy.

    Good point, however, I am required to track WHO made the change. Which means at the time of the triggering event I will have to grab the user ID from the application context (presumably set by the middle tier - another problem altogether).


    Thanks for you comments and ideas. I also looked into Workspace Manager, but we have a legacy application that requires that an empty, non-Oracle database schema structure "lay on top" - bottom line I can't rename tables and use views to "trick" the legacy code.


    Regards,


    Lisa Spory
    In Humid, Rainy Washington DC

    Nuno Souto wrote:
    Lisa Spory apparently said,on my timestamp of 12/08/2004 3:22 AM:

    Usual disclaimers apply: YMMV, IMHO, NWMD, NAWHTT, etcetc.
    Justification for a single table:
    If all you have to do is log that someone has touched a table,
    then maybe default Oracle auditing is enough?

    More detailed data activity logging (trigger-based) is only
    needed if you need to keep track of actual data moved into
    the table(s).

    I really don't like the idea of *extensive* logging into a single
    table: there is a bottleneck-waiting-to-happen, if I ever heard of 1...
    Note that Tom seems to indicate only light logging. Not data
    audit logging.
    I can create a configuration table with a list of tables/columns to be audited.
    Based upon changes to this table, I can dynamically generated new triggers.
    If you need more detailed logging, I'd look into fine-grained auditing
    in 9i. It does all that plus much more, and is presumably internalised
    (translate: fast, lesser locking issues).
    Our system aggressively pushes out new releases, most of which will introduce
    new data elements to be audited (and new columns to already audited tables).
    Therefore, an approach that logs each table history is a custom table will
    impose a huge sustainment burden.
    You'd be surprised at how easy fine-grained auditing really is nowadays...
    and it can be toggled on/off, changed, etc.
    Word of caution: try before using. I hit a few bugs a while ago in 8ir3
    with FG access control and had to use views plus some contrived authorisations
    to get around obvious breaks in security. The same might apply to FG auditing!
    I do recall restrictions.
    The reading of the system audit log will be very infrequent (1-2 times a year)
    and only supported through a formal customer request.
    In that case, look at auditing via archived redo logs (log miner)?
    And make the customer requesting it pay for the time involved?
    I mean why pay for the audit overhead ALL the time when it is only going
    to be looked at ONCE or twice a year? Just pay for it then? Just keep your
    schema exports and archive logs handy.
    Thoughts? Comments?
    You got them.
    Also - Enjoy a Violet Crumble and some Chicken Twisties for me :-)
    NOW you tawkin! :)

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Connor McDonald at Aug 12, 2004 at 8:04 am
    I haven't tried this so take this with a grain of salt...

    How about creating materialized view logs on the tables that need auditing, using the "including
    ..." clause to capture all of the rows? I'm not sure whether this would capture enough info for
    you ...

    hth
    connor

    Lisa Spory wrote:
    In response to Nuno's reply, on my timestamp Thu, 12 Aug 2004 19:49:34:
    If all you have to do is log that someone has touched a table,
    then maybe default Oracle auditing is enough?
    No, I need to audit insert, update and delete operations on subset of tables and columns,
    tracking identity of the user that made the change and the old and new values.
    [snip]>

    Connor McDonald
    Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
    ISBN: 1590592174

    web: http://www.oracledba.co.uk
    web: http://www.oaktable.net
    email: connor_mcdonald_at_yahoo.com

    Coming Soon! "Oracle Insight - Tales of the OakTable"

    "GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day"





    ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
    ----------------------------------------------------------------

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 12, 2004 at 8:10 am
    Hi Lisa,
    Although you said you can't update to 10g yet, I just got a brainfart
    that _might_ be helpful in a 10g environment and can be adopted to 9i as
    well. I have not tested this, so I cannot go into detail about all
    consequences, but by chance I will elaborate on the idea some time in
    the future. Of course, I encourage anyone to do this testing and share
    the results.

    When enabling flashback, you are able to peek into old and new values of
    a column in the (near) past using flashback queries. The trigger for the
    logging can just push a message in a queue, containg the user involved,
    table, rowid and timestamp or SCN. The job handling the queue will
    retrieve old and new values using flashback, and write the proper audit
    trail info into the logtable. Of course one of the assumptions is that
    the serialization isn't moved from the insert in the logtable to the
    adding of the message to the queue. Furthermore, the savings on the
    inserts in the logtable have to outweigh the cost of the extra I/O
    involved with flashback, and the processing of the queue. The whole idea
    is just making the logging asynchronous, without risking the loss of
    information. AQ can be of great help doing that. I think that adding the
    extra info of columns and old/new values to the message might make this
    working for 9i as well. Of course I would only go this way when the
    logging becomes a bottleneck. When the system works fine, don't change
    it. I wouldn't encourage you to introduce more complexity, although I'm
    a director of a (small) Oracle consultancy company as well;-).

    Just my $0.02.

    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    On Thu, 2004-08-12 at 14:45, Lisa Spory wrote:

    Actually, Tom's example is data audit logging, his table structure defines who, table_name, column_name, and new and old values.
    really don't like the idea of *extensive* logging into a single
    table: there is a bottleneck-waiting-to-happen, if I ever heard of 1...

    I see your point here, however, can't this be addressed via freelists and initrans settings?
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Tanel Põder at Aug 12, 2004 at 8:19 am
    Hi!

    Just a note, for auditing a high-load environment, I've few times used an
    "auditing server" concept which means a different database on a different
    secure physical server, which reads production databases archivelogs using
    logminer and where to OS audit trail is also directed...

    This kind of auditing doesn't put practically any extra load on to
    production server (except in cases SQL auditing has to be implemented or
    supplemental log data is needed)..

    Tanel.

    Original Message -----
    From: "Carel-Jan Engel"
    To:
    Sent: Thursday, August 12, 2004 4:19 PM
    Subject: Re: Is it just me
    Hi Lisa,
    Although you said you can't update to 10g yet, I just got a brainfart
    that _might_ be helpful in a 10g environment and can be adopted to 9i as
    well. I have not tested this, so I cannot go into detail about all
    consequences, but by chance I will elaborate on the idea some time in
    the future. Of course, I encourage anyone to do this testing and share
    the results.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Nuno Souto at Aug 12, 2004 at 8:29 am

    Tanel P=F5der apparently said,on my timestamp of 12/08/2004 11:22 PM:

    Just a note, for auditing a high-load environment, I've few times used = an
    "auditing server" concept which means a different database on a differe= nt
    secure physical server, which reads production databases archivelogs us= ing
    logminer and where to OS audit trail is also directed...
    =20
    This kind of auditing doesn't put practically any extra load on to
    production server (except in cases SQL auditing has to be implemented o= r
    supplemental log data is needed)..
    =20
    That's a great idea : solves a problem I've got
    coming up. Mind if I use it?

    --=20
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Mark W. Farnham at Aug 12, 2004 at 8:43 am
    cool idea, but if the possibility of an insert bottleneck is the main topic
    at this point, if initrans (or ASSM) fails to keep the audit log from being
    a pacing object, I'm thinking either real partitioning or poor man's
    partitioning would solve this. Probably who and table_name are decent
    candidates for the partitioning (and of course you still gotta keep some
    sort of date thingy or rotate/grandfather synonyms so you don't die death by
    monolith.) If one user or table dominates the change stream so much that it
    alone is a problem, you'd special case that bad boy so its audit write
    bottleneck is no worse than the table or user itself.

    Still your idea is intriguing in a cache capacity sort of way. Hmm, does
    this imply that the flashback area itself will be the bottleneck? Not on the
    retrieval part that you pointed out you could do asynchronously, but the
    original write. I'm not sure, and flashback, although I think I get it
    theoretically, still seems a bit like magic or perpetual motion to me. I
    guess it is actually no worse than rollback segments or any implementation
    of undo in transactional requirements, just more functional. Okay, I guess
    it's not magic, excuse the stream of consciousness. Why the heck haven't we
    had flashback all along since v6?

    Now, for auditing, you would have to do the equivalent of the redo log
    freeze on new transactions if your queues got far enough behind that you
    were going to lose required old values from flashback you still needed for
    queued auditing. I need more coffee before I try to think about how you
    design the queue so you know at small cost whether certain flashback can be
    released. Ugh. Does that have the same issues as snapshot too old?

    It's still a cool idea, and my children's college bursars would thrill at
    the idea of me participating in a funded project to implement it.

    mwf

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Carel-Jan Engel
    Sent: Thursday, August 12, 2004 9:20 AM
    To: oracle-l_at_freelists.org
    Subject: Re: Is it just me

    Hi Lisa,
    Although you said you can't update to 10g yet, I just got a brainfart
    that _might_ be helpful in a 10g environment and can be adopted to 9i as
    well. I have not tested this, so I cannot go into detail about all
    consequences, but by chance I will elaborate on the idea some time in
    the future. Of course, I encourage anyone to do this testing and share
    the results.

    When enabling flashback, you are able to peek into old and new values of
    a column in the (near) past using flashback queries. The trigger for the
    logging can just push a message in a queue, containg the user involved,
    table, rowid and timestamp or SCN. The job handling the queue will
    retrieve old and new values using flashback, and write the proper audit
    trail info into the logtable. Of course one of the assumptions is that
    the serialization isn't moved from the insert in the logtable to the
    adding of the message to the queue. Furthermore, the savings on the
    inserts in the logtable have to outweigh the cost of the extra I/O
    involved with flashback, and the processing of the queue. The whole idea
    is just making the logging asynchronous, without risking the loss of
    information. AQ can be of great help doing that. I think that adding the
    extra info of columns and old/new values to the message might make this
    working for 9i as well. Of course I would only go this way when the
    logging becomes a bottleneck. When the system works fine, don't change
    it. I wouldn't encourage you to introduce more complexity, although I'm
    a director of a (small) Oracle consultancy company as well;-).

    Just my $0.02.

    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    On Thu, 2004-08-12 at 14:45, Lisa Spory wrote:

    Actually, Tom's example is data audit logging, his table structure defines
    who, table_name, column_name, and new and old values.
    really don't like the idea of *extensive* logging into a single
    table: there is a bottleneck-waiting-to-happen, if I ever heard of 1...

    I see your point here, however, can't this be addressed via freelists and
    initrans settings?
    >

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Tanel Põder at Aug 12, 2004 at 9:15 am
    The problem with flashback is of course that you can't nor shouldn't go back
    in time too much using it.
    Imagine that even if you had 6 months worth of undo space, then when you'd
    want to flash back a very frequently modified block, all the undo blocks in
    given data block undo chain from present to requested point of time would
    have to be applied.

    This means lots of CPU + possibly many physical IOs for reading each of the
    old undo blocks in, just to get the old value of single row.. Also there is
    no possibility whatsoever to index a rollback segment (which, again, you
    might not want to do either, in order to keep the auditing overhead low)

    Nuno: You're welcome, but be sure to check logminers restrictions first
    (which I'm sure you do anyway;)

    Tanel.

    Original Message -----
    From: "Mark W. Farnham"
    To:
    Sent: Thursday, August 12, 2004 4:46 PM
    Subject: RE: Is it just me
    cool idea, but if the possibility of an insert bottleneck is the main topic
    at this point, if initrans (or ASSM) fails to keep the audit log from being
    a pacing object, I'm thinking either real partitioning or poor man's
    partitioning would solve this. Probably who and table_name are decent
    candidates for the partitioning (and of course you still gotta keep some
    sort of date thingy or rotate/grandfather synonyms so you don't die death by
    monolith.) If one user or table dominates the change stream so much that it
    alone is a problem, you'd special case that bad boy so its audit write
    bottleneck is no worse than the table or user itself.

    Still your idea is intriguing in a cache capacity sort of way. Hmm, does
    this imply that the flashback area itself will be the bottleneck? Not on the
    retrieval part that you pointed out you could do asynchronously, but the
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 12, 2004 at 9:43 am
    The idea is not using fashback as the audit trail, but use it very
    temporarily (seconds, or minutes at most) to provide the AQ-handler with
    actual information. When the queue cannot be handled within a very
    limited amount of time, I think flashback/AQ isn't the right solution
    either. I like the logminer thing very much. Extending that idea, one
    could also think of streams to put the logging in a separate database on
    another server.
    I worked for a lottery, where everything needed to be logged as well.
    The systems could only be reached through some management server,
    through personal ID's, (user oracle couldn't login, one could only sudo
    to it) and all keystrokes from the management server were logged on a
    blackbox with write-only disks (I think it was freeBSD based). This box
    wasn't approachable for internal sysadmins or DBA's or whatever.

    The logminer/streams thing can be used to achieve a similar separated
    environment. Might even help with meeting SOX-related requirements.....

    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===
    On Thu, 2004-08-12 at 16:19, Tanel Põder wrote:

    The problem with flashback is of course that you can't nor shouldn't go back
    in time too much using it.
    Imagine that even if you had 6 months worth of undo space, then when you'd
    want to flash back a very frequently modified block, all the undo blocks in
    given data block undo chain from present to requested point of time would
    have to be applied.

    This means lots of CPU + possibly many physical IOs for reading each of the
    old undo blocks in, just to get the old value of single row.. Also there is
    no possibility whatsoever to index a rollback segment (which, again, you
    might not want to do either, in order to keep the auditing overhead low)

    Nuno: You're welcome, but be sure to check logminers restrictions first
    (which I'm sure you do anyway;)

    Tanel.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Tanel Põder at Aug 12, 2004 at 9:57 am

    The idea is not using fashback as the audit trail, but use it very
    temporarily (seconds, or minutes at most) to provide the AQ-handler with
    actual information. When the queue cannot be handled within a very
    Ok, I should have read previous posts thoroughly before started acting
    wiseguy;)

    This FB/AQ one is quite interesting idea though and if you don't like AQ,
    you could implement it with autonomous triggers and custom message
    polling/handling solution.

    Tanel.

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 12, 2004 at 10:10 am
    Before AQ was there, I built my own version using dbms_alert messaging
    combined with a message table. The alert gets sent at commit-time.
    Otherwise dbms_pipe can help.
    The handler was just waiting for an alert, en when it was received, it
    started to empty the queue at a moderate rate. When the queue was empty,
    it started sleeping waiting again. I just don't like polling.
    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===
    This FB/AQ one is quite interesting idea though and if you don't like AQ,
    you could implement it with autonomous triggers and custom message
    polling/handling solution.

    Tanel.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Lisa Spory at Aug 12, 2004 at 10:24 am
    Logminer won't help me track the WHO, especially since in this case the who is obscured through connection pooling and only available to the database via an explicitly set application context.


    AQ or custom-built messaging systems are certainly cool and fun technology, but perhaps overkill?


    If I list partition by table_name, then how is the contention on my single table any different than having a separate table per table_name? (ignoring momentarily my desire to elegantly "slide" data off, which could be handled less elegantly to avoid contention issues instead).


    I need to poke around and gather numbers related to the number of concurrent transactions I expect to support as well, since again, I am not auditing the whole database, mostly setup/parameter data.


    Regards,


    Lisa


    Carel-Jan Engel wrote:
    Before AQ was there, I built my own version using dbms_alert messaging
    combined with a message table. The alert gets sent at commit-time.
    Otherwise dbms_pipe can help.
    The handler was just waiting for an alert, en when it was received, it
    started to empty the queue at a moderate rate. When the queue was empty,
    it started sleeping waiting again. I just don't like polling.
    Best regards,
    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===
    This FB/AQ one is quite interesting idea though and if you don't like AQ,
    you could implement it with autonomous triggers and custom message
    polling/handling solution.

    Tanel.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ---------------------------------
    Do you Yahoo!?
    Yahoo! Mail - 50x more storage than other providers!

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared.Still_at_radisys.com at Aug 12, 2004 at 11:22 am

    The idea is not using fashback as the audit trail, but use it very
    temporarily (seconds, or minutes at most) to provide the AQ-handler with
    actual information. When the queue cannot be handled within a very
    limited amount of time, I think flashback/AQ isn't the right solution
    either. I like the logminer thing very much. Extending that idea, one
    could also think of streams to put the logging in a separate database on
    another server.
    This would seem to be a good opportunity for someone to maliciously
    modify data, and delete the audit trail. The lack of audit trail
    could then be blamed on flashback not having the data due to high
    activity.

    Or even better, cause a storm of activity, or take advantage of
    a naturally occurring one ( Oracle Meteorologists? ) and ensure
    the the audit trail for the nefarious activity is never created.

    I admittedly know little yet about how flashback works, so maybe
    this none of this will work. I'm sure someone will point it out
    if so.

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • J.Velikanovs_at_alise.lv at Aug 12, 2004 at 8:54 am
    We have one customer who implemented few years ago auditing using AQ, like
    Carel-Jan Engel described. They have one auditing table and auditing
    stream realized thought AQ.
    At the moment, after some time in production, client is VARY unhappy with
    this solution.
    .
    Particularly with tow things:
    1. Maintenance of AQ administration overhead. One case for example: If for
    some reason reader process of AQ stopped for while, then the AQ supported
    table growing rapidly. After auditing process is up & running, WHM of AQ
    table still height.The performance of auditing process is unacceptable.
    They need to introduce production system unavailability for maintenance of
    this table (lower HWM).
    2. Serialization that is provided by this mechanism; overall auditing
    performance not so good, as they would like.
    .
    Jurijs
    On 12.08.2004 16:19:39 oracle-l-bounce wrote:

    Hi Lisa,
    Although you said you can't update to 10g yet, I just got a brainfart
    that _might_ be helpful in a 10g environment and can be adopted to 9i as
    well. I have not tested this, so I cannot go into detail about all
    consequences, but by chance I will elaborate on the idea some time in
    the future. Of course, I encourage anyone to do this testing and share
    the results.

    When enabling flashback, you are able to peek into old and new values of
    a column in the (near) past using flashback queries. The trigger for the
    logging can just push a message in a queue, containg the user involved,
    table, rowid and timestamp or SCN. The job handling the queue will
    retrieve old and new values using flashback, and write the proper audit
    trail info into the logtable. Of course one of the assumptions is that
    the serialization isn't moved from the insert in the logtable to the
    adding of the message to the queue. Furthermore, the savings on the
    inserts in the logtable have to outweigh the cost of the extra I/O
    involved with flashback, and the processing of the queue. The whole idea
    is just making the logging asynchronous, without risking the loss of
    information. AQ can be of great help doing that. I think that adding the
    extra info of columns and old/new values to the message might make this
    working for 9i as well. Of course I would only go this way when the
    logging becomes a bottleneck. When the system works fine, don't change
    it. I wouldn't encourage you to introduce more complexity, although I'm
    a director of a (small) Oracle consultancy company as well;-).

    Just my $0.02.



    Best regards,

    Carel-Jan Engel
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Nuno Souto at Aug 12, 2004 at 8:27 am

    Lisa Spory apparently said,on my timestamp of 12/08/2004 10:45 PM:
    Actually, Tom's example is data audit logging, his table structure defines who, table_name, column_name, and new and old values.
    I got the impression it was only for a few tables.
    The original post/example dates from 2000. That's very early 9i days,
    mostly 8ir3 back then. Some of the later examples date to later versions,
    but I don't think that is what Tom had in mind when he wrote the original
    example. I'd say he was trying to mimic in 8i what could be done later
    on with other features.
    table: there is a bottleneck-waiting-to-happen, if I ever heard of 1...

    I see your point here, however, can't this be addressed via freelists and initrans settings?
    I don't think freelists + initrans is gonna help much
    once the load increases. If it is not that much of an active system,
    then it will probably be OK.

    Put it this way: average application touches around 4 tables/transaction.
    You're generating that many writes into this audit table X number of
    transactions/sec on the system. If it is a high throughput system,
    I can see a problem with a single table receiving as many writes as
    generated to all other tables...
    Can't you split by type of transaction or business function?

    The other thing could be to consider AQ like Tom proposes?
    Make all that logging happen asynchronously: build
    up a message with the before value, the after value,
    the user, timestamp, etcetc, then send it off (via
    trigger) to be processed when possible. Then you
    wouldn't have to worry as much about contention.
    Multiple queues, one per business function.
    will have to grab the user ID from the application context
    (presumably set by the middle tier - another problem altogether).
    Yup, and potentially a nasty one... Not all do that.

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 12, 2004 at 8:46 am
    Apologies, I should have read Tom's solution first. My AQ / flashback
    post appears not to be new.
    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===
    The other thing could be to consider AQ like Tom proposes?
    Make all that logging happen asynchronously: build
    up a message with the before value, the after value,
    the user, timestamp, etcetc, then send it off (via
    trigger) to be processed when possible. Then you
    wouldn't have to worry as much about contention.
    Multiple queues, one per business function.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Mark W. Farnham at Aug 11, 2004 at 10:43 am
    Good lord.

    I may have to hide for defending this notion for certain audit required
    databases.

    But this is exactly the type of "you never hope to have to read it" data
    that screams to be segmented and rotated by date.

    (Notice I didn't beg the question by dictating partitioning, which might be
    complication overkill.)

    CREATE OR REPLACE SYNONYM functionality facilitates rotating or aging actual
    underlying tables quite nicely if you can live with a slightly fuzzy date
    boundary.

    This, combined with read only and offline tablespaces can be used to create
    an audit system that is actually feasible to query for specific time ranges,
    and practical to maintain for a long time (7 years has some meaning in the
    US, 25 (groan!) for EPA stuff) until forensics might be required.

    PS: I note that you didn't build it Connor, you just saw it and probably
    recoiled in horror at the waste (or possibly smiled curiously at the irony)
    of it being created such that it was a useless waste.

    mwf

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Connor McDonald
    Sent: Wednesday, August 11, 2004 9:31 AM
    To: oracle-l_at_freelists.org
    Subject: Re: Is it just me

    Its like the "audit" facility on a system I've recently seen. ins/upd/del
    on every single table -
    every single row change logged to a single audit table which (in order to
    handle all tables) has
    columns (renamed to preserve anonymity)

    id number (surrogate key)
    dt date (timestamp)
    typ varchar (ins/upd/del)
    ta varchar2 (tablename)
    c1 varchar2(2000) first column of table

    c2 varchar2(2000) next column of table
    c3 varchar2(2000) next column of table
    ...
    ...
    c200 varchar2(2000) next column of table

    So now there's several hundred million records in there...Also a bit of
    bummer that pretty much
    any kind of analysis query simply never comes back within reasonable time
    frames (if it all...).

    Thus its data stored that will never be read :-)

    Niall Litchfield wrote:
    On Wed, 11 Aug 2004 06:52:21 -0500, Cary Millsap
    wrote:
    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.
    Connor McDonald
    Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
    ISBN: 1590592174

    web: http://www.oracledba.co.uk
    web: http://www.oaktable.net
    email: connor_mcdonald_at_yahoo.com

    Coming Soon! "Oracle Insight - Tales of the OakTable"

    "GIVE a man a fish and he will eat for a day. But TEACH him how to fish,
    and...he will sit in a boat and drink beer all day"

    ___________________________________________________________ALL-NEW Yahoo!

    Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared.Still_at_radisys.com at Aug 11, 2004 at 1:00 pm

    Its like the "audit" facility on a system I've recently seen.
    ins/upd/del on every single table -
    every single row change logged to a single audit table which (in
    order to handle all tables) has
    columns (renamed to preserve anonymity)

    id number (surrogate key)
    dt date (timestamp) ...
    So now there's several hundred million records in there...Also a bit
    of bummer that pretty much
    any kind of analysis query simply never comes back within reasonable
    time frames (if it all...).

    Thus its data stored that will never be read :-)
    Connor, we all know what a jokester you are.

    You're making this up, right?;-)

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 11, 2004 at 2:39 pm
    That's what I call WOM - Write Only Memory

    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===
    On Wed, 2004-08-11 at 15:30, Connor McDonald wrote:

    Its like the "audit" facility on a system I've recently seen. ins/upd/del on every single table -
    every single row change logged to a single audit table which (in order to handle all tables) has
    columns (renamed to preserve anonymity)


    ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Mark W. Farnham at Aug 11, 2004 at 9:55 am
    Complete agreement, but I do have a special case answer to your wonder.

    Actually, a special class. Every useful system I'm aware of that stores
    information that is rarely read is functionally like the black boxes in
    airplanes.

    You never want to read it, but you've got to have it, and once in a while
    you have to read it.

    There is another class that is about 1:1, that being operational data stores
    where you capture, cleanse, aggregate and pass on to datamarts, warehouses,
    or whatever other buzzword has been recently generated.

    But that doesn't rise to your wonder about never retrieved.

    mwf
    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Cary Millsap
    Sent: Wednesday, August 11, 2004 7:52 AM
    To: oracle-l_at_freelists.org
    Subject: RE: Is it just me

    Read-mostly, I'd say by 5:1 or greater in most cases.

    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.

    Cary Millsap
    Hotsos Enterprises, Ltd.
    http://www.hotsos.com
    * Nullius in verba *

    Upcoming events:

    - Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte
    - SQL Optimization 101: 8/16 Minneapolis, 9/20 Hartford
    - Hotsos Symposium 2005: March 6-10 Dallas
    - Visit www.hotsos.com for schedule details...

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Nuno Souto
    Sent: Wednesday, August 11, 2004 6:03 AM
    To: oracle-l_at_freelists.org
    Subject: Re: Is it just me

    Niall Litchfield apparently said,on my timestamp of 11/08/2004 8:52 PM:
    Directories - read more frequently than written
    Relational Databases - written more frequently than read.

    My experience of RDBMS systems is just the opposite. So do folk agree
    with the generalisation abve, or do you consider databases to be a
    read-mostly environment?
    Read-mostly. By far.

    --
    Cheers
    Nuno Souto
    in sunny Sydney, Australia
    dbvision_at_optusnet.com.au
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Michael Fontana at Aug 11, 2004 at 2:27 pm
    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Cary Millsap
    Sent: Wednesday, August 11, 2004 6:52 AM
    To: oracle-l_at_freelists.org
    Subject: RE: Is it just me

    <>

    You've obviously never worked on a government contract before. Almost
    all of the data stored will by definition never be retrieved. It's
    stored because operational requirements or military standards dictate.

    On the other hand, all I have to do is drive around town. I see wildly
    successful self-storage businesses based upon the fact that people need
    to store stuff that they'll never retrieve, even if they are disinclined
    to admit it....

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 11, 2004 at 2:53 pm

    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.>>
    I used to work for a company that sold airport information systems. At a
    Swedish airport, they had a year with 600 more arriving aircraft than
    deprtures. They might still be looking for the aircraft wreckage.....

    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Mark W. Farnham at Aug 11, 2004 at 3:59 pm
    I'm guessing that was not just good planning to avoid drunk pilots on New
    Year's Day.....

    ... 600 sounds kinda high, even for the Air Force's mothball airport.

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Carel-Jan Engel
    Sent: Wednesday, August 11, 2004 4:03 PM
    To: oracle-l_at_freelists.org
    Subject: RE: Is it just me
    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.>>
    I used to work for a company that sold airport information systems. At a
    Swedish airport, they had a year with 600 more arriving aircraft than
    deprtures. They might still be looking for the aircraft wreckage.....

    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Mogens Nørgaard at Aug 11, 2004 at 4:10 pm
    Stealth-enabled aircraft could explain it. And vodka.

    Mark W. Farnham wrote:
    I'm guessing that was not just good planning to avoid drunk pilots on New
    Year's Day.....

    ... 600 sounds kinda high, even for the Air Force's mothball airport.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Carel-Jan Engel at Aug 11, 2004 at 5:34 pm
    Getting On Topic again, actually the answer was in bad datamodeling
    (what else). When the carriers invented code-sharing, relation between
    flight and aircraft suddenly was n:1. However, all flights needed to get
    displayed on the displays. So, the flight got simply duplicated with
    another flightnumber, and all updates were performed on both flights
    (from the application logic, what else. This was 1992). However, the
    cleanup process was not tested enough. Of course deleting departures
    was a completely different SQL than the SQL for deleting arrivals. They
    had to, because the AD_code column in the flighttable had another value;-). The favorite cut-and-paste development style. Only departures were
    rounded up, and arrivals of code-shared flights were left alone. Annual
    statistics revealed the unexpected surplus.
    Best regards,

    Carel-Jan Engel

    ===
    If you think education is expensive, try ignorance. (Derek Bok)
    ===
    On Wed, 2004-08-11 at 23:03, Mark W. Farnham wrote:

    I'm guessing that was not just good planning to avoid drunk pilots on New
    Year's Day.....

    ... 600 sounds kinda high, even for the Air Force's mothball airport.
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Peter Robson at Aug 12, 2004 at 4:00 am

    If you ever saw a system that was write-mostly over the long term, then
    there's data going in that's never coming out. You'd have to wonder why
    someone would pay money to store things that are never retrieved.>>
    This statement has been repeated several times in the thread now, and
    I cannot let it go unchallenged any longer.

    In essence, where a situation like this does exist, then yes, some
    fairly stern questions need to be asked. But it is very dangerous to
    generalise from the particular.

    For example - do you justify the books held in a library on the basis
    of the frequency with which they are accessed?

    In the digital environment - what about audit trailing sensitive
    transactions which one hopes will never have to be retrieved, but must
    always be retained just in case...

    In the BGS, we are charged by gov't to hold geological data (in both
    digital and analogue form) which goes back hundreds of years. Some of
    this stuff hasn't been accessed for years. Should we junk it? In the
    days of Mrs Thatcher, the answer was an emphatic 'yes', and moves
    commenced to do just this. Thank goodness sense prevailed before any
    lasting damage was done, but nevertheless we did lose some
    irreplaceable data.

    In the scientific world, the case for long term data retention, to the
    extent that there is a net inflow of data, is unassailable.

    As above - be careful out there....

    peter
    edinburgh

    --
    mailto:pgro_at_bgs.ac.uk

    *********************************************************************
    This e-mail message, and any files transmitted with it, are
    confidential and intended solely for the use of the addressee. If
    this message was not addressed to you, you have received it in error
    and any copying, distribution or other use of any part of it is
    strictly prohibited. Any views or opinions presented are solely those
    of the sender and do not necessarily represent those of the British
    Geological Survey. The security of e-mail communication cannot be
    guaranteed and the BGS accepts no liability for claims arising as a
    result of the use of this medium to transmit messages from or to the
    BGS. . http://www.bgs.ac.uk
    *********************************************************************

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Goulet, Dick at Aug 11, 2004 at 8:50 am
    Niall,

    With 3000+ tnsnames files running around you should have made the move =
    to Oracle names long ago. The migration to OID thereafter is very =
    simple, working on it, & then it does not involve AD at all.

    Dick Goulet
    Senior Oracle DBA
    Oracle Certified 8i DBA

    -----Original Message-----
    From: Niall Litchfield
    Sent: Wednesday, August 11, 2004 6:52 AM
    To: oracle-l_at_freelists.org
    Subject: Is it just me

    I'm reading the Directory Service Integration and Deployment Guide
    right now. I think we want to move from 3000+ tnsnames files to
    centralized naming and integrating with Active Directory seems
    plausibly sensible (suggestion as to why to avoid it whilst still
    running on Windows welcomed). I come across this table comparing
    directory services and relational databases.

    Directories - read more frequently than written
    Relational Databases - written more frequently than read.=20

    My experience of RDBMS systems is just the opposite. So do folk agree
    with the generalisation abve, or do you consider databases to be a
    read-mostly environment?

    --=20
    Niall Litchfield
    Oracle DBA
    http://www.niall.litchfield.dial.pipex.com

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/

    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org

    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
  • Niall Litchfield at Aug 11, 2004 at 9:28 am

    On Wed, 11 Aug 2004 09:54:21 -0400, Goulet, Dick wrote:
    Niall,

    With 3000+ tnsnames files running around you should have made the move =
    to Oracle names long ago. The migration to OID thereafter is very =
    simple, working on it, & then it does not involve AD at all.

    Dick Goulet
    Senior Oracle DBA
    Oracle Certified 8i DBA
    This is true. However when I tried it (8.1.5 and 7.3 days) I couldn't
    get it to work reliably. Of course back then all I knew about
    networking was that there were boxes with lights on involved, so it
    was probably down to me. Now I understand that there is electric
    string as well.

    As for AD, we already have that - we are windows only. I'm hoping that
    using AD makes good technological and business sense (we have AD
    experts as well as Oracle folk in house) for us.

    --
    Niall Litchfield
    Oracle DBA
    http://www.niall.litchfield.dial.pipex.com
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Peter Robson at Aug 11, 2004 at 9:56 am
    Yes





    sorry Niall ... :-) !

    --

    mailto:pgro_at_bgs.ac.uk

    This e-mail message, and any files transmitted with it, are
    confidential and intended solely for the use of the addressee. If
    this message was not addressed to you, you have received it in error
    and any copying, distribution or other use of any part of it is
    strictly prohibited. Any views or opinions presented are solely those
    of the sender and do not necessarily represent those of the British
    Geological Survey. The security of e-mail communication cannot be
    guaranteed and the BGS accepts no liability for claims arising as a
    result of the use of this medium to transmit messages from or to the

    BGS. . http://www.bgs.ac.uk
    *********************************************************************

    ----------------------------------------------------------------

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
  • Goulet, Dick at Aug 11, 2004 at 9:33 am
    Niall,

    I'm headed in the direction of OID. Reason is that mixing the Oracle =
    naming system with AD will introduce another responsible party who is =
    having enough trouble with maintaining DNS in AD right now. Sometimes =
    having responsibility spread around works out better and faster in the =
    first place.

    Dick Goulet
    Senior Oracle DBA
    Oracle Certified 8i DBA

    -----Original Message-----
    From: Niall Litchfield
    Sent: Wednesday, August 11, 2004 10:33 AM
    To: oracle-l_at_freelists.org
    Subject: Re: Is it just me

    On Wed, 11 Aug 2004 09:54:21 -0400, Goulet, Dick =
    wrote:
    Niall,
    =20
    With 3000+ tnsnames files running around you should have made =
    the move =3D
    to Oracle names long ago. The migration to OID thereafter is very =3D
    simple, working on it, & then it does not involve AD at all.
    =20
    Dick Goulet
    Senior Oracle DBA
    Oracle Certified 8i DBA
    This is true. However when I tried it (8.1.5 and 7.3 days) I couldn't
    get it to work reliably. Of course back then all I knew about
    networking was that there were boxes with lights on involved, so it
    was probably down to me. Now I understand that there is electric
    string as well.

    As for AD, we already have that - we are windows only. I'm hoping that
    using AD makes good technological and business sense (we have AD
    experts as well as Oracle folk in house) for us.

    --=20
    Niall Litchfield
    Oracle DBA
    http://www.niall.litchfield.dial.pipex.com

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Ron Rogers at Aug 12, 2004 at 12:50 pm
    Jared,
    I don't think that it is the amount of data changes even if they are
    caused by the Oracle meteorollgists, It depend on the undo_retention
    parameter
    and the size of the disk space available for the undo_tablespace.
    If the undo_retention is set to 1 hour then the undo data is saved for
    1 hour.
    The space used can be over written after that time frame. If the undo
    retention
    is set to days then the undo_tablespace will grow intil the time limit
    is reached
    or the disk fills up and then you have other problems.
    If you know the table that was maladjusted you can query the table
    with
    the SELECT * from tablename VERSIONS BETWEEN clause to see the
    difference
    in the data. To find out who made the changes you could use the info
    in the dba_transaction_query view.
    Ron
    Jared.Still_at_radisys.com 08/12/2004 12:26:06 PM >>>
    The idea is not using fashback as the audit trail, but use it very
    temporarily (seconds, or minutes at most) to provide the AQ-handler with
    actual information. When the queue cannot be handled within a very
    limited amount of time, I think flashback/AQ isn't the right solution
    either. I like the logminer thing very much. Extending that idea, one
    could also think of streams to put the logging in a separate database on
    another server.
    This would seem to be a good opportunity for someone to maliciously
    modify data, and delete the audit trail. The lack of audit trail
    could then be blamed on flashback not having the data due to high
    activity.

    Or even better, cause a storm of activity, or take advantage of
    a naturally occurring one ( Oracle Meteorologists? ) and ensure
    the the audit trail for the nefarious activity is never created.

    I admittedly know little yet about how flashback works, so maybe
    this none of this will work. I'm sure someone will point it out
    if so.

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared.Still_at_radisys.com at Aug 12, 2004 at 1:10 pm

    Jared,
    I don't think that it is the amount of data changes even if they are
    caused by the Oracle meteorollgists, It depend on the undo_retention
    parameter
    and the size of the disk space available for the undo_tablespace.
    If the undo_retention is set to 1 hour then the undo data is saved for
    1 hour.
    IIRC, there are no guarantees that Oracle will actually save the data
    for 1 hour. It will make a best effort, but a 'storm' of activity
    could subvert that.

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Tanel Põder at Aug 12, 2004 at 1:16 pm

    IIRC, there are no guarantees that Oracle will actually save the data
    for 1 hour. It will make a best effort, but a 'storm' of activity
    could subvert that.
    Btw, in 10g, there is..
    You just specify "retention guarantee" when creating an undo tablespace (or
    alter it later on).

    Tanel.

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared.Still_at_radisys.com at Aug 12, 2004 at 3:44 pm

    IIRC, there are no guarantees that Oracle will actually save the data
    for 1 hour. It will make a best effort, but a 'storm' of activity
    could subvert that.
    Btw, in 10g, there is..
    You just specify "retention guarantee" when creating an undo tablespace (or
    alter it later on).
    So, is this 'unbreakable'?

    Sounds like a challenge.;)

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Mark W. Farnham at Aug 12, 2004 at 10:06 pm
    It still ultimately has the usage profile of 'freeze transactions because we
    wrapped redo logs' if you run out of space to grow the flashback area.
    Presumably retention guarantee would have to be able to do the similar
    freeze until it could grow or the retention time limit is reached so stuff
    could get tossed. Even so, I still don't see how a time boundary could
    guarantee that the requisite copy out to audit tables was complete.

    In my thinking audit trails have to be Murphy aware, and this scenario just
    begs to be broken.

    mwf

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of
    Jared.Still_at_radisys.com
    Sent: Thursday, August 12, 2004 4:48 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Is it just me
    IIRC, there are no guarantees that Oracle will actually save the data
    for 1 hour. It will make a best effort, but a 'storm' of activity
    could subvert that.
    Btw, in 10g, there is..
    You just specify "retention guarantee" when creating an undo tablespace (or
    alter it later on).
    So, is this 'unbreakable'?

    Sounds like a challenge.;)

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

Related Discussions

People

Translate

site design / logo © 2022 Grokbase