Archives of the TeradataForum

Message Posted: Sun, 16 Oct 2011 @ 10:54:51 GMT

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

Just to add some thoughts to Kenneth Hansen's note. Actually, I would recommend that you review his and the other notes again.

Sizing a system is a complicated task and a full explanation is far beyond the ability of any Forum. As somebody who participated (many years ago) in a couple of sizing exercises (both large and small, new and upgrades), I can point out some things you need to consider. Importantly, you should be able to answer these points (plus a bunch of others that I haven't listed) before talking about hardware:

- Do you have a clear understanding of the data and the underlying demographics of the database. This question isn't about hardware, it's about the data. You honestly can't size the system without a clear design and understanding of the database. What are the data sources? How fresh is the data? Are the sources dependable? Dirty data requires scrubbing, so how much work is that going to take and where is it going to be done? How long is it between arrival of data and the time when it must be available to the user?

- The number of users, the types of queries that they are going to run, what kind of response times are required for those queries (seconds, minutes, hours). A query using the primary index can be very fast and uses very little (to no) spool space. A query requiring a full- table scan can be very slow and requires lots of spool space. Are these going to be tactical queries or strategic? How many of each type of query do you need to plan for? What's the mix of queries? What kind of worst-case concurrency must you plan for?

- How well do you understand the industry and the specific business units that wants the database? The needs of a retail system are a great deal different than a telco system and financial systems are another subject altogether.

- My own experience is that the types of adhoc queries that the business community begins with will lead to new queries (and requirements) after a few weeks of them first gaining access to the data. So how flexible does your implementation need to be? It's a very rare situation in which the database lives in a static environment where the data and workload remains the same over time. Expect it to change quickly and you'll need to size for that change. You really can't anticipate these things if you don't have subject experts available to you.

- You didn't mention it, but what kind of data loading & maintenance jobs are going to be required? I've worked with several systems where the daily loading of new data and maintenance of existing data consumes more system resources than the queries submitted by the users. What kinds of connectivity do you require? How much new data do you have to deal with daily? How much of your data is going to change (ie- updates/deletes)? You need to have a clear picture of your infrastructure issues.

- Are you going to have restrictions on your users during your production window or will they have access 365x24? I'm willing to bet your understanding production requirements is a great deal different than what your users are going to commit you to. You really need to make sure that both of you understand your processes and requirements. How happy are your users going to be when they discover that your production jobs will have rolling locks?

- What kinds of indexes are you going to need. What columns are going to be used by the queries? Those columns are going to require statistics and that will affect the sizing and production windows.

- Going back to your data sources: What are the load and maintenance windows? What happens when your data doesn't arrive on time? How long do you have to catch-up? What about disaster planning and recovery? How long do you have to recover? What's your archive strategy? It affects the sizing.

- Have you taken the findings of the above and taken them back to the involved parties to create a Service Level Agreement (SLA) that everybody agrees with? There's no point going any further if you don't start by understanding and managing expectations. And from my own experience, I would warn you that SLA's aren't done by arm-waving, they really need to be committed to paper. If you aren't starting with an SLA, you've probably got an unpleasant time ahead.

These are just a scratch of the surface and you'll notice that we haven't said anything about hardware yet. I know this all sounds airy- fairy, but before you start talking about hardware, you need to have clear and specific answers to the above.

Other than those who are very experienced with Teradata, I doubt that anyone outside of Teradata could properly size a system. In addition, since it's important to Teradata that any sale of their machine meets the need of the customer, I doubt they would sell a system if they don't have some kind of participation in the sizing and a confidence that the system will meet the needs of the ultimate customer.

Like I said before, the subject is too broad and demanding for any Forum to give a meaningful answer to your question. I would recommend that you contact Teradata directly and see what help they can give you.

Really, it's easier to get a sizing wrong than to get it right - and you'll need experienced help to get it right.

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