 |
 |
Archives of the TeradataForum
Message Posted: Sun, 27 Feb 2000 @ 17:54:29 GMT
| Subj: | | Re: Teradata OS |
| |
| From: | | John Grass |
Notes:
David Nasser wrote:
| | I'm going to expand on this a bit more. | |
| | Teradata installations are finely balanced between the CPU, memory, interconnect bandwidth, DASD connect bandwidth and DASD
I/O throughput. In essence, a well tuned (normal) Teradata installation will not be constrained on any of these components. | |
| | With all due respect, all computer systems have potential and/or actual bottlenecks. Just hand a system over to a group of
users ... | |
True. Aggregate queries will use more CPU than I/O. Joins between two fact tables or Cartesian product joins will impact
the interconnect. However, the database will handle these workloads w/o bringing the entire system to it's needs. The idea is that
all the hardware is working at peak capacity: that no major components are idle, effectively wasting money. This is expecially true
for mainframes, where a well managed CEC will almost always run at least at 95%.
Also rmemember that if one has a very heavy CPU extensive workload, then one can always change the CPU to DASD ratio (by adding
nodes) to accommodate this workload "bottleneck."
| | underlying OS and the underlying CPU architecture have little effect on the performance of the system. Rather, they
have an effect on the COST of the entire solution platform. | |
| | You take the position that performance is independent of the OS?? This po' boy has been trained otherwise. | |
Actually, performance is dependent on a good match between the OS, the hardware, and the application software running on
it. Mainframes are great at OLTP. Would you run multiple file table scan DB2 queries on a heavily loaded OLTP mainframe? Is this
the fault of the OS?
As long as the OS is adequate to ensure the hardware is well used by the application software, then we are good. NCR's UNIX
variant - SVR4 - has been around for a long time and is very robust. It is not, however, widely used in the industry and thus would
not be a good choice for an enterprise solution across all platforms.
Tandem's non-stop OS is great (the best?) for financial OLTP but, again, is not widely used in the industry and thus would not be
a good choice for an enterprise solution across all platforms.
The proof is in the pudding. When is comes to competitive benchmarks for DSS, Teradata and NCR's SVR4-MPRAS UNIX usually come out
on top.
| | From the mainframe, all one really sees is the performance of the SQL and batch maintenance jobs (both fully
parallelized) submitted across the channel. One does not see UNIX, NT, Solaris, 32-bit, 64-bit, or whatever. | |
I'm not really concerned with the mainframe. It is "familiar territory.
| | Just this week, we had a query blow up, eat 160 gb of spool space. First thing we did was forget the mainframe, test
with NT/Queryman. Jury is still out... hope its something silly ... | |
Probably. Take a look at the EXPLAIN (in English, and will be produced
without having to execute the query) and look for "product join" or a
join between two fact tables.
| |
