|
|
|
Forum Newbie
Group: Forum Members
Last Login: 8/7/2007 2:45:00 PM
Posts: 6,
Visits: 1
|
|
Hi Nicky,
Not sure what you actually mean by "rollup" but there are Aggregate Join Indexes which can be used and it is completely Ansi SQL compliant.
About "The partitioning faculity Teradata offer is by no mean equal to oracle" -
Well, you will never have to and will never need to think about partitioning in Teradata because everything is parallel by default (data distribution, retrival, etc..).
Please note that, Optimization criterion for Oracle and Teradata are different. Teradata is optimzed for DWHing. There is nothing you cannot do with Teradata which you can do with Oracle in terms of DWH. Besides, you can do all that much much faster.
From a DBA standpoint, there are many things if a DBA wants can do. But usually they are not required to do it as per their job role. I would agree if with the fact that some aspects of DBA are not as easy as in Oracle. But life of DBA is much easier with Teradata.
As stated before also by me, it might be a rough road to crossover to Teradata from Oracle background but the effort will be worth it.
Try this and you will see the difference :
Try to load 150 Million rows into an Oracle table - use any optimization strategy you want - just do a traight dump to make it simpler)
Try doing the same in Teradata.
OR
Try doing a query with couple joins etc.. on a HUGE table (200 millions) selecting all rows in both environments.
The difference will be obvious.
Thanks, Giri.
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 7/10/2009 6:28:52 PM
Posts: 505,
Visits: 546
|
|
I once had a training session for folks who were porting an OLTP JDBC Application( with tons of RIs, triggers etc in cascaded fashion) from Oracle to TD, so there was the obvious complaints going on, as to how difficult TD was to use and it didn't give the performance.
After executing a simple JDBC program which used the "right features of Tera JDBC", my average office latpop (which is infamous for the tones of open windows and other apps running  ) configured with Demo DB, could load a million records in a minute. (I survived the rest of the days without hearing much complaints  )
TD and Oracle are like Apples and Oranges, it's better not to be compared one to one...
I would also vouch that for a Teradata DBA (who know's his stuff) life is heaven compared to an Oracle DBA (who know's his stuff). I can't name organisations due to confidentiality reasons, but some of the major telecos whom I have interacted with in the past didn't had more that 2 DBAs for their TD systems (and there was one teleco who just had 1 who couldn't recollect missing a weekend off due to a production issue call). And they all have tons of data.
Most of the new TD guys come from Oracle background and has to do a lot of unlearning to do which puts them at cross with TD (They start by applying oracle logic), and similar in the experiences in the past tell me that, most of the "Oracle to TD porting" is sort of .... copy the DDLs, copy the Data, do changes for syntaxes and data types that does not work etc ...... very bad idea !! but whom do you blame ? the client doesn't want to spend more money on what looks unnecessary, the IT guys don't want to lose the contract by irking the client !. I have seen SQLs running for days in TD due to this (!)... Then you go in, do abracadabra on the physical design of some tables... and the queries are over in a few minutes. but by then, it's too late...
last, but not the least, I wouldn't take those surveys without a grain of salt
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 9/12/2007 12:33:00 AM
Posts: 4,
Visits: 1
|
|
thanks to all of you guys again.
most of guys claims that teradata is much quicker than oracle in parallel processing.
why? any technical reason.
Amir Riaz
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 11/5/2009 4:40:02 PM
Posts: 717,
Visits: 466
|
|
Hi Amir,
"most of guys claims that teradata is much quicker than oracle in parallel processing.
why? any technical reason."
Because Teradata is a parallel database system using a shared nothing approach from the very beginning, whereas Oracle just added some parallel options and even RAC is still using shared storage :-)
Dieter
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 7/5/2009 11:52:43 AM
Posts: 1,
Visits: 2
|
|
On top of all the issues mentioned here is the cost of resources (people). I can hire an Oracle developer with no problem. Teradata developers are few and far between, and the interviews are discouraging at best. Just trying to find someone who understands that a TD PI is for distribution can be frustrating.
Teradata is "different" and the differences are annoying.
1. date/time/timestamp handling is moronic at best. After 2 minutes with oracles to_date/to_char you can't imagine why teradata doesn't get it.
2. skew (when the data is not properly balanced across the nodes)
3. spool (when the optimizer decides it needs to copy loads of data from node to node and rehash it all) which is a big performance hit. Then there are the opportunities to exceed spool. No matter how much spool is assigned, you can always have sets that are just too big for spool.
I'm not saying that all databases and all DW solutions don't have challenges, but we spend an enormous amount of time on issues other than just getting the data loaded. A lot more than I ever spent on an Oracle database. We're not building an autonomous robot to send to mars, just trying to load some data and build some reports.
The join indexes, and covering JI's, are a great help, but not enough of a selling point.
Where I am, a fortune 50 company, we have thousands of small to medium sized Oracle servers and a couple very expensive teradata servers. I have yet to see a comparison between comparatively priced (aka equivalently built out) servers. I would love to know what a 15 million dollar Oracle server would perform like. It would also be fun to look at a grid and see if they are introducing the same issues we suffer from on Teradata.
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 10/18/2009 5:48:26 AM
Posts: 273,
Visits: 1,214
|
|
Hello,
I don’t intent to say anything bad about any individual or any RDBMS .... no offense at all! :)
I genuinely believe it all depends on the requirements & exactly how you plan to use the RDBMS. The parameters include (not limited to) data volume, data types, DBMS engine performance, SQL engine caliber, hardware requirements, software/hardware limitations, data crunching abilities .... etc. After defining all those parameters, you need to assign weights for all of them, and then it will all be clear .... or in some cases you may also have to do some benchmarking.
As far as comparison between Teradata, Oracle and other RDBMSs is concerned one must first define the requirements very clearly (cannot emphasize enough on it! :)) to decide what to put on. And as far as migration of current implementation is concerned you surely cannot blame one RDBMS for storing DATE as DATE and TIMESTAMP as TIMESTAMP, because RDBMS X stores TIMESTAMP as DATE and RDBMS Y stores some creepy binary value in TIMESTAMP.
Now lets talk about some facts .... Teradata's SQL engine is fair enough, why? because it is not as fancy as Oracle's SQL engine but at the same time it does what is required .... it works. That helps keep the SQL simple & straight-forward .... the decision of which one is better, again goes to your requirements & usage and your previous experience as well .... if you have been working with Oracle for long, you may say that "CREATE TABLE Table1 (Col1 INTEGER, Col2 INTEGER)" is much complex, tough and rigid than
"CREATE TABLE Table1
(
Col1 INTEGER,
Col2 INTEGER
)
TABLESPACE Table_Space_1
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 128M
NEXT 128M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
)
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;
" but again, it depends! Do you really need that level of 'control' for couple trillion rows, or will you like to leave it to the RDBMS engine you have invested in?
Next comes the fact, Teradata is built for DWH i.e. for HUGE DWH! Oracle is the best OLTP DBMS one can have. No DBMS can stand for long if you have an increase of couple TBs of data coming in daily and yet no increase in batch window, no matter how much money you throw in it .... because there is some point at which software’s/hardware’s limit will rise above and hinder your comfort.
Next comes the parallelism, WOW! It always fascinates me! From storing a single bit, to retrieving couple GBs of data after joining many tables, its all parallel, can you just imagine that for once? And parallelism is not just a marketing hoax .... Teradata's architecture is completely based on it from start till very end .... including all of its utilities as well.
Next comes the scalability, if you started with a 100 GB DWH volume and now you need more or you need your reports to be more faster regardless of the data volume increase, okay fine no problem it is linearly-scalable, you may add more nodes 'whenever' you desire .... and that also without the need to manual-rework (re-defining table-spaces, partitions, dropping & recreating of DB objects etc)! Now I believe you can't say this for every DBMS out there, can you? So, it again goes in the bag of .... what exactly do you desire? What exactly are your requirements?
Lastly, every RDBMS has its own specific purpose, the questions arise when there is some area where two or more over-laps each other. The decision can be made out of what you are good at with current resources or what you can have in given resources! :)
HTH!
Regards,
Adeel
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 10/22/2009 1:29:06 AM
Posts: 36,
Visits: 182
|
|
Oracle and Teradata have their own unique distinct features. I have worked on both and certified in both.Being in datawarehousing,
I feel the partition part Oracle is far ahead. Materialzed view oracle is far ahead. Functions, packages,procedures,triggers oracle has many options and they rule in OLTP. Now come to teradata utilities, mload,tpump,fastload,bteq,fastexport. Oracle has to come up a lot.
I work on all these features. Oracle bulk load has to improve in many ways. I have many points to tell but time is a constraint.. :)
Teradata_cert_Oracle_cert
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 9/14/2009 3:51:08 PM
Posts: 1,
Visits: 4
|
|
|
Heh... It seems there are not so many arguments against Oracle, does it? :)
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 10/1/2009 9:48:00 PM
Posts: 1,
Visits: 1
|
|
Fully agree with joedsilva. Teradata is leader for parallel processing.
Teradata is still the only database that loads data in parallel, backs-up data in parallel and processes data in parallel. The idea of
parallel processing gives Teradata the ability to have unlimited users, unlimited power, and unlimited scalability.
Teradata allows for maximum flexibility in selecting and using data and it therefore can
be designed to represent a business and its practices.
The Teradata founders set
two primary goals when they designed Teradata which were:
• Perform parallel processing
• Accommodate Terabytes of data
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 11/18/2009 4:07:50 PM
Posts: 4,
Visits: 8
|
|
Each product has their strengths. OLTP and smaller data warehouses are places I would consider Oracle. Large data warehouses are definitely the focus for Teradata.
User behavior also needs to be considered. If you will have a large community of end-users generating adhoc queries, you will need to take some precautions in a Teradata environment since they are able to impact overall system performance rather dramatically. These precautions could be as simple as educating them on query development or as drastic as isolating them in some fashion (environment or time of access). Since Oracle doesn't use MPP, it seems to hold up better against users experimenting with their queries.
Hope that helps!
john
|
|
|
|