Re: On-Archie or OnBar ??

About 5 years ago, if I told you to set up a system specifically for doing queries, and reports, and I told you this system would have a data base without indexes, and I told you there would be no OLTP activity whatsoever, you might think I was crazy. Today, data warehousing does these things and a whole lot more. Data warehousing has requirements for table recovery and loading that as you say, deals a with large amounts of data. In this context, the recovery can be done in larger windows of time for the most part, or in ways that reduces the down time. There are also ways of building the DW so that this kind of activity is factored in as a regular part of business. OLTP systems for the most part are still being built with the idea that the tables that do the most work grow larger than they should. Instead of really designing around intelligent, robust recovery, tables get too big to recover, managers and DBAs panic because they can't recover all that data that they let get too big. In light of good, accepted DW practice, there is no reason why an OLTP system should have large volumes of data in mission critical tables. As the tables grow, a recovery factor should be considered all along and considered for extremely expensive systems like hotel and airline reservation systems. The idea that your OLTP system is also used for reporting and querying is going the way of the dodo bird. Your online query and retrieval system should be taking advantage of rolling off data that is aged, onto smaller fast-recoverable systems. Regarding recovery from UNIX files, it is also possible with the high performance loader to load from a device, or system, such as ADSM. The recovery is actually faster using this method than using onbar. ADSM is a bottomless pit for the DBA; "where to put it" or "where did it come from" are two questions you don't have to ask, you simply retrieve it from ADSM and shoot it back into the data base. A table-level restore option should be available even if the consistency factor is in question. If you've done your incremental backups, then you should be able to restore this backup into a perfectly healthy dbspace, etc. as I said before. To be sure, even a high-traffic OLTP system will require maintenance, and a certain amount of fault-tolerance. If this isn't designed in, well, then you get what you pay for. Thanks, Tim Super-User wrote: > > Mark brings up one of many major reasons why no 1st tier DBMS vendors > support table level backup/restore in their main backup/restore products. > I'm sure there are certain products out there claim to do just this but > unless it's an extremely simplistic scenario. i'm not sure DBAs want to > use them either. Think integrity, dependencies (index ...). What if the > table schema has been altered, i.e. column type changed, dropped, length > expanded... It's not as easy nor simple as one might think. You can always > do this with other provided utilities. > MS SQL server did have table level support with tons of caveats but dropped > it in 7.0 > Oracle does have lower granularity PIT restore (tablespace) but the process > is nothing but simple. As Mark pointed out, integrity is the key here, Oracle > will need to re-sync everything to ensure that. > > Without OnBAR, i don't know how you can manage a VLDB environment where the > typical size is getting close to 1 terabyte or larger and the backup window > is shrinking. It will take a while for onbar to mature. > > pete -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://www.inxutil.com -- -