Archives of the TeradataForum

Message Posted: Thu, 18 Oct 2001 @ 08:25:42 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

I worked on a project 2 years ago that migrated a large Oracle d/b from a Sequent SMP platform to an NCR5250 Teradata box. The same data was being moved from one to the other. This gave me a very real insight into the similarities, and differences, between the two databases.

SQL*Plus was used to perform the unloads from Oracle. It's just like BTEQ - they're both used to submit batch SQL requests. We could find no native Oracle tool for performing a high-volume, high-speed data unload to aid migration i.e. there is no equivalent of the Teradata Fastexport utility. This may no longer be true, and 3rd party tools may exist.

Lesson 1 - Teradata has a native utility for any operation you would want to perform, Oracle does not.

The Oracle database consisted of about 5 billion rows, and to be honest it never worked. Multi-table joins, complex queries or more than a few concurrent users and it simply came to a halt. It cost a lot of money and had 5 users.

Lesson 2 - Teradata supports high-concurrency and complex ad hoc queries, Oracle does not.

During the migration one of the Oracle tables became corrupt. Luckily they had an archive. 3 Oracle DBAs fought for 2 weeks to re-load the data and gave up. The Oracle d/b simply would not let them load the data from an archive due to the changes in the file system that had taken place in the meantime. This we could not believe. Teradata is unchoosy about using archives to do restores. You could restore data on a different release into a different d/b and create a table that had never existed. This the Oracle DBAs could not believe.

Anyway, we provided a CSV file to be re-loaded and used to perform the recovery via SQL insert processing, which worked. If we had not been migrating the data this would not have been possible. So, even with an archive the data would have been irretrievably lost without good cause.

Lesson 3 - Teradata archive/restore facility is easy to use and dependable, Oracle's is not.

Once on Teradata we simply extended the existing model with the new data. It worked a treat. The users loved it. It's still there. The Sequent/Oracle platform was de-commissioned and the h/w used to provide a disaster recovery solution for the OLTP environment. Oracle for large-scale DSS/data warehousing is no longer an option within the organisation.

Lesson 4 - Teradata scales up easily, Oracle does not.

One of the biggest eye-openers was also the number of Oracle DBAs needed just to keep it working. The Teradata platform on which the data now lives is nearly 10Tb and has no full-time DBA.

Lesson 5 - Oracle lots of needs highly skilled, expensive DBAs to keep running smoothly, Teradata does not.

Oracle platforms are often in wide use throughout an organisation for OLTP, which means Oracle skills, and mindsets, abound. This is compounded by the number of Unix support people who are comfortable, and knowledgeable in the Unix/Oracle environment. This is not sufficient reason, imo, for using the same platform for large scale d/w.

It's a case of 'horses for courses'. Oracle is great for OLTP and small/mid-sized d/w. Scalability is the number one issue, imo, that will come back to haunt many Oracle users.

As my old boss used to say "Oracle have got the sales staff, but NCR have got the technology, if only I could get a supplier with both"!

Paul Johnson.

	<Prev	Next>		<<First	<Prev	Next>	Last>>