Taking the plunge, migrating to LINUX

1
Taking the plunge, migrating to LINUX

• John PetersJRPJR, Inc.
• john.peters_at_jrpjr.com

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 onHP/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?

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

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 Oracles recommended
  approach for some time now.
• Migrating the DB requires a full DB
  export/import.
• You probably have the original server still
  available.

5
OraApps Linux Configuration

• DB resides on a SAN device
• OraApps components on single LINUX server
• Local LINUX disks used for OraApps code

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).

7
Why migrate to LINUX

• Intel won the CPU battles

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

9
Why migrate to LINUX?

• Lower Component Cost (for Upgrades)
• CPU
• HP9000, 750MHz -gt 8,000
• Intel/AMD, 2GHZ -gt 600
• Memory
• HP9000, 2GB -gt 3,000
• Intel/AMD, 2GB -gt 700
• Internal Disks
• HP9000, 72GB 10k -gt 1,000
• Intel/AMD, 72GB 10k -gt 300

10
The steps to migrate to LINUX

• Start with Oracles Note 238276.1Migrating 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.

11
Migrate to LINUX before or after upgrade

• No single answer for everyone.
• No recommendation from Oracle.

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

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

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

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)

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

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

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
• Dont do this until you have frozen the PROD
  environment, step probably belongs after 11

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

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

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)

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)

23
Migration from source to destination server

• Regenerate File System Objects(on target system)
  
• This regenerates all bin files, using libs in
  customer specific patch
• Messages, Forms, Reports, Graphics and JAR files
  regenerated

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

25
Finishing Tasks

• 3rd Party Libraries
• ILOG (any MFG modules)
• QUANTUM (Vertex Tax Integration)
• ROGUEWAVE (???)
• Customizations
• Forms
• C Code
• OraApps Printer Name Changes

26
Finishing Tasks

• Update Workflow Cartridge Config(AutoConfig
  changed values)
• Verify and Fix CLASSPATH
• Start Target Services
• Down Time Completed

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

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

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

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 1700, Finished on 11/27 1000

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

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)

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

34
New Configuration

• We can run 3 OraApps TEST Instances on a single
  LINUX server
• CPU Utilization gt95 idle
• Plenty of free memory

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

36
DB CPU Performance
37
DB CPU Performance
38
MRP Performance
39
Summary

• I think it is inevitable that OraApps customers
  will be running the OraApps on LINUX based Intel
  architecture CPUs due to the following
• Cost vs Performance
• Phase out of proprietary RISC CPUs
• HP has already phased out PA-RISC
• SUN is using AMD CPUs, what is the future of
  SPARC?
• Oracles Support for other OSs (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.

40

• My contact information
• John Petersjohn.peters_at_jrpjr.com
  http//www.jrpjr.com
• Additional reference papers can be found
  athttp//www.norcaloaug.org
• http//www.jrpjr.com