Taking the plunge, migrating to LINUX

1. Taking the plunge, migrating to LINUX John PetersJRPJR, Inc. john.peters@jrpjr.com John Peters, JRPJR, Inc.

2. Before We Start A Quick Audience Survey • How many of you have considered running the OraApps on LINUX? • How many of you are in the process of migrating to LINUX? • How many of you are currently running the OraApps on LINUX? • How many are currently running on:HP/UX? Solaris? AIX? Windows? • How many of you are on 11.5.10? 11.5.9? • How many of you are using 10G of the DB? John Peters, JRPJR, Inc.

3. What we are going to cover • What migrates to LINUX? • When would you want to migrate to LINUX? • Why migrate to LINUX? • The steps to migrate to LINUX • Other Considerations • Case study of a LINUX migration • Original Environment • LINUX Environment • Performance comparisons • 11.5.10.2 Upgrade Information • 10G DB Upgrade Information John Peters, JRPJR, Inc.

4. What migrates to LINUX? • This paper will deal primarily with running the OraApps code on LINUX, while leaving the DB on an existing non-LINUX server, (HP/UX). • No OraApps code on any non-LINUX server. • Single OS for OraApps Patches and DB Patches • Only the DB on non-LINUX server. • This is probably the most straight forward migration. This has been Oracle’s recommended approach for some time now. • Migrating the DB requires a full DB export/import. • You probably have the original server still available. John Peters, JRPJR, Inc.

5. OraApps Linux Configuration • DB resides on a SAN device • OraApps components on single LINUX server • Local LINUX disks used for OraApps code John Peters, JRPJR, Inc.

6. When to migrate to LINUX? • Typically advantageous when existing system resources become constrained and RAM/CPU upgrades are required. Or • When hardware additions are required for security reasons, (reverse proxy DMZ server) • Probably also done during an OraApps upgrade, (due to testing requirements). John Peters, JRPJR, Inc.

7. Why migrate to LINUX Intel won the CPU battles John Peters, JRPJR, Inc.

8. Why migrate to LINUX • Lower Systems Cost • HP RP7410 HP9000, $130K (2002) • 4 – 750MHZ Processors • 12GB • HP/UX • DL385 Proliant, $15K • 2 – 2.4GHZ Processors • 16GB • RedHat LINUX John Peters, JRPJR, Inc.

9. Why migrate to LINUX? • Lower Component Cost (for Upgrades) • CPU • HP9000, 750MHz -> $8,000 • Intel/AMD, 2GHZ -> $600 • Memory • HP9000, 2GB -> $3,000 • Intel/AMD, 2GB -> $700 • Internal Disks • HP9000, 72GB 10k -> $1,000 • Intel/AMD, 72GB 10k -> $300 John Peters, JRPJR, Inc.

10. The steps to migrate to LINUX • Start with Oracle’s Note 238276.1‘Migrating to Linux with Oracle Applications Release 11i’, last update Oct. 17, 2005 • However, there are many extra steps I will discuss in a few minutes. John Peters, JRPJR, Inc.

11. Migrate to LINUX before or after upgrade • No single answer for everyone. • No recommendation from Oracle. John Peters, JRPJR, Inc.

12. Migrate to LINUX before upgrade • Benefits • You get the performance benefits on the LINUX servers during the upgrade • You can pre-stage the LINUX server, not done during downtime weekend • Drawbacks • You are committed to LINUX, no fall back strategy • You must make this decision at the beginning of the upgrade project • Requires pre-upgrade patching to perform LINUX migration John Peters, JRPJR, Inc.

13. Migrate to LINUX after upgrade • Benefits • You can roll back to the existing server if issues come up • If you run out of time during the upgrade weekend you can go live with the existing server • Final version TechStack (off of 11.5.10.2 CD) • Drawbacks • Dual testing of OraApps on the existing and LINUX server (to support roll back) • Slower upgrade performance • I prefer this migration path John Peters, JRPJR, Inc.

14. Summary of Steps • Install Tech Stack on LINUX • Copy non-Tech Stack (OraApps) code from source server to LINUX • Apply customer specific patch which provides LINUX libraries • Relink bin code John Peters, JRPJR, Inc.

15. High Level Steps • Prep work on the source server(Note 238276.1, Section 1) • Probably all steps you have already done, or should have done • If not they probably require user testing • Migration from source to destination server(Note 238276.1, Section 2) • Majority of steps can be done prior to down time • Oracle does not specify down time steps • Finishing Tasks(Note 238276.1, Section 3) John Peters, JRPJR, Inc.

16. Prep work on the source server • DB must be minimum of 8.1.7.4 • Must be on 11i AD, G • Autoconfig must be implemented • Maintain snapshot (adadmin) • Software Version (source server) • PERL 5.005 (usually not an issue) • JVM 1.4.2 (requires JInitiator 1.3.1.21) • See note 246105.1, (run with single JVM version) • LINUX Kernal Parms/Packages (target server) • See note 287453.1 John Peters, JRPJR, Inc.

17. Prep work on the source server • Get these steps in PROD before starting Migration Project, possibly with other testing cycles. • Then each TEST clone will have them ready to go. • There are a few more steps in the later sections to also include. I will flag them. • Order LINUX OraApps Rapid Install Pack for final version John Peters, JRPJR, Inc.

18. Migration from source to destination server • Apply Platform Migration Utility Patch(get this in PROD in advance) • Generate and Upload Manifest • Run a script on your server, then upload to Oracle Support • This builds a list of all your Oracle Supplied lib files • This will be used to generate a custom patch just for your environment • Patch is generally ready to download from Metalink within a day • Don’t do this until you have frozen the PROD environment, step probably belongs after 11 John Peters, JRPJR, Inc.

19. Migration from source to destination server • Create the Target System APPL_TOP • Copy the following file systems from source to target • APPL_TOP • OA_HTML • OA_JAVA • COMMON_TOP/util • COMMON_TOP/_pages • Copy JInitiator security files • JInitiator 1.3.1.21 uses a different security file mechanism John Peters, JRPJR, Inc.

20. Migration from source to destination server • Clone the AutoConfig XML file(on target system) • Install Middle Tier Tech Stack(on target system) • Rapid Install Wizard –techstack option • Installs: ORACLE_HOME & IAS_ORACLE_HOME • Apply Oracle InterOp Patches for Linux John Peters, JRPJR, Inc.

21. Migration from source to destination server • AutoConfig Target System • Critical to include INSTE8_SETUP option • Download and Apply Customer Specific Update Patch(on target system) • Probably belongs after step 11 • Apply Patch if Source System is Windows(on target system) John Peters, JRPJR, Inc.

22. Migration from source to destination server • Reapply Tech Stack Patches(on target system) • Apply TechStack InterOp Patch(on target system) This is where I would insert customer specific patch (steps 2 & 8) John Peters, JRPJR, Inc.

23. Migration from source to destination server • Regenerate File System Objects(on target system) • This regenerates all bin files, using lib’s in customer specific patch • Messages, Forms, Reports, Graphics and JAR files regenerated John Peters, JRPJR, Inc.

24. Migration from source to destination server This requires down time at this point. • AutoConfig Target System • Stop all OraApps processes on Source System • Messages, Forms, Reports, Graphics and JAR files regenerated John Peters, JRPJR, Inc.

25. Finishing Tasks • 3rd Party Libraries • ILOG (any MFG modules) • QUANTUM (Vertex Tax Integration) • ROGUEWAVE (???) • Customizations • Forms • C Code • OraApps Printer Name Changes John Peters, JRPJR, Inc.

26. Finishing Tasks • Update Workflow Cartridge Config(AutoConfig changed values) • Verify and Fix CLASSPATH • Start Target Services Down Time Completed John Peters, JRPJR, Inc.

27. Real World • Perform the above three groups of steps in the TEST instance. • Copy TEST LINUX server to PROD LINUX server • RapidClone • AutoConfig This process takes less than an hour during the downtime weekend John Peters, JRPJR, Inc.

28. Other Considerations • Post Processing Printing • Printing now occurs on LINUX Concurrent Processing Tier • RSH/RCP script to send output back to source server • Email • Email is sent on the LINUX server by Notification Mailer • Startup and Shutdown Scripts • Start DB Tier (source server) • Start OraApps Tier (target server) • No Oracle Solution • Manually, or use RSH to automate • User access URL changes • Virtual DNS Entry, prod.mycompany.com • iPayment Integrations • Certificates • Custom Code • Positive Pay Transfer Routines • Custom Executable Per Bank John Peters, JRPJR, Inc.

29. Case Study • Bay Area company • Financials (AP, AR, GL, FA) • Discrete Manufacturing • Order Management • Service Contracts/Installed Base • iStore/iPayment • Currently Domestic OraApps Users Only • ~75 Concurrent Users • 150GB Database John Peters, JRPJR, Inc.

30. What was changed • HP/UX OS Patching • OraApps from 11.5.9 to 11.5.10.2 • JVM Upgrade • License/Patch new modules • ICM • Field Service • Customer Care/Call Center • Email Center • EPB • Oracle Security Patches • JInitiator upgrade (required desktop rollout) • Web ADI • Migrate OraApps to LINUX • Started on 11/23 17:00, Finished on 11/27 10:00 John Peters, JRPJR, Inc.

31. Original Configuration • Single Tier Server • HP9000, RP7410 • 4 - CPU 750MHZ • 12GB • OraApps 11.5.9 • DB 8.1.7.4 • 9i instance for Content Management System • OFA, Oracle Express • Experienced performance issues • CPU 100% from time to time through out day John Peters, JRPJR, Inc.

32. New Configuration • DB Tier Server • HP9000, RP7410 • 4 - CPU 750MHZ • 12GB • DB 10.1.0.4 (OraApps Instance) • 9i instance for Content Management System • OFA, Oracle Express (to be phased out by EPB) John Peters, JRPJR, Inc.

33. New Configuration • OraApps Tier Server • HP DL385 Proliant Server • 2 - CPU 2.4GHZ • 16GB • RedHat LINUX • All OraApps Code • Allows for future Reverse DMZ Server for iStore Users John Peters, JRPJR, Inc.

34. New Configuration • We can run 3 OraApps TEST Instances on a single LINUX server • CPU Utilization >95% idle • Plenty of free memory John Peters, JRPJR, Inc.

35. Performance • DB Tier now rarely hits 100% CPU utilization • OraApps Tier rarely goes over 5% CPU utilization • HTML users noticeable improvement in speed • OraApps Forms users have seen a mixed bag, primarily due to 11.5.10.2/10G DB Performance Issues John Peters, JRPJR, Inc.

36. DB CPU Performance John Peters, JRPJR, Inc.

37. DB CPU Performance John Peters, JRPJR, Inc.

38. MRP Performance John Peters, JRPJR, Inc.

39. Summary • I think it is inevitable that OraApps customers will be running the OraApps on LINUX based Intel architecture CPU’s due to the following: • Cost vs Performance • Phase out of proprietary RISC CPU’s • HP has already phased out PA-RISC • SUN is using AMD CPU’s, what is the future of SPARC? • Oracle’s Support for other OS’s (limited availability of patches) • The ease to migrate OraApps to LINUX • Next will be the Database, many new OraApps customers are just starting off on LINUX. John Peters, JRPJR, Inc.

40. My contact information: John Petersjohn.peters@jrpjr.com http://www.jrpjr.com • Additional reference papers can be found at:http://www.norcaloaug.org http://www.jrpjr.com John Peters, JRPJR, Inc.