>>>So I need to choose between the following options...
>>>A.) Develop application to extract only the data I need from the oracle repository box and store it on another machine that will become the backend for my apps (I need to process and normalize about 60% of the raw data for reporting and analysis tasks)
>>>
>>>B.) Just have the Oracle box replicate the raw data to my backend directly, and then build a typical 3 tier client server environment straight off of this second machine for my VFP apps. (What platform to use for this second machine is also open to my decision. I'm considering either VFP on NT 4.0, SQL Server, or maybe even Oracle)
>>>
>
>>Sounds like alot of extra work to me. Do the seven UNIX machines each have their own Oracle DB with their own billing system data that needs to be consolidated into 1 DB nightly?
>
>The seven Unix machines do not use Oracle. They each stand as a separate billing system provided by a Service Provider we are stuck with. And yes, we consolidate them together nightly whenever we can... in my 2.6 system sometimes the consoldiation process happens during the normal day-to-day work, depending on the company's needs. With the new client server enviroment I'm trying to map out here, I'm hoping to get the replication from the Oracle box to my backend server setup like a nightly dump that happens automatically once all the west coast retail offices are closed for each business day.
>
>>In these days of WANS, T1/2/3 lines, etc., It does not much matter whether your server is in the next room or next country with respect to performance. If you have to have a distributed application, the routine to consolidate the data (accounting for new, updated and deleted records) will be hellacious.
>
>I know it seems hellacious, but this is our needs. We are in the communications business so the networking end of this is the easy part. We already have dedicated T1's in place that run from the unix boxes to my office were the new Oracle machine will be installed. The oracle box will handle the consolidation concerns, my backend will hold a static copy of all the data and just get purged out and replaced each night.
>
>>I would analyze what the requirements are and develop a solution that minimizes the amount of distribution. This minimizes the risk of corruption and failures. I assume when you say you are going to replicate data from Oracle to your other server, that data will also flow back (as a "batch" transfer?) to the source on a regular basis as well.
>
>I honestly hadnt thought much about concern of distribution here because it is going to function as a data warehouse. Data warehousing techniques typically call for replication across a distributed environment, and for a one-way flow of work produced. Also, the need for the data to "flow back" to the Oracle box is not apart of the requirements I need to meet at this time.
>
>Here's what I see as the "right path"... This new Oracle box is from the same Service Provider as the unix-based billing systems. It's a high dollar item the vendor is offering as a migration for the billing systems to a modern client-server environment. For what we need to do with the data from these billing systems, this monster is our only choice. As things stand now, we selectively transfer data from each billing system, consolidate it, normalize it where practical, and generate more than 80 reports to more than 20 remote locations. I need to get the reporting out of 2.6 and into VFP for the extended SQL capabilities. And I need to look at the data we are using to grow bigger than VFP can handle locally in another year or two.
>
>Since this Oracle box is designed to handle the consolidation concerns, and the deal is the Service Provider will be replicating the data from the CTREE structures used in the billing systems to this new box for 12 months. After 12 months the Oracle box will become the data source for the billing systems (or so they led to me to believe). Because of the massive amount of work this Oracle box is going to do for consolidating and providing us dam-near real-time access to the billing system data, plus the bad track record this Service Provider has with our company regarding the billing system boxes, I dont want depend on this Oracle box as the sole backend for my data warehouse apps. I figure if I start nailing that box with all of our extensive query needs and it fails, the Service Provider can say we are trying to make it do more than it was designed to do. But if I replicate the data to my own backend machine, one I buy & setup strictly to meet the needs of the data warehouse, and
>the new Oracle box fails.... well then the Service Provider is solely at fault.
>
>This is why I'm looking for answers as to what kind of replication features are either built-in or possible with Oracle. But any of your feedback on my plan in general is also appreciated Mark! Thanks!

If the UNIX hardware is dependable, and with a good UNIX administrator it usually is, and Oracle is installed and manageed properly, and a good Oracle DBA can do this, the Oracle backend is darn-near break-proof. Most Oracle systems are set up with a feature called REDO logs. So, in case of failure, the Oracle DBA can recover the database upto the exact point of failure. All that is basically left is scheduled (nightly?) backup of the Oracle data which can be done several ways.

Oracle is a tough-bird and extremely robust/dependable. Companies like Mobil Oil, Wells Fargo Bank, etc., use Oracle for all their datawarehousing. I doubt many can approach the transaction rates some of these companies have. Oracle can handle much more than you think. I guess it depends on the HUMAN resources and your level of trust in them with respect to the Oracle server.