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." <ian_at_SLAC.Stanford.EDU> 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
> ian_at_SLAC.Stanford.edu
>
> -----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
> >
> > >>> JayMiller_at_TDWaterhouse.com 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
> >
> >
> >
> >
> >
> > prem_at_ibsplc.com
> > Sent by: root_at_fatcity.com
> > 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: wisernet100_at_yahoo.com
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: ListGuru_at_fatcity.com (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).
Received on Fri Nov 08 2002 - 15:08:53 CST
