Ian - I have seen some of that in the general media. One problem is that if the information is extremely miniaturized so a lot of information can be stored in a small area, then some who discovers one of your artifacts may not realize something is written on it. The first clay tablets with cuneiform writing were tossed because they were assumed to be decorative tiles. An ingenious solution was to write in a spiral pattern on a disk and make the outer row large enough to be easily readable with the naked eye, then gradually reduce the character size. I thought that was clever. < obligatory Oracle reference > Of course Larry feels that Oracle will still be available then. </ obligatory Oracle reference >
Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Friday, November 08, 2002 1:15 PM To: Multiple recipients of list ORACLE-L I went to one meeting where someone from another DOE lab said they needed to store some data on media which would last 10,000 years. I suggested chisels and stone tablets :) Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -----Original Message----- Sent: Friday, November 08, 2002 9:14 AM To: Multiple recipients of list ORACLE-L Ron, Under ideal conditions, that is, controlled temperature, humidity and atmosphere, a CD has a lifespan of 30-200 years. In typical conditions, 5-50 years. CD's stored in a computer room might only last 10 years. In someone's desk, maybe only 5 years. On the visor of your car, probably not that long. ;) Jared On Friday 08 November 2002 04:48, Ron Rogers wrote: > Jay, > Remind the management that in the future there might also ba a change > of hardware and then the backups on tape could possible be useless and > unreadable by the new tape drives. If possible save the data to a text > delimited file and save the file. That wouls insure you that you would > always be able to at least read the information if needed. I have a > lot of data( from 1993- to - today) that someday will be archived , I > hope, and I can remove from the system. I will be saving it in text > format in CD's so it can be accessed if needed. We also are changing > to a new server and OS format. The old backup tapes are scrap now. > Planning on your part could be very helpfull down the road. > Ron > > >>> [EMAIL PROTECTED] 11/07/02 04:24PM >>> > > Well, if worst comes to worst we can always install an earlier version > on a box and import it there. > But the reason we can't get more storage approved still has me shaking > my > head... > > -----Original Message----- > Sent: Thursday, November 07, 2002 2:19 PM > To: Multiple recipients of list ORACLE-L > > > Jay, > > just make sure you are not around when, after several Oracle upgrades, > and they want to "import" one of these files back that they discover > that the > current release of import can no longer read the older version of the > .dmp > file. > > now what are these senior damagers going to do? blame the DBA, that's > what! > > > duck and cover... duck and cover... > > Tom Mercadante > Oracle Certified Professional > > > -----Original Message----- > Sent: Thursday, November 07, 2002 1:55 PM > To: Multiple recipients of list ORACLE-L > > > FWIW, what we just implemented (because senior management refuses to > approve additional storage on the grounds that "making the database > larger will > affect performance" - aaargh!) is > > 1) Confirmed with business how long data needs to be online for > various tables (they're all partitioned so that makes it a lot easier) > 2) Export partitions older than that once/month (this is generated off > a > table that lists each partitioned table and how long data should be > kep) > 3) After confirming that all export files are valid we drop the old > partitions (this will be done by script but is being done manually for > the > first few months) > 4) Leave dmp files on server for 2 end of months (our end of month > backup > tapes are stored for 7 years) > 5) Maintain a table in database saying what exported partitions are on > what > date's tapes > > > And I really long for the days in this company when senior management > made technical decisions by asking the technical people instead of > just making > things up... > > Jay Miller > > > -----Original Message----- > Sent: Wednesday, November 06, 2002 11:54 AM > To: Multiple recipients of list ORACLE-L > > > Someone asked about this 3 weeks ago. Here's my take > on archiving data. I don't expect everyone to agree with this, > but nonetheless, I have an opinion. :) > > Here's an email from last month. You can undoubtedly find some other > ideas on this by searching the archives of this list at fatcity.com > > Jared > > ================================================== > > I'm not a proponent of purging data. > > Unless of course, you expect to never see it again. > > That word 'archive' rolls of the tongues of managers > and consultants pretty easily, but what's behind it? > > There are a few gotchas with purging and archiving. > > Let's assume you have some 3 year old data that > you need to see again, and it has been purged. > > Here are some of the possible problems: > > * Your backup tapes are corrupted > * Your new backup hardware can't read the old tapes > * Your software no longer understands the format that > the data is in. > * You have the correct software, but it won't work on the > current version of OS on your hardware. > * The data format/software/whatever is not well documented > * The employees that understood the data 3 years ago > have been laid off. > * ... lots more stuff > > Read Bryon Bergeron's "Dark Ages II: When the Digital Data Die" > http://www.powells.com/cgi-bin/biblio?inkey=2-0130661074-0 > > Perhaps much better than archiving the data, is to stick with the idea > of moving it to another database, and using lots of cheap disk storage > (NAS) or a heirarchical file system to store it. > > The point being that if it's online somewhere, it will be maintained. > > Don't purge it till Finance, HR, the IRS and any other stakeholder > says it's ok. Only then purge it and archive it to offline tape with > the knowledge that you may never see that data again. > > Jared > > > > > > [EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > 11/06/2002 01:13 AM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > cc: > Subject: Data Purging Strategy > > > > Dear List, > > I need some inputs from you all regarding purging data from the > database. > > This is the requirement > > > We define a retention period for all the data in the system. When the > retention period is reached, the data should be deleted, but > > then at a later time, some user might request for this purged data. So > it must be possible to retrieve this data. > > This is the strategy we have designed for this. > > When the retention period is reached, move the data from the main > database to an offline database. Then delete the data from the main > database. > > In the offline database, we cannot again keep it from long, so it has > to moved to tapes. Now my question, how can we move this data to tapes > and at > the same time retrieve data from the tapes based on dates. > i.e, the user will ask for the data on a particular date, so it must be > > possible to retrieve data from the tapes based on a date and load it > to > > the database tables. > > Regards > Prem -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: MacGregor, Ian A. INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
