Re: Database Archive

My reactions:
1) A proper archiving strategy can improve performance for OLTP
activities and reduce storage requirements for the databases.
However, if the database has not been architected with an
archiving strategy in mind, archiving activities may cause more
performance problems that it solves. BTW, the sidebar does not
even mention this. In fact, the sidebar is so generic as to be
useless to us non-PHB types.

2) If you archive the data to a DSS/DW using the OLTP structures
(don't laugh, I've seen this done all too often), the OLAP
performance will be okay for a month or two, then it will
degrade rapidly.

3) The databases they refer to are small. I am working on
building a 100g play database on my single-cpu Win2k box at
home. I am sure there are systems out there that generate 27g of
redo per day, not per month. 2tb was huge 5 years ago, not
today.

Overall, it's an okay article, but it seems more fluff designed
to sell software and services by EMC.

Daniel


Jared.Still@xxxxxxxxxxx wrote:
> 
> First off, this is not about archive logs.
> It is about archiving data.  ie. moving data from your database to an
> offline
> system or moving it to nearline storage (HSM, etc)
> 
> I was reading an article in Computerworld about this:
> 
> http://www.computerworld.com/databasetopics/data/software/story/0,10801,90819,00.html
> 
> Or just go to computerworld.com and type in QuickLink 44949
> 
> What struck me about this article is twofold
> 
> 1) archiving data to improve performance
> 2) the databases they refer to don't seem all that large.
> 
> I would think that given a decent database to work with (Oracle)
> and someone fairly knowledgeable to run it, achieving acceptable
> performance would not require moving data out of the database.
> 
> For instance, one of the databases referred to is 100G is size.
> 
> Many of us have tables larger than that.
> 
> Just wondering what others reactions to this article are.
> 
> I plan to write a letter to computerworld regarding this, but thought it a
> 
> good idea to weigh in here first.
> 
> Thanks,
> 
> Jared
> 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: