08-21-2007 02:02 AM
I oversee a fairly large but aging PARISC based 11.11 Ecosystem - complete with a Dev/Build Environment, Test& Staging, a ProdTest Environment (which is an exact copy of prod where adhoc batch, inquries ansd resolutions are ran) and a normal Production Environment.
We're planning to switch to Itanium Hardware sometime middle to end of 2008 and are aware that thj e road to Itanium starts with converting your PARISC systems to run on 11i v2.0 (Is this still correct?). And the way I envision the upgrade to happen will the following sequence:
1.) Test and ProdTest Environments First
(11.11 builds should continue to run unmodified and should still run native)
2.) Establish an 11i v2.0 parallel Dev and Build Environment and test out natively built 11.23 Executables.
3.) Once 11.23 Dev and Build Environment's builds/exes are full tested... collapse the 11.11 dev and build environments.
The Itanium Road will be something similar.. Test and ProdTest can run briefly on Aries Translators or a parallel effort to establish a native Itanium build of the apps should alerady be happening a few months before the cut to Itanium.
08-21-2007 02:28 AM
Going through the same as you as well.
Currently, we built a "test" environment on Itanium with VSE as well.
We too are moving from 11.11 to 11.23 (and even 11.31 in some cases).
If you are in a "server" hardware refresh point - then either build on Itanium now, or on 11.23 PARISC.
Last year, any new servers we received we built 11.23 on them.
We moved our test to 11.23 last November for SAP, and our App server in Prod to 11.23 (parisc). I'm in the process of upgrading our QA env and Prod to 11.23 - for September.
Next spring - we will be moving this particular environment to Itanium - the 11.23 on parisc is just a stepping stone.
The biggest thing for Itanium - is ensure your binaries for your apps are local to the machine - IE - for clusters - don't failover binaries. That is our plan - we will bring Itanium servers into the existing clusters - having locally native compiled binaries (oracle and SAP) and then the migration will be a lot easier.
08-21-2007 02:33 AM
I have to ask: "why 11.23?" I would think you would want to go directly to V3. V2 gains you little and the expiration date is the same as V1.
08-21-2007 02:45 AM
The road to Itanium starts with converting your PARISC systems to run on 11i v2.0 (Is this still correct?).
Pete makes a point. I would not jump to 11.31 now. But next summer, after there have been two bi-annual updates, I'd consider it if application support exists.
As to the rest of your plan.
1. Cold install is still more reliable than upgrade-ux. That is a must for 11.31 as there is no direct path and a strongly advised thing to do if you still plan to go to 11.23.
1.) Good, yes this is good.
2.) I agree once again.
3.) Once again.
Avoid it as if it was the plague. We tested it on our core applications and it cost us 70% on performance. This makes your assumption of short term use of Aries VERY problematic. You are much better going through a re-compile and finding a way to NEVER run on Aries. HP Israel has offered us generous support in getting our applications re-compiled.
I surely hope this input is of value.
Owner of ISN Corporation
08-21-2007 02:58 AM
We cannot go to 11.31 as it's not a "standard yet".. our client dictates the OS version we need to be at.
And it's not an "upgrade" we're doing... it'll be fresh 11.23 golden images.
Geoff, in your experience... do 11.11 Environment Built EXES run seamlessly on 11.23 PARISC? Any gotchas that youv;ve encountered? Of course at a later date - we'll be establishing our 11.23 PARISC build environments.
And as far as source codes.. whatever bug fixes that are applicable on 11.23 PARISC should also be applicabale on Itanium 11.23 builds -- right? I guess what I'm asking is -- supposing our 11.23 BUILD/DEV environments is already fine and dandy - and we now have Itanium hardware, should we just continue on using our BUILD/DEV environment and churn out Itanium Native 11.23 Executables w/o issues?
08-21-2007 03:07 AM
08-21-2007 04:49 AM
11.23 is supposed to run 11.11 built execs seemlessly.
I havn't had any issues - that said - for our App servers - SAP was installed - we didn't just do a restore/copy from 11.11 servers.
Same for db's - dba's installed Oracle from scratch - but the database files were just "moved" over.
08-21-2007 04:49 AM
Without knowing exactly what you are running in terms of applications I would suggest that rather than upgrade to 11i v2 you start at going straight to Itanium. We recently went the straight to Itanium route. We really didn't have a choice since some of our hardware was not supported on 11i v2, mainly SCSI and tape drives. That is something to look out for.
I would rather get your dev and test environments set up on Itanium and start the process from there. You will still encounter problems and I don't see any reason why you would want to do the same work twice. Don't underestimate the amount of time it will take to get all your binaries compiled, even if you have the necessary skills in house to do it. I assume you have access to all the source code. Including libraries. Third party applications and support can however be a problem. A thorough checklist and documentation of all applications will help greatly.
Also the longer you can extend your timeline the better.
Plan around your data conversion, being an Oracle shop we essentially couldn't use the same datafiles so we had to work out how to move 800GB's of data from one platform to the other with minimal or no downtime. In the end we had less than 2 hours worth, but a lot of pain when it came to the testing beforehand since we picked up corruption when we imported our data. That alone delayed us a month!
Do NOT use Aries for anything other than applications you cannot convert.
Essentially we followed a similar route to what you have planned except we first built a small mini system from scratch on an rx2600 as a practical evaluation, then a proof of concept where we built two systems, one on an rx4600 and another on an IBM machine to test performance as a proof of concept and only then did we start the conversion process properly but at that stage we certianly knew what were in for.
We were fortunate that we only had two binaries that needed Aries, both of which were from companies that were merged with others and these particular products discontinued. Neither of these apps could be counted as strategic though.
Lastly do a lot of planning for this, OK maybe this is the project manager part of me showing, but don't underestimate the scope of work needed. The final conversion took a team of 8, excluding testers and HP staff, 4 months to complete.
08-21-2007 04:58 AM
Our experience, to reiterate is that Aries does not run our pa-risc executables in an acceptable fashion.
If by smoothly you mean, will they run, well I have to admit they did run. The performance was abominable and in realistic testing delivering systems using the Aries emulator, even for one day of use was judged as unacceptable.
We ran our core business application under the environment.
Owner of ISN Corporation
08-21-2007 05:40 AM
I was surprised to hear that your datafiles from an 11.11 Parisc system couldn't be copied over to an 11.23 (or 11.3) Itanium.
Can anyone else please comment on this point?I was planning to move next year as well and was pretty much banking on not having to convert datafiles in a go-live weekend cutover.
08-21-2007 06:14 AM
Apologies for being slightly misleading/confusing. Oracle database files are binary compatable from HP-UX to HP-UX between PARISC and Itanium and under most circumstances they should work. Our complication was related to an import from another Oracle database on a Linux server which we had done as part of the consolidation project had introduced corruption into the database. The PA-RISC version didn't have a problem with the data but when we moved it onto the Itanium server suddenly our row counts didn't match the system tables any longer.
In order to make sure our system downtime was minimal we had created a standby database and mirrored the changes (essentially log replays) between our live and standby databases. The plan was then to make the standby database the live database. However it was when we did integrity tests before taking the standby database online that we discovered the problem.
I hope I have explained this adequately, not being a DBA all of this is second hand.
The point I was trying to make is that you need to factor in data conversion time into your project and remember to test before you go live. Lastly always have a backout plan.
Again apologies for the confusion.
08-21-2007 06:29 AM
There is a relatively painless conversion procedure to take oracle data between IA64 and PA-RISC or vice versa.
Andrew is right, you need to factor in some time for conversion. The procedures are generally done by DBA's using instructions from metalink.oracle.com . Last I heard you had a few DBA's around there so you should consult with them on this for your project plan. I think we have a former DBA from your parent company on staff where I work now. :-) He's pretty good.
Best of Luck,
Owner of ISN Corporation
08-21-2007 06:39 AM
But, to clarify: You had row-count issues with the data brought over the PA-Risc system?
Thanks, and please forgive the intrusion onto Nelson's post, but I need this information as it would throw a big monkey wrench in my plans if this step of the conversion is a known problem. Apologies.
08-21-2007 07:48 AM
If you went to the forum - the download is free.
I don't believe we are allowed to post it here.
08-21-2007 08:02 AM
Our apps are simple... just Oracle 10G DBs mixed with homegrown Cobol, Syncsort compiled C/C++/Cobol Apps... some GNU Tools and java.
Thanks so far for your inputs...
Geoff.. can you please post the URL to the HPTF 2007 presentations? I attended and have not cheked yet if the presentations are already available..
08-21-2007 08:22 AM
Part way down the page is a link:
Presentations are now available for download (2007 attendees only). For presentations in PowerPoint 2007 format, please download a converter for viewing in earlier versions.
Â» Download presentations
Login, then go to "Session Catalog"
In the "Session ID" colum, you will see an icon - clcik on it to download presentation.
08-21-2007 05:12 PM
As Steven says it should be OK, but do a test run before the time to make sure it works. I chatted to my DBA's last night after the post and they said our problem was caused by a bug in DataPump which was used to bring the data from an Oracle 10G database on Linux into an Oracle 9i database on PA-RISC. On the other 10 databases we moved there were no problems, unfortunately it was our biggest that had the problem.
A suggestion is if its possible (and your Oracle licensing allows) create a standby database on the Itanium server in advance and replay changes from the one to the other.
That will give you time to do whatever testing is needed before your cutover and minimizes the cutover time as well.
08-21-2007 05:22 PM
Yes. A "select count *" would return a value less than the number of records refelected in the system table. The system table would be the same as the select count * on the PA-RISC box but different on the Itanium.
We had to fix the PA-RISC box data and then try again.
By this stage we had got really paranoid.
08-21-2007 06:20 PM
No. HP's compilers are completely different.
>supposing our 11.23 BUILD/DEV environments is already fine and dandy - and we now have Itanium hardware, should we just continue on using our BUILD/DEV environment and churn out Itanium Native 11.23 Executables w/o issues?
If by BUILD/DEV you include HP's compilers, no, you'll need new IPF ones.
08-23-2007 02:29 AM
Of course we'll be using Native IPF HP aCC/C++/GNU/Javac compilers.
But generally though - when we cut over our BUILD/DEV environments, our entire Build Trees will remain the same. We'll now simply be using 11.23 IPF development tools and compilers - and this is actually where I'm interesetd -- should we expect our builds should still proceed without much hitches?
Of course the answer will be to test/sanitize/test/test/test... It is this transition that is UNKNOWN to us right now. As we do builds and distributions practically ever night or a couple of nights.
But I guess the solution would be a few weeks before the Itanium roll out.. we also have a parallel Itanium only build and test environments right? -- So this essentially negates the need to convert to 11.23 this early and instead do it when the Itanium rollout is at hand?
08-23-2007 03:13 AM
I think having a parellel environment is a good idea.
HP claims that they can help overcome any problems encountered. You claim your applications are simple.
I would still have the parellel environment ready depending on how critical it is to continue development and what the cost of delays are in terms of monetary value and negative impact on your career.
If you have the funding, having an option is a good idea.
Owner of ISN Corporation
08-23-2007 05:43 AM
I am assuming you are replacing everything in your infrastructure.
My suggestion would be the following process.
1) Set up a prototype build environment to do all your initial code conversions.
2) Set up a prototype test/live environment just to see that the final builds would work and what change issues you may have in terms of code and processes.
3) Setup up the final Dev and Build environments. This will include any revisions to processes due to different/ newer toolsets. Run these in parallel to the existing environments. Your developers will complain about doing things twice.
4) Build the final Test and Prod/Test environment and test extensively.
As part of the signoff process for each system, milestones and criteria should be established. These should include not only functional milestones but also performance milestones. IMHO most conversions include the former but seldom take into consideration the latter. The entire production cycle should be tested.
I'm also not sure what sort of change control and documentation requirements you would have. The last conversion we did, the cutomer had really strict ISO documentation requirements which included a full standby site in another city. Factor in time for that process too.
Other factors to consider are the usual infrastructure considerations like power, cooling, racking and networking. Although I suspect larger international organisations are more spoilt in terms of facilities than most datacenters here in Africa, if and when such things exist.
08-23-2007 06:12 AM
As I said, the C/C++ compiler on IPF is completely different and stricter for C++. (You don't have to port to 64 bit.)
When you go to IPF, you must port aC++ from -AP to -AA. There are links on the aC++ page:
You can of course download Cadvise for PA and see what issues you would have.
I'm not sure how hard it would be to move some of your build processes to HP's testdrive machines:
>We'll now simply be using 11.23 IPF development tools and compilers - and this is actually where I'm interested -- should we expect our builds should still proceed without much hitches?
For C, yes. But as much as we'd like to say no problems for aC++, you should plan for them.
>But I guess the solution would be a few weeks before the Itanium roll out.. we also have a parallel Itanium only build and test environments right?
I don't think that is long enough unless you want to use Aries.
>So this essentially negates the need to convert to 11.23 this early and instead do it when the Itanium rollout is at hand?
You interested in bridges in NYC? ;-)
Well, I don't think it real issue is 11.23 but to the IPF tool chain.
>SEP: I would still have the parallel environment ready depending on how critical it is to continue development
Exactly. Andrew has some good suggestions too.