water constantly dripping on stone, will wear away the stone. And an
earthquake, with debris falling on that stone could shatter it.

I don't think even that will work


--- "MacGregor, Ian A." <[EMAIL PROTECTED]> wrote:
> 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
> >
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rachel Carmichael
  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).

Reply via email to