Re: MS SQL Server Evaluation

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1079388217.467747_at_yasure...
>
> Different countries different priorities perhaps. Here TAF is a bigger
> issue.

Not sure how it can be that big an issue, considering it does sod-all and works only when the prevailing wind is from the west on alternate wet Wednesday afternoons with a full moon. But whatever. I know it gets better in 10g.

>But the biggest reason for RAC is to save money. The argument
> is quite simple.
>
> 1. Check the cost of a 16 CPU box to handle an application's anticipated
> load.
>
> 2. Check the cost of 8 x 2CPU boxes plus the cost of RAC to handle an
> application's anticipated load.
>
> 3. Explain to your CFO why you just spent a boat load of capital on the
> big box when it won't be required until the application scales up to its
> anticipated workload two years in the future when the 16CPU box will
> already be obsolete.

Easy.

"My dear CFO. You have been gulled by Oracle marketing. Were things really as easy as bolting on another 8 cpu box as the need arose, I would naturally have recommended that particular solution. But it isn't. The additional costs associated with the extra code layer that RAC brings are potentially immense (I believe they're known as "bugs" in the trade), and it is a good deal easier to manage and tune a single-instance environment that it is a multi-instance one. In a few years' time, when the experts have worked out how to properly tune and diagnose and cure the cross-instance contention and latency issues that cache fusion introduces, perhaps my response to you might be different. But no-one currently has really pinned down all the issues associated with tuning a RAC, and that is a cost you should take into consideration.

Furthermore, all our tables currently use freelist management, and freelists are not very flexible. Extents belong to the instance that acquired them. So even if it really were easy just to bolt on another instance, we are going to have major contention issues and/or space management issues arising out of past space allocation practices. Of course, we should migrate to ASSM to deal with this issue. But did you consider the cost of all the downtime and poor performance due to massive I/O rates that will be required to effect that particular migration?

Then of course there is the slight matter that all our tables use synthetic primary keys, generated by sequences, and sequences do not cache and order as cheaply in 9i Release 2 RAC as they would do on a single instance. So you need to add in the cost of all the application testing required to make sure that performance on a RAC is actually as good as we need it to be. And the cost of the developer time required to correct code that refuses to scale properly. Did you remember to cost the acquisition of another RAC for the developers to be able to develop in a realistic environment? Bear in mind that I can use system statistics to fool the optimiser in an el-cheapo single CPU machine into thinking and behaving as though it were running on an expensive multi-CPU system. But there's no way I can simulate the issues that arise from cross-instance transfer of data.

Additionally, indexes on monotonically incrementing sequences pose a major contention issue on the "right-hand leaf node", and we'll need to deal with that by recreating our indexes as reverse key. You should factor in the cost of storage for an index which used to be highly compact and efficient now block splitting like crazy. And the further downtime/unavailability/huge I/O issues as we attempt to rebuild all those indexes. Or we could have hash partitioned our indexes... but we then need to purchase the partitioning option from Oracle, and that's not exactly cheap.

Oracle currently charges about $2000 per person to attend the 3-day RAC course. Training our team of 5 DBAs is therefore a cost you need to bear in mind. Plus the unquantifiable cost of the fact that the 3-day RAC course is a bit thin on actual detail so they'll have to acquire their more specific knowledge some other way. Did you factor into the equation the costs of a small training RAC?

By the way, one of our applications is provided by Systems Are Poor, and they refuse to certify their software with ASSM or with hash partitioning or...

I could go on, but you appear to have turned a little pale. So perhaps I'll leave it there, merely pausing to sum up: If we'd needed high availability, scale up and speed up then RAC might have been a viable contender. But we get the high availability from our Data Guard infrastructure already. And I have purchased a box for us which will cope with our scale up and speed up requirements well into the future (a box doesn't become obsolete until its CPUs burn out and cannot be replaced).

> 4. Explain to the people at the unemployment office why you need a job.

Easy.

"I got bored dealing with brain-dead CFOs who liked the glossy brochures but didn't understand the actual technical issues, so I resigned".

Regards
HJR Received on Mon Mar 15 2004 - 17:17:31 CST