1. Choosing the Right Mass Deployment Strategy for Oracle Database 10 g Software Sudip Datta Principal Product Manager Oracle Corporation

2. Agenda  Part 1 – Software deployment challenges – Basic best practice operations – Operational entities-nuts and bolts  Part 2 – Case study: Enterprise Manager 10 g

3. Software Deployment challenges

4. Data center labor distribution Source: Giga Forrester research,2003

5. Life Cycle Management Install and Configure Activate Upgrade And Update Install Configure Activate Operate Clone Upgrade Patch Uninstall Deactivate

6.  Wide distribution of hosts  Variety of platforms and versions  Different hardware and network topologies  Too many moving parts for administration  Security vulnerabilities-frequent interim patching – According to a recent Aberdeen group study, patch handling costs businesses in excess of 2 billion dollars annually. For a leading service provider, the cost was reported to be as high as $14,400 per server  All the above lead to high IT Management costs Challenges

7. Basic best practice operations

8. 10 g database software ontology  Immutable Files – Original  Objects, classes, message files – Derived  Relinked executables, some library archives  Mutable files – Configuration files like init.ora, tnsnames.ora – Oracle inventory

9. Physical Cloning  Build a stage consisting of a base image optionally patched with a patchset and/or one-offs  Copy the stage as-is to other nodes  Use secure transfer to make sure that bits are distributed reliably  Make target specific changes to environment and inventory

10. Physical Cloning-Merits and limitations  Merits – Trusted and Scalable – Software can be tested at source and deployed  Limitations – Multi NLS deployments – Multi-platform deployments

11. Logical cloning  Replay the operations as-is in the same order  Works on staged software components and not on final bits  Operations may consist of – Silent install – Silent upgrade – Silent patch

12. Logical Cloning-merits and limitations  Merits – Works for multi NLS environment – Works for a fragmented platform distribution  Limitations – More time consuming and less scalable – Results in less trusted deployments – Cannot deploy a fully patched software in one go

13. Incremental operations  Checksum based approach – Propagate deltas  Logical approach – Use opatch at the targets – Frequent one offs not recommended  Hybrid model – Physical cloning for initial deployment – Logical operations for one-off

14. Operational entities-the nuts and bolts

15. Oracle software inventory  Hierarchical structure in every host – Central Inventory pointer  Central inventory ­Local Inventory within ORACLE_HOME  There can be multiple central inventories to support the hosted environments  Each central inventory contain pointers to a set of ORACLE_HOMEs  Local inventory contains components, versions and patches  Enterprise Manager host collection collects information from inventories  Inventory is updated during install,patch,upgrade

16. Oracle software Inventory (contd) Central Inventory pointer Central inventory Central Inventory Oracle Home 1 Oracle Home 2 Oracle Home 3 Oracle Home 4

17. Interactive Install  GUI driven-requires X configuration on Unix  Single click enabled for database 10 g on Windows  Can be invoked in recordmode to capture session variables in responsefiles. –./runInstaller –recordmode –responsefile  Not scalable in a large environment

18. Http based install  OUI supports software staged in a central application server – More reliable and open than shared filesystem  Both interactive and silent install supports http install – FROM_LOCATION should point to the products.xml file.  Supports firewalls between source and target

19. Silent Install  Supports different installation flows  Scalable for mass deployment  Can be scheduled from a job subsystem  Can be chained with silent configuration tools (dbca, netca etc)  Used by third party vendors like Opsware, HP, ASDIS among others  Not suitable for deploying ‘patched’ and ‘tested’ bits

20. Patch engine  Opatch-the single patching interface from 9iR2 onwards  Pre-requisite checks include operating system, component and version  Conflict detection and superset handling  Integrates with inventory via OUI APIS  Callable from a job subsystem in silent mode

21. Cloning  New Installer mode with OUI 10 g, functionally equivalent to install  Retains ‘patched’ bits  Makes context specific inventory changes  The new installation can participate in bigger system management  Smaller footprint helps in cloning

22. Operation mappings Data center operation Oracle operationBackend Engine First time install on sandbox Interactive install Silent install OUI CloningEM cloning/ OUI cloningOUI clone mode Logical large scale deployments Silent install from http/NFS stage OUI in silent mode Interim patchingEM patching via job subsystem Opatch and job subsystem Compliance tracking Collection from inventories OUI APIs

23. Case study: Enterprise Manager 10g

24. EM enabled practices  Enterprise Manager 10gR1 adopts a hybrid model – Physical cloning – Logical incremental one off patching  Job subsystem can perform silent installation as well  Compliance tracking

25. EM Cloning - choose source

26. EM Cloning - provide source settings

27. EM Cloning – specify destination

28. EM Cloning – schedule job

29. Post deployment practices “After a software system is packaged and released the software producer must have an effective mechanism to advertise the release in order to notify interested consumers of its existence. There is little benefit for the software producer if its customers, both current and potential, are unaware of its products and services.”- Ricahrd Scott Hall [1][1] “Agent-based Software Configuration and Deployment” by Richard Scott Hall, B.S., University of Michigan, 1990,M.S., University of Colorado, 1993

30. EM enabled practices  Set up Enterprise Policies  Compliance checking – Software version and patchsets – Patches – Configuration parameters – Database features  Corrective action against deviations

31. Compliance tracking via search

32. Overall configuration search

33. Compliance tracking through comparison

38. Summary  Build and clone method is the most scalable option  Deployment has to be tied with overall lifecycle management  Compliance has to be tracked  Enterprise Manager 10 g Grid Control implements some of the best practices.

39. Thank you