RE: EMC TimeFinder, and EMC TimeFinder vs Hot Standby

-----Original Message-----
> What do we want to know?

> 1. Are we on the write way, (do you have any other idea)?

Yes, you're on the right track.

> 2. Does that concept have some misses?

This concept does not give you the fault tolerance. It will only make it easy for you to have an up-to-date reporting database. For the fault tolerance,
you will have to use parallel server option.

> 3. What is your opinion and experience on that subject?
> 4. What is your experience with implementing and administering of such
> configuration?
> 5. Could you explain us basic concept of starting up of target database
> through SRDF and
> Time Finder. Sales people from EMC2 told us that some APIs are used for
> this purpose.
> Do we have to customize it, or write some programs or scripts?
> 6. Do you use some special monitoring tools?

SRDF is, essentially, a very fast backup facility which copies "disk->disk". We don't
use the so called "media layer" with SRDF, which means that we put the database in the
backup mode ("alter tablespace ... begin backup;"), SRDF it to another array and do the
full database recovery. It is an automated script and the database synchronization (copy &
recovery) is done in 1.5 hours. We don't use time finder. As for the monitoring tools,
our sysadmins use a tool from EMC that shows them potentially "hot" disk drives.
Data loss never happens, because of the configuration (redundant everything).

> 7. Could you describe us your step-by-step scenario for starting up target
> system in case of primary site failure, and specially if your
target
> site at the time of the failure is open for reporting.
> 8. What if:
> - primary site server fails (loosig data in cache)?

You MUST use Oracle Parallel Server if you want to protect yourself from thedata loss.

> - EMC storrage system fails ?

Hot swappable, redundant everything system which can tolerate any single point of failure,
combined with the under 2 hours of response time 24x7, 365 days a year will take care of that.

> - Network fails?

Redundant network connections with steep penalties if the provider does not meet it's
obligations.

> - Corrupted blocks (Oracle side)?

You have to do database recovery, but that does not happen very frequently.

> 9. Have you ever experienced failure and downtime?

Yes, the cause was the application software, and in one case a bad oracle bug which
allowed duplicate data in the primary key (under special conditions and on OPS)
> 10. After all, do you recommend us such configuration?

Yes, I would, but keep in mind that prices for such configurations are very high (> $5,000,000)

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Gogala, Mladen
  INET: MGogala_at_oxhp.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).