I still see roll-your-own was still the best option in our case, but those are due largely to psychological/political factors within our organization.

Thanks again for your insights, and I hope to see you at Hotsos next week!

-T. J.

The fix has been officially released for the ODA. 2.1.0.3.0 (patch #13622348) was released today. Check MOS note #888888.1 for details. If you’re already running 2.1.0.2.0, then you don’t have to install the Oracle patch. It’s the same as in 2.1.0.2.0 (the January 2012 CPU).

execute dbms_stats.delete_system_stats;
worked for me.

Now, ODA shows around 2900 MHz at AUX_STAT$.CPUSPEEDNW

Ralf

execute dbms_stats.gather_system_stats(‘noworkload’);

You are right, it should be fixed with patchset 2.1.0.3.0. In the meantime, we received a temporary patch, which accelerated our benchs by 400%. I received (but cannot validate because of missing access) the information that AUX_STAT$.CPUSPEEDNW is still the same.

Ralf

Yes – this is a known (but unpublished) bug (bios related). The bios is supposed to be fixed in the next ODA bundle patch set. You should open an SR and support should be able to help you fix the problem. CPUSPEEDNW will be around 675 with the bug and should be around 2700 after the fix.

Kerry

we are facing really poor single thread performance of ODA with 6-core Intel Xeon
processors X5675. 3.06 GHz.

Can somebody share output of

select PVAL1 from aux_stats$ where pname=’CPUSPEEDNW’;

THX
Ralf

Thank you for your response. I certainly appreciate the depth and breadth of the experience behind your comments and recommendations. I agree with your assertion at Hotsos that the industry is beginning to lean towards engineered systems, but for my situation, it just doesn’t make sense yet.

As my employer continues to grow, downtime becomes less and less tolerable. For our part, we are using DataGuard in order to maintain a DR site across town, so we’re looking at 2 identical hardware setups as it is (presently, we’re single instance). I see what you’re saying about patching the standby, switching over, patching the primary, and switching back. Is this possible with ODA? Your post only mentions one box, so I’m assuming this is only a theoretical solution. Beyond the theory, the risk there for me is whether our services can respond within SLAs when they’re connected to a database that’s on the opposite end of a metro E connection. What I want is on-site redundancy, and I can get that with RAC One Node without licensing a 2nd box, thanks to the 10 day rule (IF I can manage to stay off that box for 10 days, of course). Regarding your list of advantages,

1. Cost – I agree completely when only looking at hardware – The ODA box is priced quite competitively. A full examination of the cost requires more than just hardware though. For the size of individual server I’m after (I’m looking for as few cores and as much RAM as possible), the cost difference is insignificant compared to the gain in flexibility. I’m essentially out of time to investigate options such as your suggestion to patch the standby & roll to it, as the tax advantage of capital improvements diminishes significantly in 2012.

2. Time – Right on again, but flexibility beats the cost again for me.

3. Risk mitigation – The “It Just Works” factor is huge, but the known quantity of no rolling patches and no commitment that it will change or timeline as to when that will change is a larger risk for me. I’m moving from single instance to RAC One Node in either case, so why wouldn’t I choose to take advantage of the redundant server for rolling patches?

Thanks again for your input. In considering my response to you, I am convinced that ODA is a viable option, although I still don’t see it as my first choice.

-T. J.

No patches even exist for the ODA at this point so it’s a bit of a mute point. That said, if you are running a system that absolutely can not afford any maintenance windows then you probably should be paying a lot more money for it than what the ODA costs. The fact that Oracle has not announced a rolling patch strategy for this machine “yet” is a nit in my opinion and is probably something that will be addressed in fairly short order. If it’s an absolute requirement to never have any down time then you might consider buying two ODA’s and using Dataguard. This would allow you to do “standby first patching” which means virtually no application downtime. However, every solution has it’s trade off’s so it’s best to understand your requirements and architect a solution that fits in your budget and meets your most important needs. The ODA shines in a couple of areas:

1. Cost – I don’t believe there is any way you can build your own cheaper. We went through the exercise of pricing competitive components and couldn’t come up with a way to do it for less money.

2. Time – Building out your own RAC cluster takes time which translates to money. We’ve built out a bunch of two node RAC clusters over the last several years and it takes some time. Our experience has been that to do a thorough job generally takes a couple of weeks. With ODA the configuration can be done in a day.

3. Risk mitigation – The biggest advantage of ODA in my opinion is that you don’t have worry if you, or your staff, or your consultants have thoroughly tested the newly created environment. The last thing you want is a system that becomes unstable under load after you have put it in production. This can and does happen due to various components not working well together or not being configured to work well together.

Clearly you will have more flexibility if you “roll your own” because you can do anything you want. But you will be trading the advantages provided by that approach against the advantages provided by a prebuilt system. That is to say, the custom system will probably cost more and take longer and introduce more risk. Most technical solutions involve trade offs of some type.

You may wonder why I would be arguing against building from scratch since I work for a consulting company that typically gets paid by the hour to do this kind of work. The answer is that the vast majority of RAC systems we’ve helped customers build over the last several years would be nicely handled by ODA. So I don’t really expect we’ll be building too many more two node RAC clusters.