Re: Archiving Data Strategies.
Council on Library and Information Resources http://www.clir.org/home.html - http://www.clir.org/pubs/issues/issues25.html#plan - -- http://www.clir.org/pubs/reports/rothenberg/contents.html Avoiding Technological Quicksand: Finding a Viable Technical Foundation for Digital Preservation by Jeff Rothenberg January 1998 Contents Preface Executive Summary Introduction The Digital Longevity Problem Preservation in the Digital Age The Scope of the Problem Technical Dimensions of the Problem The Inadequacy of Most Proposed Approaches Criteria for an Ideal Solution The Emulation Solution Research Required for the Emulation Approach Summary References ---end--- On 15 Apr 2002 at 9:49, [EMAIL PROTECTED] wrote: > Ian, > > I've put of replying to this for a couple of weeks now. I see that > no one else has replied either, at least to the list. > > Archiving data is a rather complex subject. ... > "Biddell, Ian" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 03/27/02 01:53 AM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > cc: > Subject:Archiving Data Strategies. > > > Hi All, > > I previously posted this question to the Lazydba List and got a couple > of replies, but thought I would also send it to this list as well to see > if I can just get a couple more (so excuses to those people that have > already seen it) > > I am currently discussing with a customer their requirements for > archiving data as their system is 4 years old and billing data is piling > up which obviously is affecting performance. I am pushing for an Oracle > upgrade, they are currently on 7.3.4 and I am trying to get them to go > to 9i. The main reason for this is so they can use partitioning. > > My question to the List is to try and find out other people's > experiences in archiving complex and integral data and whether most have > gone the partitioning path or some other path (ie. Something like > separate tables and data migration). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Eric D. Pierce INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Archiving Data Strategies.
Ian, I've put of replying to this for a couple of weeks now. I see that no one else has replied either, at least to the list. Archiving data is a rather complex subject. When data is taken offline and archived, there are a number of things to consider. * algorithms for archiving. Your application may already have this built in. If not, you will need to build it yourself. Archiving data with it's dependence on other data is not a simple task. There are 3rd party tools to aid in this. ( don't ask me which, I've never used one. I just know they're available ) * media life How long will the archive media survive? Nothing lasts forever. CDROM's have a useful life of about 20 years. ( don't throw away those vinyl LP's! ) Tape lasts 10-15 years. But that's only part of the problem. Will you have the hardware needed to read the format stored on tape or disk? Will the hardware still work? What if it breaks? You may not be able to fix it. * binaries You better keep versions of the binaries that are current with the archived data. Programs change over time. You won't be able to read 10 year old data with your current software. * data structures These are static. Do you think that you'll be able to load 10 year old data into your current data structures? Probably not. * legal requirements Are you legally required to keep records for a period of time? Accounting data for the last 7 years ( at least ) is usually needed for audits. Medical records must often be available for 15 years. * cost It's probably less expensive to leave your data online. --- As for as I'm concerned, data that has been archived is lost. Even if you do due diligence in all of the requisite areas, the chances of every seeing data are greatly reduced with time once it's archived and deleted from an online system. I just bought a very interesting book yesterday, "DARK AGES II - When The Digital Data Die" It's theme is the longevity of digital data. I'll post more when I've read it. Jared "Biddell, Ian" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/27/02 01:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject:Archiving Data Strategies. Hi All, I previously posted this question to the Lazydba List and got a couple of replies, but thought I would also send it to this list as well to see if I can just get a couple more (so excuses to those people that have already seen it) I am currently discussing with a customer their requirements for archiving data as their system is 4 years old and billing data is piling up which obviously is affecting performance. I am pushing for an Oracle upgrade, they are currently on 7.3.4 and I am trying to get them to go to 9i. The main reason for this is so they can use partitioning. My question to the List is to try and find out other people's experiences in archiving complex and integral data and whether most have gone the partitioning path or some other path (ie. Something like separate tables and data migration). So I would appreciate anyones comments, the path they chose, database size etc. With Thanks Ian Biddell -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Biddell, Ian INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Archiving Data Strategies.
It depends on Application and hardware availability like disk space. It is mix and match situation. With 7.3.4 neither you have partioning option nor to export old data using query option from source table and delete rows from that table. If you are talking about Oracle Financials database , it has it is own purge routines but even then we customize our own option to backup the data first and then running purge routines for AR / INV tables. Regards Rafiq Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Date: Wed, 27 Mar 2002 01:53:29 -0800 Hi All, I previously posted this question to the Lazydba List and got a couple of replies, but thought I would also send it to this list as well to see if I can just get a couple more (so excuses to those people that have already seen it) I am currently discussing with a customer their requirements for archiving data as their system is 4 years old and billing data is piling up which obviously is affecting performance. I am pushing for an Oracle upgrade, they are currently on 7.3.4 and I am trying to get them to go to 9i. The main reason for this is so they can use partitioning. My question to the List is to try and find out other people's experiences in archiving complex and integral data and whether most have gone the partitioning path or some other path (ie. Something like separate tables and data migration). So I would appreciate anyones comments, the path they chose, database size etc. With Thanks Ian Biddell -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Biddell, Ian INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). MOHAMMAD RAFIQ _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mohammad Rafiq INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Archiving Data Strategies.
Ian, Partitioning is a great way to archive stuff as long as there are no logical dependencies on it from data that will stay active. You're then able to convert the partition to archive table or just drop it if business rules allow. If you make sure that partitions are in separate tablespaces you also gain the ability to make the tablespace readonly or to use the transportable tablespace feature to move the data and plug it into an "archive" database. Regards, Mike Hately -Original Message- Sent: 27 March 2002 09:53 To: Multiple recipients of list ORACLE-L Hi All, I previously posted this question to the Lazydba List and got a couple of replies, but thought I would also send it to this list as well to see if I can just get a couple more (so excuses to those people that have already seen it) I am currently discussing with a customer their requirements for archiving data as their system is 4 years old and billing data is piling up which obviously is affecting performance. I am pushing for an Oracle upgrade, they are currently on 7.3.4 and I am trying to get them to go to 9i. The main reason for this is so they can use partitioning. My question to the List is to try and find out other people's experiences in archiving complex and integral data and whether most have gone the partitioning path or some other path (ie. Something like separate tables and data migration). So I would appreciate anyones comments, the path they chose, database size etc. With Thanks Ian Biddell -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Biddell, Ian INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hately Mike INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Archiving Data Strategies.
Title: RE: Archiving Data Strategies. As you say Ian partitioning is a obvious answer as I imagine the billing data will be quite easy to range partition using dates. However why go to 9i, 8i has many partitioning options and it may be an easier upgrade as well as a leap that management might find easier to agree to. Unfortunately removing data when there is a lot of RI involved can be quite complex and needs good knowledge of the schema and data dependencies. This knowledge is not always available and sometimes the cost in terms of man-hours is not one that management is prepared to pay. HTH John -Original Message- From: Biddell, Ian [mailto:[EMAIL PROTECTED]] Sent: 27 March 2002 09:53 To: Multiple recipients of list ORACLE-L Subject: Archiving Data Strategies. Hi All, I previously posted this question to the Lazydba List and got a couple of replies, but thought I would also send it to this list as well to see if I can just get a couple more (so excuses to those people that have already seen it) I am currently discussing with a customer their requirements for archiving data as their system is 4 years old and billing data is piling up which obviously is affecting performance. I am pushing for an Oracle upgrade, they are currently on 7.3.4 and I am trying to get them to go to 9i. The main reason for this is so they can use partitioning. My question to the List is to try and find out other people's experiences in archiving complex and integral data and whether most have gone the partitioning path or some other path (ie. Something like separate tables and data migration). So I would appreciate anyones comments, the path they chose, database size etc. With Thanks Ian Biddell -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Biddell, Ian INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). = This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. =
Archiving Data Strategies.
Hi All, I previously posted this question to the Lazydba List and got a couple of replies, but thought I would also send it to this list as well to see if I can just get a couple more (so excuses to those people that have already seen it) I am currently discussing with a customer their requirements for archiving data as their system is 4 years old and billing data is piling up which obviously is affecting performance. I am pushing for an Oracle upgrade, they are currently on 7.3.4 and I am trying to get them to go to 9i. The main reason for this is so they can use partitioning. My question to the List is to try and find out other people's experiences in archiving complex and integral data and whether most have gone the partitioning path or some other path (ie. Something like separate tables and data migration). So I would appreciate anyones comments, the path they chose, database size etc. With Thanks Ian Biddell -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Biddell, Ian INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).