Re: upgrade & migrade JDE
[ QUOTE ]
The reasons why we move from win/sql to orcl/hpux are performance and scalability
[/ QUOTE ]
It is understandable that you have performance issues with B7322 running on SQL 7.0 - but 8.12 running on SQL 2005 would demonstrate a MUCH higher scalability and performance - to the point where it is hard to really distinguish the performance difference between a high end Oracle system and SQL 2005. All platforms these days can perform and scale to as high as your requirements are.
[ QUOTE ]
2core db server and 2core apps server will be clustered with hp mc serviceguard
[/ QUOTE ]
Clustering and high availability, in my opinion, are actually better on Unix than traditional clustering (passive clustering) with Microsoft. However, saying that, Microsoft has certainly made some huge strides in recent years - there are third party active clustering solutions, and now Microsoft has their "compute" parallel solution (which we all hope will end up supporting SQL 2008!). I think its important to look into active clustering technologies with Microsoft if you have those skillsets internally.
[ QUOTE ]
we will be a huge challenge in acquiring orcl/hpux skills and supporting the configuration, is it more complicated than win/sql? How about the cnc?
[/ QUOTE ]
Oracle skills are traditionally far more expensive than Microsoft skills - as are Unix skills. They are rarer as well, given the fact that the market is swamped with MCSE's in comparison to the very few Linux/Unix personnel out there. Oracle is much more "hands on" - the real positive side of Oracle is how you can tune the database server, and the same goes for Unix as an operating system. The problem comes when you need to tune the OS or the Database - and your guy doesn't really know what he's doing ! At least with Microsoft its very difficult to make a "serious, unrecoverable" mistake - with Oracle on Unix, its a lot easier to screw up if you have root access....
[ QUOTE ]
We are going to use HDS storage subsystem 10 X AMS 146GB FC 15K RPM mirroring, is it ok?
[/ QUOTE ]
No - absolutely not. You have been talking about performance and scalability throughout this thread, and all of a sudden you throw a small disk system ! It seems to me that your hardware provider has spent time trying to come under a certain budget that you have proposed - and putting together 10x146Gb hard disks is absolutely showing me that they've saved money in the most critical place - the storage.
The HDS System is certainly a very scalable solution - but I'd rather see 40x36Gb drives as opposed to 10x146Gb drives.
As anyone will tell you - the number of arms is critically important in any database system. At best, your 10 disks will end up as RAID 10 - ie 4 volumes mirrored/striped with parity - a total volume size of 600Gb. Not a lot of space at all.
Given the fact that you need to place your Oracle archive logs on separate disks than your data drives - you'll end up with even less space and it sounds like your hardware provider is trying to sell you a RAID5 configuration.
I'll also say that for your size company, the HDS is going to be a challenge. Its a Virtual Array storage solution that is very cutting edge - a little TOO cutting edge maybe ?
Lets give you a comparison. For one customer recently, they purchased an HP EVA 5000 stacked with SIXTY FOUR x 72Gb 15K RPM Fiber Connected drives. A Total of 4.6Tb. Carving this out to a SQL Server (or to Oracle) meant a total usable space of around 3Tb once all the mirroring and parity's had been taken care of (their production database is 200Gb, and they have 5 copies of this for CRP, Development, Training, Conversions and Data Warehousing).
Total cost ? Under $200k.
Interesting enough, you can buy the same configuration on ebay from an HP vendor for around $50k these days - and the equipment would STILL BE UNDER WARRANTY !
[ QUOTE ]
EO 8.11sp1 is stable than 8.12, could you advise
[/ QUOTE ]
I'm not sure where your consultant got this information - he might be right, he might be wrong - it all depends on the functionality you are deploying.
I would recommend that if you are upgrading, you upgrade to the latest version - which would be 8.12. During your conference room pilot, you will encounter "issues" and problems and Oracle will absolutely be more keen to help a customer on the latest version than one on an older version. It removes the ability for their support department to say "well that was changed in 8.12 so you need to upgrade..."
I wouldn't be surprised, either, if you see a "SP1" coming out within the next couple of months for 8.12 - certainly Oracle want to be able to promote the fact that their product is absolutely the most stable thing out there.
Financials is financials. I'd say that any version above B7331 is completely stable as far as financials is concerned. There are definitely changes to manufacturing, however, that occur between 8.11 and 8.12. Lastly, you'll be on the same service pack release between 8.11 and 8.12 (the technology foundation) - ie, 8.96 - and the foundation is far more critical in the stability of a product if you ask me. Once you install the thousands of ESU's for 8.12 and you're on 8.96, then you'll be about as stable as you can get ! After that, its up to your implementation team and Oracle !
I think your company should rething its strategy of moving away from SQL Server to Oracle - instead you should be thinking about a large clustered SQL Server solution to provide the stability, reliability, scalability and performance and you will be able to utilize your existing skillset. Once you venture away from Microsoft into Oracle, you'll need some very experienced personnel to tune the database and operating system - and you'll be seeing lots of little scripts to assist with the non-application side of the system (such as backups and general nightly tasks).
Don't get me wrong - I like Unix AND Oracle, in fact I personally prefer it over all platforms - but for a company with less than 500 concurrent users, I just don't see the justification. You'll end up, with the budget it seems you have, with a small unix system that barely keeps up with the number of users you'll expand to - in comparison with a huge wintel system that can expand to thousands of users.....
