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).
