-----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: [EMAIL PROTECTED]
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: [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).
