TeMIP Oracle Use Reference Guide

8/18/2019 TeMIP Oracle Use Reference Guide

1/128

HP TeMIP Software

Oracle Use Reference Guide

Edition: 6.1

for the UNIX Operating System

November 2011

© Copyright 2011 Hewlett-Packard Development Company, L.P.


2/128

2

Legal Notices

Warranty

The information contained herein is subject to change without notice. The onlywarranties for HP products and services are set forth in the express warranty statementsaccompanying such products and services. Nothing herein should be construed asconstituting an additional warranty. HP shall not be liable for technical or editorialerrors or omissions contained herein.

License Requirement and U.S. Government Legend

Confidential computer software. Valid license from HP required for possession, use orcopying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software,Computer Software Documentation, and Technical Data for Commercial Items arelicensed to the U.S. Government under vendor ‟s standard commercial license.

Copyright Notices

© Copyright 2011 Hewlett-Packard Development Company, L.P.

Trademark Notices

Adobe®, Acrobat® and PostScript® are trademarks of Adobe Systems Incorporated.

Red Hat® and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat,Inc. in the United States and other countries.

Linux is a registered trademark of Linus Torvalds.

HP-UX Release 10.20 and later and HP-UX Release 11.00 and later (in both 32 and 64-bitconfigurations) on all HP 9000 computers are Open Group UNIX 95 branded products.

Java ™ is trademark of Oracle and/or its affiliates.

Microsoft®, Windows® and Windows NT® are U.S. registered trademarks of MicrosoftCorporation.

Oracle® is a registered U.S. trademark of Oracle Corporation, Redwood City, California.

UNIX® is a registered trademark of The Open Group.

X/Open® is a registered trademark, and the X device is a trademark of X/Open CompanyLtd. in the UK and other countries.


3/128

3

Contents

List of Figures ............................................................................................................... 7 List of Tables ................................................................................................................ 8 Preface ....................................................................................................................... 10

Chapter 1 Oracle Architecture Fundamentals ............................................ 12 1.1 Server Configuration Principle ......................................................................... 12

1.1.1

OFA Compliance ........................................................................................ 12

1.1.2 Database Layout ......................................................................................... 13 1.1.3 Database Naming Plan ............................................................................... 15 1.1.4 Service Naming Use ................................................................................... 16 1.2 Client Configuration Principle .......................................................................... 18 1.3 Networking ....................................................................................................... 19 1.3.1 Client Side ................................................................................................... 19 1.3.2 Server Side ................................................................................................. 19 1.3.3 Protocol Considerations .............................................................................. 20 1.4 Security ............................................................................................................ 20 1.4.1 User Authentication .................................................................................... 20

1.4.2

User Rights ................................................................................................. 21

1.5 Database Backup and Recovery ..................................................................... 21 1.6 Oracle 11g standard edition ............................................................................. 21 1.6.1 Restriction ................................................................................................... 21 1.6.2 Compatibility with TeMIP databases........................................................... 21

Chapter 2 High Availability within a TeMIP Environment .......................... 22 2.1 Data Read Availability ...................................................................................... 22 2.1.1 Oracle Concepts ......................................................................................... 23 2.1.2 TAF and CTF Use in a TeMIP Environment ............................................... 26 2.2 Data Write Availability ...................................................................................... 27

Chapter 3 Synonyms Service....................................................................... 28 3.1 Overview/Architecture ...................................................................................... 28 3.2 Database Layout and Implementation ............................................................. 30 3.2.1 Synonyms Database Layout ....................................................................... 30 3.2.2 Synonyms Oracle Table Description .......................................................... 31 3.2.3 Synonyms Database Constraints and Indexes ........................................... 33 3.2.4 Synonyms Database Sizing ........................................................................ 36 3.2.5 Synonym Trigger Implementation ............................................................... 37 3.2.6 Synonyms Physical Layout ......................................................................... 39 3.2.7 Replica ........................................................................................................ 40 3.2.8 TeMIP Synonyms Database Implementation ............................................. 40 3.3 High Availability ................................................................................................ 41 3.4 Planning the Database Deployment ................................................................ 41


4/128

4

3.4.1 Constraints and Requirements for using TeMIP Synonyms ....................... 42 3.4.2 Planning Criteria ......................................................................................... 46 3.4.3 Configuration Criteria .................................................................................. 46 3.4.4 Sizing and Performance Criteria ................................................................. 47 3.4.5 Planning Process Overview ........................................................................ 49

3.4.6 Planning TeMIP Synonyms in a Distributed Configuration ......................... 49 3.5 Installation and Configuration .......................................................................... 50 3.5.1 Server Side ................................................................................................. 51 3.5.2 Client Side ................................................................................................... 51 3.5.3 Changing Oracle password ........................................................................ 54 3.6 Caching Mechanism ........................................................................................ 55 3.7 Recovery Mechanism ...................................................................................... 57

Chapter 4 TeMIP Alarm Handling Archiving ............................................... 59 4.1 Archiving Service Overview ............................................................................. 59 4.1.1 Client/Server Architecture ........................................................................... 59

4.1.2

Connectivity Aspects .................................................................................. 59

4.1.3 Archive Directive ......................................................................................... 60 4.2 Archiving Database Layout and Implementation ............................................. 61 4.2.1 Database Layout ......................................................................................... 62 4.2.2 Database Table Description ....................................................................... 62 4.2.3 Database User ............................................................................................ 69 4.2.4 Database Sizing .......................................................................................... 70 4.2.5 Database Physical Layout .......................................................................... 70 4.3 Planning the Archiving Database Deployment ................................................ 70 4.3.1 Constraints and Requirements ................................................................... 70 4.3.2 Planning Criteria ......................................................................................... 71

4.3.3

Configuration Criteria .................................................................................. 71

4.3.4 Sizing and Performance Criteria ................................................................. 71 4.3.5 Planning Process Overview ........................................................................ 72 4.4 Installation and Configuration .......................................................................... 72 4.4.1 Oracle Server .............................................................................................. 72 4.4.2 Oracle Client ............................................................................................... 72 4.4.3 Changing Oracle password ........................................................................ 74

Chapter 5 Hierarchy and Decoration Server ............................................... 77 5.1 Overview .......................................................................................................... 77 5.1.1 Simple Configuration .................................................................................. 78 5.2 Database Layout .............................................................................................. 81 5.2.1 Sizing .......................................................................................................... 81 5.2.2 Triggers ....................................................................................................... 81 5.2.3 TeMIP MAP Database Physical Layout ...................................................... 81 5.2.4 Replica ........................................................................................................ 82 5.3 High Availability ................................................................................................ 82 5.4 Install and Configure ........................................................................................ 82 5.4.1 Server Side ................................................................................................. 82 5.4.2 Client Side ................................................................................................... 84 5.4.3 Changing Oracle password ........................................................................ 87

Chapter 6 Oracle Tools ................................................................................. 89 6.1 Introduction ...................................................................................................... 89 6.2 Oracle Script Installation .................................................................................. 89


5/128

5

6.3 Tool Organization ............................................................................................. 90 6.4 temip_create_database ................................................................................... 91 6.4.1 Interface Description ................................................................................... 91 6.4.2 Functional Description ................................................................................ 92 6.4.3 Advanced Use............................................................................................. 93

6.4.4 Typical Use-Cases ...................................................................................... 94 6.4.5 Troubleshooting .......................................................................................... 96 6.5 temip_delete_database .................................................................................... 97 6.5.1 Interface Description ................................................................................... 97 6.5.2 Functional Description ................................................................................ 98 6.5.3 Typical Use Cases ...................................................................................... 98 6.5.4 Troubleshooting .......................................................................................... 98 6.6 temip_oracle_client_configure ......................................................................... 99 6.6.1 Interface Description ................................................................................... 99 6.6.2 Functional Description ................................................................................ 99

Chapter 7 Oracle Troubleshooting ............................................................ 101

7.1 Managing the Oracle Environment ................................................................ 101 7.1.1 Listener Management ............................................................................... 101 7.1.2 Database Instance Management .............................................................. 102 7.2 Getting Basic Info from an Oracle Instance ................................................... 103 7.2.1 Identifying the Main Database Processes ................................................ 103 7.2.2 Getting Current Database Parameters ..................................................... 103 7.2.3 Finding Database Files ............................................................................. 104 7.3 Fixing Common Oracle Error Messages ........................................................ 104 7.3.1 Common Oracle Network Errors ............................................................... 104 7.3.2 Common Instance Error Messages .......................................................... 106

7.3.3

Help with Error Information ....................................................................... 106

7.3.4 Trace Files ................................................................................................ 106 7.4 Oracle Utilities ................................................................................................ 107 7.4.1 Assistants .................................................................................................. 107 7.4.2 Oracle Controller ....................................................................................... 107 7.4.3 Oracle Enterprise Manager Database Control ......................................... 108

Appendix A Raid Use .................................................................................. 109 A.1 Raid Use ........................................................................................................ 109 A.1.1 RAID 0: Striping With No Parity ................................................................ 109 A.1.2 RAID 1: Shadowing .................................................................................. 109 A.1.3 RAID 0+1: Striping And Shadowing .......................................................... 109 A.1.4 RAID 3: Striping With Static Parity............................................................ 109 A.1.5 RAID 5: Striping With Rotating Parity ....................................................... 110 A.1.6 Summary ................................................................................................... 110 A.2 Disk caching ................................................................................................... 110 A.2.1 Reliability ................................................................................................... 110 A.2.2 Memory Waste .......................................................................................... 111 A.2.3 Performance Expectations ........................................................................ 111 A.2.4 Summary ................................................................................................... 111

Appendix B Relationships in Archiving Tables ........................................ 113 B.1 Cardinality ...................................................................................................... 113 B.2 Archiving Table Diagrams .............................................................................. 114 B.3 Table Information Access Examples ............................................................. 123


6/128

6

Glossary ...................................................................................................... 126

Index ............................................................................................................ 127


7/128

7

List of Figures

Figure 1 Database Naming Plan .................................................................................... 16 Figure 2 Service Naming ................................................................................................ 18 Figure 3 CTF and TAF mixing ........................................................................................ 26 Figure 4 Database Connections Schema Overview ...................................................... 29 Figure 5 Oracle Databases in the TeMIP Environment ................................................. 31 Figure 6 Trigger Implementation in Master Server Configuration .................................. 38 Figure 7 Trigger Implementation in Replica Server Configuration ................................. 38 Figure 8 New Oracle Configuration for TeMIP Synonyms ............................................. 50 Figure 9 Recovery Mechanism in Synonyms Service .................................................... 58 Figure 10 Simple Configuration ........................................................................................ 78 Figure 11 Oracle Server – TeMIP Director ...................................................................... 79

Figure 12 Oracle Server – Two TeMIP Directors ............................................................. 80 Figure 13 Distributed Configuration ................................................................................. 81 Figure 14 Oracle Processes and Architecture ............................................................... 103 Figure 15 AlarmComment Table .................................................................................... 114 Figure 16 CloseBy Table ................................................................................................ 115 Figure 17 Correl Notif Info Tables .................................................................................. 116 Figure 18 HandledBy Table ........................................................................................... 117 Figure 19 Monitored Attributes Table ............................................................................. 117 Figure 20 Proposed Repair Action Tables ..................................................................... 118 Figure 21 Specific Problem Tables ................................................................................ 119 Figure 22 StateChangeDefinition Tables ....................................................................... 120

Figure 23 Target Entities Table ...................................................................................... 121 Figure 24 Threshold Info Tables .................................................................................... 122


8/128

8

List of Tables

Table 1 Database Mount Point Layout Table ............................................................... 14 Table 2 Database SID Table ......................................................................................... 15 Table 3 Database Service Table ................................................................................... 17 Table 4 TeMIP Database User Names ......................................................................... 20 Table 5 ASCII Synonyms Database ............................................................................. 32 Table 6 IP Synonyms Database ................................................................................... 32 Table 7 OSIDN Synonyms Database ........................................................................... 32 Table 8 Algorithmic Synonyms Database ..................................................................... 32 Table 9 Class Synonyms Class Table Database .......................................................... 33 Table 10 Class Synonyms Instance Table Database ..................................................... 33 Table 11 Instance Name Synonyms Class Table Database .......................................... 33

Table 12 Instance Name Synonyms Instance Table Database ...................................... 33 Table 13 ASCII Synonyms Constraints........................................................................... 33 Table 14 ASCII Synonyms Indexes ................................................................................ 34 Table 15 IP Synonyms Constraints ................................................................................. 34 Table 16 IP Synonyms Indexes ...................................................................................... 34 Table 17 OSIDN Synonyms Constraints ........................................................................ 34 Table 18 OSIDN Synonyms Indexes .............................................................................. 35 Table 19 Algo Synonyms Constraints ............................................................................. 35 Table 20 Algo Synonyms Indexes .................................................................................. 35 Table 21 Class Synonyms Constraints ........................................................................... 35 Table 22 Class Synonyms Indexes ................................................................................ 35

Table 23 Instance Name Synonyms Class Constraints.................................................. 36 Table 24 Instance Name Synonyms Table Constraints.................................................. 36 Table 25 Instance Name Synonyms Table Indexes ....................................................... 36 Table 26 Synonym Database Predefined Database Size............................................... 36 Table 27 Synonyms Physical Layout .............................................................................. 39 Table 28 Oracle Table Instances .................................................................................... 41 Table 29 Archiving Database Layout .............................................................................. 62 Table 30 Alarm Object Table .......................................................................................... 62 Table 31 AlarmComment Table ...................................................................................... 64 Table 32 ClosedBy Table ................................................................................................ 65 Table 33 CorrelNotifInfo Tables ...................................................................................... 65

Table 34 HandledBy Table ............................................................................................. 66 Table 35 MonitoredAttributes Table ................................................................................ 66 Table 36 ProposedRepairActions Tables ....................................................................... 66 Table 37 SpecificProblems Tables ................................................................................. 67 Table 38 StateChangeDefinition Tables ......................................................................... 68 Table 39 TargetEntities Tables ....................................................................................... 68 Table 40 ThresholdInfo Tables ....................................................................................... 69 Table 41 Pre-Defined Database Size ............................................................................. 70 Table 42 Archiving Physical Layout ................................................................................ 70 Table 43 MAP Database Predefined Database Size ...................................................... 81 Table 44 MAP Database Physical Layout ...................................................................... 81

Table 45

Common Oracle Network Errors .................................................................... 105

Table 46 Common Oracle Errors .................................................................................. 106


9/128

9

Table 47 RAID Use Table ............................................................................................. 110 Table 48 Disk Caching Recommendation .................................................................... 111


10/128

10

Preface

This document describes the global Oracle approach implemented acrossTeMIP applications. It helps to understand the TeMIP/Oracleenvironment and describes the adopted standards. It also shows how toset up databases and adapt them to customer specific requirements andconstraints.

The TeMIP databases addressed by this document are the following:

TeMIP Alarm Handling archive database

TeMIP MAP database TeMIP Synonyms database

Oracle Software installation is out of the scope of this reference guide.

Intended AudienceThis document is aimed at the following personnel:

Solution Architects

System Managers

Database Administrators

TeMIP Administrators

System Integrators

Prior knowledge of Oracle is a prerequisite to fully appreciate the contentsof this document.

Supported SoftwareThe supported software referred to in this document is as follows:

Product Version Operating Systems

HP TeMIP SoftwareFramework FullServer 6.1

HP-UX 11.31 (Itanium)RHEL 5.x

The term UNIX is used as a generic reference to the operating system,unless otherwise specified.


11/128


12/128

12

Chapter 1Oracle Architecture Fundamentals

1.1 Server Configuration PrincipleTeMIP implements a global approach to the Oracle product. In earlierversions, each TeMIP MM had its own database naming, deployment andlayout scheme. From TeMIP V5.0, Oracle use is standardized in order tofit Oracle standards as well as internal TeMIP guidelines.

The next sections introduce these TeMIP standards. A dedicated chapterdescribes the tools associated with this global Oracle approach and theway of customizing the standard deployments to best fit internal customerstandards or map available hardware configurations (disk usagerationalization and optimization). Chapter 6 introduces the TeMIPscripts.

1.1.1 OFA ComplianceThe TeMIP database layout is compliant with the Optimal Flexible

Architecture (OFA) described in the Oracle documentation. The mainbenefits are the improvement of database maintainability andrecoverability.

In particular it:

Organizes large amounts of complicated software and data on disk toavoid device bottlenecks and poor performance.

Facilitates routine administrative tasks, such as software and databackup functions, which are often vulnerable to data corruption.

Alleviates switching between multiple Oracle databases.

Manages and administers database growth.

Helps to eliminate fragmentation of free space in the data dictionary,isolate other fragmentation and minimize resource conflicts.

The main difference with OFA is that the Oracle „applicative‟ and „userdata‟ mount points are not directly created under the root directo ry butgrouped under /usr/ORACLE. This location will now be called theORACLE_ROOT. It is settable if required and can even be reduced to /.

This leads to the next mount point definitions (using Oracle terminology):

Software mount point : /usr/ORACLE/u01

User data mount points : /usr/ORACLE/u02….u10 (9 data mountpoints are pre-defined)

And according to OFA:

ORACLE_BASE is mandatory and refers to:Software_mount_point/app/oracle.

ORACLE_HOME is defined as $ORACLE_BASE/product/release


13/128

13

The ORACLE_HOME for the “Oracle 11g release 2 ” server would be:

/usr/ORACLE/u01/app/oracle/product/11.2.0

The database name ( dbname ) used to describe the next directory structureis equal to the database SID in the TeMIP environment where no multipleinstance databases are used.

The Database admin location will be created with the followingsubdirectories:

ORACLE_BASE/admin/dbname/adhoc Ad hoc SQL scripts

/adump Audit files

/arch Archived re-do log files

/bdump Background process trace files

/cdump Core dump files

/create Programs used to create thedatabase

/exp Database export files

/pfile Initialization parameter files

/udump User SQL trace files

/logbook Files recording the status andhistory of the database

The pure database datafiles are spread over the user data mount points(u02 to 10). The only difference with OFA is that the „dbname‟ directories

are split into sub-directories that organize the database files by type:

user_data_mount_point/oradata/dbname/DATA Any User data files

/UNDO Any undo segments

/TEMP Any Temporary tablespace files

/LOB Available for separate LOBstorage

/IDX Any index

/SYSTEM System and sysaux tablespacefiles

/TOOLS For any tools tablespace datafile

/REDO Any redo log file

/CRT Any control file

This subdivision helps to identify file types at a glance and can be used tomap additional mount points if needed.

1.1.2 Database LayoutDisk repartition is a key aspect for performance and reliability. Thissection describes the default mapping of the database files over the pre-defined user data mount points.


14/128

14

The next table details the nine user data mount points and their defaultallocations.

Table 1 Database Mount Point Layout Table

Data Mount Point Value(default)

Default Mount Point Allocation for all TeMIPDatabases

/usr/ORACLE/u02 System tablespace files

Syaux tablespace files

First database control file

/usr/ORACLE/u03 undo tablespace files

Second database control file

/usr/ORACLE/u04 Temporary tablespace files

Third database control file

/usr/ORACLE/u05 Tools tablespace files/usr/ORACLE/u06 First data files location

/usr/ORACLE/u07 Second data files location (preferred for LOBS)

/usr/ORACLE/u08 Index files location

/usr/ORACLE/u09 First and third redo group files location

/usr/ORACLE/u10 Second redo group files location

Flexibility is provided to let you best match your available hardwareconfiguration. Refer to Chapter 6 to see how to modify these defaultvalues and allocations.

In order to help you decide how to spread mount points over your diskssome hints are given concerning the various RAID possibilities and diskcaching mechanisms.

1.1.2.1 Disk Sharing RulesWhen merging several mount points to fit a limited number of disks youmay consider the next rules but also take into account therecommendation concerning RAID and caching use (see followingsections). If you plan to use RAID or caching on your file system, nevermerge files with incompatible constraints.

The most important rules are:

Separate data from indexes

Separate log files from data and indexes

Separate archived log files from data, log and indexes

A strictly OFA compliant disk repartition (4 mount points) is sufficient tofulfill these rules.

To improve performance, reliability and maintainability the followingadditional rules should be considered:

Spread data over several disks

Spread index over several disks

Spread log files over disks dedicated to a specific log group


15/128

15

Replication log files are separated from the data and log files

LOBs can be isolated

Control files are copied to several disks

1.1.2.2 Disk SelectionWhen you have multiple RAID and disk caching solutions you shouldcarefully decide which software mount point to place on which disk. Thisis an open topic even for Oracle consultants: OFA leads to specialize theuse you make of all disks but in some cases placing all data over a steppedand mirrored set of disks (RAID 0+1) provides very good performance butis an expensive solution.

Internal tests showed that specialized disks running under separatecontrollers usually provides better high end performance and scalabilitythan fully relying on stripped data. However, if only one poor performingdisk is introduced in the configuration (One redo group with slower I/Opotential) you could suffer a significant impact on the performance, which

quickly becomes inferior to the fully stripped and mirrored alternative.Information about RAID and disk caching use is given in Appendix A.

1.1.3 Database Naming Plan As the number of databases increases and in order to ease the replicationdeployment it is important to follow a strict database naming convention.This is also helpful if tools like Oracle Enterprise Manager Grid Controlare used to administer a whole platform. A well-defined naming planhelps to quickly identify databases.

Moreover, to enhance platform wide visibility Oracle global naming isautomatically enabled for each database when it is installed. This is of thehighest importance to understand a deployed replicated or distributedOracle environment. Global naming insures that a database link is alwaysidentified by the target global database name.

The defined naming plan insures network wide unique and easy databaseidentification. A database is identified by its SID, (pre-defined byproduct), the hostname where it is installed and the host domain.

The table below summarizes the pre-defined naming plan for the TeMIPproducts addressed. How this plan can be adapted or where the commoninformation will be stored (to reduce the number of questions duringdeployment) is detailed in Chapter 6.

Table 2 Database SID Table

TeMIP Database Predefined SID

AH archive aharchi

MAP temipmap

Synonyms syno

The global database name is composed as shown below.

Global database name = database name.‟server_host‟.‟server_domain‟.

The most immediate benefit is the simplification of deployment: you will

no longer be asked for master global names or even give free SIDs anddatabase domains. This will limit the problems of non-unique global


16/128

16

database names or heterogonous naming for various databases belongingto the same TeMIP platform. The server host and domain are stored in ashared configuration file; refer to Chapter 6.

It is recommended not to change the default naming schema in order todeploy homogeneous platforms. Interoperability issues are fully

described in the HP TeMIP Software Interoperability and MigrationGuide TeMIP V5.x (Tru64 / HP-UX PA-RISC & IPF, Sun) TeMIP 6.x(HP-UX IPF, Sun, RHEL 5.x)

The figure below shows a replicated deployment that respects the defaultnaming plan. It features a replicated TeMIP map database on two servers(host1 and host2 ) in the same domain ( net ).

Figure 1 Database Naming Plan

1.1.4 Service Naming UseOracle recommends using Service Naming instead of SID to identify thedatabase(s) clients want to connect with. This naming scheme enableshigh availability features and introduces a new level in database

identification. A physical database can provide multiple services and oneservice can be provided by multiple databases. The service identificationbecomes stronger than the system identification as one service is useful ifit relies on several systems to achieve high availability. From a clientpoint of view, service naming introduces flexibility and allows advancedbackup configuration.

One or several database services can be defined in the database init file(ORACLE_HOME/dbs/init sid .ora) by the „service_names‟ parameter.Clients will then request the defined service on connection. One importantmechanism is the Oracle service registration: at startup and on regularintervals (not settable and up to one minute) the database will register itsservice(s) by its listener(s) with additional information concerning its

current load.


17/128

17

This implies that the listener should always be started before thedatabase to be immediately informed of service availability at databasestartup. If the listener is started after the DB it will only acceptconnections after a given interval that based on the next registrationtime.

To check the service registration and the current service state you can runthe “services” or “status” command within the lsnrctl utility.

Note

Static service information is still configured in the listener.ora file to allowmanagement tool use like OEM and enable heterogeneous services orexternal procedures.

Each TeMIP product will use a pre-defined service. It is of the highestimportance to have services that cannot be confused with the databaseSID. This is mandatory to avoid dedicated server process spawning by thelistener even if the database is not available, as this would disturb thehigh availability mechanisms.

Moreover, it is important to append a domain definition to the service toavoid automatic concatenation with the database domain by Oracle, whichwould lead to a variety of services (due to the host part of the databasedomain) that are not suitable.

The table below summarizes the pre-defined services that are built byadding “srv” to the default SID and appending the server domain.

Table 3 Database Service Table

TeMIP Product Pre-defined Database service

Alarm Handling archivedatabase

aharchisrv .server_domain

TeMIP MAP database temipmapsrv .server_domain

TeMIP Synonyms Synosrv .server_domain

Note

Even if you change the default SID this will not affect the service name.

From a client point of view two databases of the same TeMIP product (forexample master + replica) will provide a unique service. Clients can thendefine preference and backup orders between these databases; refer toChapter 2.

In the example given earlier temipmap.host1.ie.net andtemipmap.host2.ie.net will provide the same temipmapsrv.ie.net service.

Note

This service definition needs to be adapted if you want a database toparticipate in an already deployed high available configuration and thisnew database resides on another domain. Refer to the example below.

The example below shows the case where a database from domain B

(domB.net) is included in a replicated environment hosted by domain A(domA.net).


18/128

18

In this case the added database‟s service_names parameter must beupdated manually. You should add the service corresponding to the highavailable configuration in its init file.

This new database will have its service name set to:

service_names = synosrv.domB.net , synosrv.domA.net

This example illustrates the free mapping between network topology anddatabase grouping by service. It is also possible to fully removesynosrv.domB.net if it makes no sense from a service point of view.

Figure 2 Service Naming

It is not recommended to fully remove the server domain notion from theservice name and use service descriptors like synosrv.world. This wouldbe too global in large environments and would also prevent automatic

client setup that is based on the host name and completes the pre-definedservice with the host domain. Refer to Chapter 6 for more information.

1.2 Client Configuration PrincipleTeMIP clients are linked with the Oracle libraries to connect to servers.Only Oracle Net configuration files need to be configured. Thetemip_setup tool automatically adds the required entries in theappropriated tnsnames.ora file.

How to manually configure advanced features related to high availabilityis explained in Chapter 2 and the client Oracle Net setup is detailed

below.


19/128

19

1.3 NetworkingThis section describes the Oracle Net configuration. Only general OracleNet characteristics are discussed. More advanced mechanisms areintroduced in Chapter 2.

1.3.1 Client Side

1.3.1.1 Oracle Net File LocationEach TeMIP module accessing an Oracle database will configure one orseveral Oracle net services in the tnsnames.ora file. TeMIP uses adedicated file in order to avoid conflicts with other existing applicationsthat would need an Oracle Net connection. This TeMIP specific file is/var/opt/temip/conf/tnsnames.ora.

The TeMIP configuration file (.temip_config) will point to that file locationand define the TNS_ADMIN variable as “/var/opt/temip/conf”.

1.3.1.2 Net Service DefinitionThe TeMIP modu le‟s setup phase will automatically carry out a basicupdate of the tnsnames.ora file and also check the TNS_ADMIN setting inthe TeMIP configuration file.

This automatic file update addresses only simple client to databaseconnections and no advanced configuration steps: defining transparentapplication failover (TAF) or connect time failover (CTF) remains manual.If a default domain is specified in the sqlnet.ora file, then it will beautomatically commented during the module setup phase.

Two connection modes are supported, by specifying an SID in the

connection description string or by specifying a SERVICE_NAME. Thefirst method will still work, as the corresponding SID will be explicitlydeclared in the target listener.ora file. This method is howeverincompatible with Oracle high availability features such as TAF or CTF.The second method is the default one and the only one supported byproducts implementing high availability in replicated environments.

It is recommended to use service naming instead of SID naming to fullybenefit from new high availability features. Some TeMIP products willalways chose the service naming while other may give you the choiceduring the setup phase. These setup phases are described in the productspecific chapters. Configuration file examples are also given in theproduct specific chapters.

1.3.2 Server Side

1.3.2.1 Oracle Net File LocationThe Oracle Net files are located in $ORACLE_HOME/network/admin.

The oratab file is stored in /etc.

The server tnsnames.ora file was previously used to define the databaselinks connect string. This string is now directly passed to the link creationstatements during snapshot deployment. This way, no more entries are tobe added in the files.


20/128

20

Remark

This has one major advantage as a manual remote tnsnames.ora update isno longer required while deploying a replication model that creates linksfrom the master to the replica (like TeMIP MAP application). This alsoeases link administration in case of a master or replica move on the

network. The target database global name will change and the links willtherefore need to be recreated, but no tnsnames.ora update is required.Moving database and related links will be easier and faster as everythingcan be done via Oracle remote connections and no rlogin is needed formanual file update.

1.3.3 Protocol ConsiderationsOracle Net connections will always be configured with the TCP protocol.In some cases, the client and server may run on the same host and theprotocol should be manually set to IPC to maximize performance.

During the TeMIP setup phase the local target database will be detectedand the following information message will be given.

INFO :The "temipmap_write" net service you are configuringrefers to a local target database (host= target host)It is recommended to switch to IPC protocol :replace "(ADDRESS = (PROTOCOL =TCP)(HOST=target host)(Port=1521))"by "(ADDRESS = (PROTOCOL = IPC)(KEY=TargetDatabaseSID))"in /var/opt/temip/conf/tnsnames.ora

To improve TCP connection throughput, some tuning is possible on thepacket size: Oracle provides flexibility by setting the Session Data Unit(SDU) size setting.

1.4 Security

1.4.1 User AuthenticationEach TeMIP product uses its own user to connect to the database. Nooperating system authentication is used. The table below lists the created

usernames within the product specific databases.

Table 4 TeMIP Database User Names

TeMIP Database Dedicated User Name

AH Archive temipaharchi

MAP temipmap

Synonyms temipsyno


21/128

21

1.4.2 User RightsNone of the above listed users will be granted „DBA‟ rights. Each user hasa limited set of roles and privileges. For a detailed user rights descriptionplease refer to the product specific chapter.

1.5 Database Backup and RecoveryTeMIP engineering does not provide a tool that encapsulates Oraclebackup solutions. Users should be familiar with the Oracle backupand recovery methodology to best anticipate and manage possiblefailures (refer to “ Oracle11g Backup and Recovery documentation ”).

1.6 Oracle 11g standard editionThe Oracle 11g standard Edition is a full featured database. It is a lowercost database option compared to Oracle 11g Enterprise.

1.6.1 RestrictionOracle 11g Standard Edition has some restrictions in term of licensingand in term of features.

In term of licensing, the Standard Edition supports a maximum of 4CPUs on a single server. The way to compute the number of CPU dependsif the processor is multi-core or not. The targeted hardware machineshould be studied to see if it fits this Oracle requirement. Please contactOracle Corporation for the pricing.

In term of features, the standard edition does not offer some of the

advanced features/options available in the Enterprise Edition.The upgrade from the Oracle Standard Edition and the Oracle EnterpriseEdition could be done at any time by only installing the EnterpriseEdition software. No migration of data needs to be done. They remainunchanged.

1.6.2 Compatibility with TeMIP databasesTeMIP 6.10 has been qualified to run with the Oracle 11g R2 standardEdition for the following TeMIP databases:

TeMIP synonym database,

TeMIP Map database, TeMIP Archiving database,


22/128

22

Chapter 2High Availability within a TeMIP

Environment

Several solutions are provided to improve data availability. Thesesolutions do not cover all the Oracle supported configurations andadvanced replication features, but are designed to assist the dataavailability in typical TeMIP configurations.

The solutions described in the next sections only focus on the availabilityimprovements that are compatible with the Database deploymentpossibilities offered by TeMIP modules. Concerning the replicationmechanism only read-only snapshots are provided and no multi-master orupdateable snapshots will be considered.

The fact that replication is implemented by read-only snapshots leads todistinguish two kinds of availability: a master and its snapshot can beconsidered as equivalent (ignoring propagation times) from a read point ofview while data write and update remain a master specific capability.

This involves a client ability to identify operations that can only beexecuted at the master site (updates) and others that can be executed atsnapshot sites (reads). To achieve that distinction, the TeMIP modulesconcerned will use two (or more) net service entries in the tnsnames.orafile. The first will address update operations and will be configured tofocus on the master site while the read entry can be configured tomaintain the service despite database crashes or maintenance phases, aslong as at least one site remains up and running.

These functional considerations lead to two types of availability:

Data Read availability

Data Write availability

2.1 Data Read AvailabilityOptimize Read availability in a snapshot read-only environment isintuitive: master and replica can be used to access the stored information.Clients should be able to use one of the servers within a replication groupif their preferred server is not available.

Snapshot replication is primarily designed in TeMIP environments toprovide better performance by insuring data proximity and spreadingglobal platform loads over several servers. It also implicitly increases dataavailability as network fault risks are reduced.

Oracle features are used to achieve server substitution in case of adatabase crash. The next section briefly introduces these mechanisms in


23/128

23

order to better understand the benefit they can provide and the ways theyare used.

2.1.1 Oracle ConceptsThis section introduces the main Oracle native solutions that are involved

in a TeMIP High Available configuration. The general approach is to usethese native features instead of applicative solutions whenever possible.This is mandatory to take full advantage of Oracle‟s improvements. It alsohelps the DBAs in understanding their configuration behavior, as theexpected failover strategy is not modified by applicative measures.Moreover, if an application is responsible for its own failover strategy itsconfiguration needs to be updated when the Oracle platform evolves(server addition, removal and so on), whereas Oracle native solutions areable to integrate platform evolutions more easily.

Understanding the features described below is a pre-requisite todeploying an advanced Oracle configuration involving replication with ahigh availability configuration. It also helps to identify the backup andfailover strategy of a TeMIP client relying on several databases to achieveoptimal performance and improve availability.

Note

Setting up Oracle‟s high availability mechanisms is a manual task thatneeds a good knowledge of the deployed platform and the network used.

For a complete description please refer to the related Oracledocumentation and Metalink. The sections below only focus on the usethat TeMIP makes of these features.

2.1.1.1 Connect-Time Failover (CTF)

Description

This feature is a client side failover mechanism that only addressesdatabase availability issues at connection request time.

The principle is to declare a list of ordered databases that should be triedfor connection until one connection succeeds or until all databases in thelist have been unsuccessfully tried. In reality connect-time failover doesnot directly check database availability but relies on listeners, which isnot equivalent. The automatic service registration section highlights thisdistinction.

Several variants of this feature are possible, such as re-trying connectionsat repeated intervals until timeout or success and balance the load uponthe addressed listeners. Refer to the Oracle documentation for a completedescription.

Note

Once CTF has routed connection requests to a secondary host theconnections are established and will remain attached to that host. Whenthe preferred host comes up again, the re-routed connections are nothanded back to the preferred database.

Configuring tnsnames.ora for CTF Support

The Connect-Time failover configuration is located in the TeMIP clientspecific tnsnames.ora file. The net service descriptors automatically


24/128

24

created by the various MM‟s setup phases are all pre -formatted to easethe manual failover setup : They use the ADDRESS_LIST tag even ifCTF is turned OFF and even if only one listening address is specified.

They look like:

net_service_name=(DESCRIPTION =

(ADDRESS_LIST =(FAILOVER = OFF)(ADDRESS = (PROTOCOL = TCP)(HOST=host1)(Port=port1))

)(CONNECT_DATA =

(SERVICE_NAME = database_service))

)

To enable connect-time failover you need to substitute (FAILOVER =OFF) with (FAILOVER = ON) and add one or several copies of the

ADDRESS description line. The specified addresses correspond to theordered list of listeners you would like to try.

With a three-database configuration (one master and two replicas), theprevious example could become:

net_service_name=(DESCRIPTION =

(ADDRESS_LIST =(FAILOVER = ON)(ADDRESS = (PROTOCOL = TCP)(HOST= host1 )(Port= port1 ))(ADDRESS = (PROTOCOL = TCP)(HOST= host2 )(Port= port2 ))(ADDRESS = (PROTOCOL = TCP)(HOST= host3 )(Port= port3 ))

)(CONNECT_DATA =

(SERVICE_NAME = database_service ))

)

Note

The example above shows that all the databases involved need to providethe same „service‟ (refer to service naming for more details).

Your changes to tnsnames.ora will take effect as soon as you have savedthe file and issue new connection requests.

2.1.1.2 Transparent Application Failover (TAF)

Description

While connect-time failover only addresses database availability issues atconnection time, transparent application failover is dedicated to alreadyconnected sessions. TAF handles session re-routing to backup resources incase of database failure. This re-routing is configured at the client side

and can as such be client specific. Its description is part of the connectstring defined in the tnsnames.ora file.


25/128

25

Note

Transparent Application failover is only available with the OracleEnterprise edition of the database.

TAF provides more possibilities than the one described below, all optionsand configurations will not be detailed here, to focus on the onessupported in the TeMIP environment.

The used TAF options are:

TYPE: is set to „session‟. This mode simply re -establishes lostconnections to the defined backup for the user. It does not try torecover selects.

METHOD: is set to „basic‟. This mode establishes connections towardsthe backup only at failover time. This leads to a small delay(connection time) during failover but avoids to backups systematicallysupporting all potential re-routed connections.

BACKUP: this parameter specifies the net service name that should beused as a backup to re-establish the broken sessions.

Two other options are of interest: RETRIES and DELAY, which haveinterdependent defaults. These options can help to implement anautomatic retry of your connection requests (even retries of the currentlyused net service name).

Note

Once TAF has handed off sessions to a secondary host they remainattached to that host. When the originating host comes up again, the re-opened sessions are not handed back to the preferred database.

Configuring tnsnames.ora for TAF Support

To configure TAF you need to manually update the CONNECT_DATAsection of the connection descriptors. You must add theFAILOVER_MODE sub-parameter with its own sub-parameters.

net_service_name =(DESCRIPTION =

(ADDRESS_LIST =(FAILOVER = OFF)(ADDRESS = (PROTOCOL = TCP)(HOST= host1 )(Port= port1 ))

)(CONNECT_DATA =

(SERVICE_NAME = database_service )(FAILOVER_MODE =

(BACKUP = your backup net service name )(TYPE = session)(METHOD = basic)

) )

)


26/128

26

Note

You can query FAILOVER_TYPE, FAILOVER_METHOD andFAILED_OVER columns in the V$SESSION view to verify that TAF iscorrectly configured.

Your changes to tnsnames.ora will take effect as soon as you have savedthe file and issue new connection requests.

2.1.2 TAF and CTF Use in a TeMIP EnvironmentMMs have a service level view of a replicated environment that involves aunique master and one or several read-only snapshots. TAF and CTFimplement that service high availability by relying on multiple databaseinstances.

Using TAF and CTF features provides backup solutions to the client andeliminates most of the single point failure possibilities. As long as clientscan reach at least one node involved in the replicated system they are ableto read their data.

Associating TAF and CTF is mandatory to provide backup solutions atconnection and during runtime. The next figure shows how bothtechniques are associated to achieve connection and runtime availability.

Note

As introduced in the CTF and TAF descriptions, no way is provided toswitch sessions back to the preferred host once they have beenautomatically re-directed. To come back to the preferred database, themodules have to issue new connection requests to create new sessions.

Figure 3 CTF and TAF mixing

When designing the backup strategy you should observe this set of rules:

1. Always use the nearest snapshot as the preferred server.

Net Service

configuration

serv er 1

serv er 2

serv er 3

TAF

Connect-timefailover

H1, H2, H3

H2, H3, H1

H3, H1, H2

Client 1

Client 2

Client 3

Each cli ent has its ownspecific configuration

(tnsnames.ora)

Net Service

configuration

serv er 1

serv er 2

serv er 3

TAF

Connect-timefailover

H1, H2, H3

H2, H3, H1

H3, H1, H2

Client 1

Client 2

Client 3

Each cli ent has its ownspecific configuration

(tnsnames.ora)


27/128

27

2. Prefer a snapshot as backup to the master to avoid a connectionconcentration towards the master that could degrade writeperformance.

3. Consider network bandwidths when you have apparently equivalentpossibilities.

These few basic rules cannot be considered as sufficient, they simply helpyou in setting up your initial failover configuration over your replicatedenvironment. If during operation you notice important load gaps betweenservers you should reconsider your client connection defaults and failoverstrategies to best spread the work over your servers and the data trafficover your network.

Modifying your configuration is a pure Oracle administrative task and canbe done smoothly and incrementally by editing the client‟s tnsnames.orafiles. These files can be edited during runtime without disruptingconnected clients. The modifications will take effect when the moduleopens new connections (usually at startup time).

NoteIn some cases you might configure client load balancing to spread givenclient connections over several servers that seem to have comparablepotentials.

2.2 Data Write AvailabilityDue to the supported replication mechanisms (read only snapshots) datawrite availability is directly dependant from the master database‟savailability. Increasing availability consists as such in optimizing the

server‟s availability. In that area TAF or CTF are of no help (excludingautomatic retry mechanisms on failure).

The write capacity availability will be equivalent to the master siteavailability.


28/128

28

Chapter 3

Synonyms Service

This chapter presents the Synonyms service regarding the OracleDatabase implementation. The Synonyms Service enables you to definean alternative name (synonym) for the entities that exist in a TeMIPsystem and to display this name in any Presentation Module (PM) orapplication capable of displaying TeMIP entities.

This feature provides a platform wide instance-naming alternative,including user-friendly names, support of alternate identifiers andnaming issues for SNMP and OSI.

Synonyms service allows a TeMIP application to associate a synonym of agiven type with an entity specification. An alternate naming system could,for example, involve the use of shorter names, therefore avoiding"crowding" of the display, especially in large networks that have manyentities displayed.

This chapter also suggests recommendations to help solution architectsplan a TeMIP and Oracle configuration that supports TeMIP synonyms.

The topics covered in this chapter include:

Section 3.1 An overview of the Synonyms Service architecture.

Section 3.2 The Oracle Synonyms Database Layout with a descriptionof the Oracle tables, the indexes, the constraints, some indicationsrelated to the Database sizing.

Section 3.3 The High Availability.

Section 3.4 Planning the Database Deployment.

Section 3.5 Installation and Configuration.

Section 3.6 The Caching Mechanism.

Section 3.7 Recovery Mechanism`

3.1 Overview/ArchitectureThe Synonyms Service is based on Client/Server architecture. Eachapplication using the Synonyms service will use the client stubs. TheServer side is a relational database (Oracle on UNIX) that does notinclude any TeMIP dependencies.

The Synonyms Service has the capability to address several OracleConnections on the same director in order to improve performance. Theconstraint of a unique Synonyms database for all MMs of a TeMIPdirector has been removed. Six different “fixed” Oracle Network ServiceNames on a TeMIP director are offered for managing all the Synonyms.


29/128

29

This new layout allows any MM on a TeMIP director to support theconnections to different Oracle servers for the different services and so toimprove performance by avoiding serialization of the calls.

The Synonyms Service now relies on powerful Oracle features, inparticular the Failover, including the Transparent Application Failover

(TAF) and the Connect-Time Failover (CTF).Their implementation underlines the fact that the Oracle configurationfile is different according to the service dedicated to read operations(multiple backups) or to write operations. It is the reason why Read andWrite operations have to be separated and two Oracle Network ServiceNames are suggested for a specified Synonym type.

The twelve different “fixed” Oracle “Network” Service Names on a TeMIPdirector defined for managing all the Synonyms are:

temip_syno_ascii_write and temip_syno_ascii_read respectivelyfor writing and reading ASCII Synonyms.

temip_syno_ip_write and temip_syno_ip_read respectively forwriting and reading IP Synonyms.

temip_syno_osi_write and temip_syno_osi_read respectively forwriting and reading OSI Synonyms.

temip_syno_algo_write and temip_syno_algo_read respectivelyfor writing and reading Algorithmic Synonyms.

temip_syno_class_write and temip_syno_class_readrespectively for writing and reading Class Synonyms.

temip_syno_inst_name_write and temip_syno_inst_name_readrespectively for writing and reading Instance Name Synonyms.

The following figure shows an MM (such as the SNMP_AM) of a directorusing a database for handling IP Synonyms and another for the ASCIISynonyms:

Figure 4 Database Connections Schema Overview

A MM could potentially access up to six different databases (via thetwelve different “fixed” Network Ser vice Names). A MM could for

TTeeMM IIPP DDiir r eeccttoor r

AAllll MMMM AA p p p p lliiccaattiioonn

((TTyy p p iiccaallllyy PPMM ))

N N aamm ee SSeer r vveer r FFMM

Class SynoAlgo SynoInstance Name Syno

ASCII Syno IP Syno OSI Syno

SS N N MM PP _ _ AAMM mm oodduullee

OOSSII _ _ AAMM mm oodduullee


30/128

30

instance read ASCII Synonyms on a “local” replica server and writethem on the shared master server.

All MMs on the same TeMIP director access the same database for agiven Synonym type.

Note

One or more Oracle databases are used to support the TeMIP synonymsfunction. In the rest of this chapter the Oracle databases allocated to thistask will be referred to as the "TeMIP synonyms database".

3.2 Database Layout and ImplementationThis part gives all Oracle information related to the Synonyms Service:

It puts forward the Synonyms Database Layout.

It lists the different Oracle tables used, the different constraints andindexes for each type of synonym.

It gives information about Database sizing.

It deals with Synonyms Database Implementation.

3.2.1 Synonyms Database LayoutThe TeMIP synonyms feature (including all ASCII, IP and OSI aspects)relies on the availability of a TeMIP synonyms database. The layout of theTeMIP synonyms database comprises six fully independent table sets (infact, only Class and Instance Name synonyms use more than one table,see below):

The ASCII synonyms table that supports all aspects of ASCIISynonyms (including naming planes, that is, tag values). ASCIISynonyms are used by a number of existing TeMIP applications and an

Application Programming Interface (API) allows customizedManagement Modules or applications to use the feature.

The IP synonyms table that supports IP Synonyms used by the TeMIPInternet SNMP Toolkit (IST).

The OSI synonyms table that supports OSI Synonyms (also known asOSI Distinguished Names or OSIDN). OSI Synonyms can be used by

the OSI Management Toolkit configured either as an OSI AccessModule or as an OSI Agent.

The Algorithmic synonyms table that supports all aspects of Algorithmic Synonyms. Algorithmic Synonyms are used by a numberof existing TeMIP applications and an Application ProgrammingInterface (API) allows customized Management Modules orapplications to use the feature.

The Class synonyms Class and Instance tables that support all aspectsof Class Synonyms. Class Synonyms are used by a number of existingTeMIP applications and an Application Programming Interface (API)allows customized Management Modules or applications to use thefeature.


31/128

31

The Instance Name synonyms Class and Instance tables that supportsall aspects of Instance Name Synonyms. Instance Name Synonyms areused by a number of existing TeMIP applications and an ApplicationProgramming Interface (API) allows customized Management Modulesor applications to use the feature.

The TeMIP synonyms database is fully independent from other databasesused in the TeMIP environment, for example, for Alarm Archiving. Thedatabase layout is shown in the following figure.

Figure 5 Oracle Databases in the TeMIP Environment

3.2.2 Synonyms Oracle Table DescriptionThe following information describes all ASCII, IP and OSIDN Synonymstables.

Distributed Oracle Environment


32/128

32

3.2.2.1 ASCII Synonym Database Table

Table 5 ASCII Synonyms Database

SQL> desc temip_syno_ascii;Column Name Null? Type------------------------------ -------- ----ENTITY_SPEC NOT NULL VARCHAR2(2048)CLASS_STRING NOT NULL VARCHAR2(255)ASCII_STRING NOT NULL VARCHAR2(255)TAG_STRING NOT NULL VARCHAR2(16)

3.2.2.2 IP Synonym Database Table

Table 6 IP Synonyms Database

SQL> desc temip_syno_ip;Column Name Null? Type------------------------------ -------- ----

ENTITY_SPEC NOT NULL VARCHAR2(2048)IPADDR0 NUMBER(3)IPADDR1 NUMBER(3)IPADDR2 NUMBER(3)IPADDR3 NUMBER(3)PRIMARYFLAG NUMBER(1)UDPPORT NUMBER(5)CONTEXT_NAME VARCHAR2(255)CONTEXT_ENGINE VARCHAR2(255)OWNER VARCHAR2(255)TRAPCOMM VARCHAR2(255)MUSTBEAUTHENTICATED NUMBER(1)

3.2.2.3 OSIDN Synonym Database Table

Table 7 OSIDN Synonyms Database

SQL> desc temip_syno_osidn;Column Name Null? Type------------------------------ -------- ----OSIDN NOT NULL VARCHAR2(1024)ENTITY_SPEC NOT NULL VARCHAR2(2048)PATTERNFLAG NOT NULL NUMBER(1)

3.2.2.4 Algorithmic Synonym Database Table

Table 8 Algorithmic Synonyms Database

SQL> desc temip_syno_algo;Column Name Null? Type------------------------------ -------- ----REWRITE_START NOT NULL VARCHAR2(255)REWRITE_END NOT NULL VARCHAR2(255)PARSING_REGEXP NOT NULL VARCHAR2(1024)PARSING_STRING NOT NULL VARCHAR2(1024)PRINTING_REGEXP NOT NULL VARCHAR2(1024)PRINTING_STRING NOT NULL VARCHAR2(1024)


33/128

33

3.2.2.5 Class Synonym Database Tables

Table 9 Class Synonyms Class Table Database

SQL> desc temip_syno_class;Column Name Null? Type------------------------------ -------- ----VERSION_ACTUAL_CLASS NOT NULL VARCHAR2(255)VERSION_VIRTUAL_CLASS NOT NULL VARCHAR2(255)

Table 10 Class Synonyms Instance Table Database

SQL> desc temip_syno_entity;Column Name Null? Type------------------------------ -------- ----VERSION_VIRTUAL_ENTITY NOT NULL VARCHAR2(2048)VERSION_ACTUAL_CLASS NOT NULL VARCHAR2(255)

3.2.2.6 Instance Name Synonym Database Tables

Table 11 Instance Name Synonyms Class Table Database

SQL> desc temip_syno_inst_name_class;Column Name Null? Type------------------------------ -------- ----CLASS NOT NULL VARCHAR2(255)

Table 12 Instance Name Synonyms Instance Table Database

SQL> desc temip_syno_inst_name_inst;Column Name Null? Type------------------------------ -------- ----PARENT_ENTITY NOT NULL VARCHAR2(2048)CLASS_ID NOT NULL NUMBER(20)REAL_INST_NAME NOT NULL VARCHAR2(2048)INST_NAME_SYNO NOT NULL VARCHAR2(2048)CLASS_NAME NOT NULL VARCHAR2(255)

3.2.3 Synonyms Database Constraints and IndexesIn order to guarantee coherence and to improve performance, someConstraints and Indexes are created on these tables. All constraints andIndexes are stored in dedicated tablespaces according to the Synonymtype.

3.2.3.1 ASCII Synonym Constraints and IndexesHere is the list of the constraints defined for the ASCII Synonyms:

Table 13 ASCII Synonyms Constraints

Constraint Name Value

Multi_ascii_ct UNIQUE for (class_string, ascii_string and tag_string)

Multi_ident_ct UNIQUE for (entity_spec, tag_string)


34/128

34

Nn_ascii Ascii_string NOT NULL

Nn_ascii_fem Entity_spec NOT NULL

Nn_class Class_string NOT NULL

Nn_tag Tag_string NOT NULL

The following table lists different indexes defined for the ASCIISynonyms:

Table 14 ASCII Synonyms Indexes

IndexName Value

Ascii_index Index on „ascii_string‟ attribute

Ascii_index_2 Index on „entity_spec‟ attribute

Ascii_index_3 Index on „tag_string‟ attribute

Multi_ascii_ct Index on (class_string, ascii_string and tag_string)Multi_ident_ct Index on (entity_spec, tag_string)

3.2.3.2 IP Synonym Constraints and IndexesHere is the list of the constraints defined for the IP Synonyms:

Table 15 IP Synonyms Constraints


multi_ip_ct_1 UNIQUE for (entity_spec,ipaddr0,ipaddr1,ipaddr2,ipaddr3)

multi_ ip_ct_2 UNIQUE for (ipaddr0, ipaddr1, ipaddr2, ipaddr3, udpport,context_name, context_engine)

nn_ioaddfen Entity_spec NOT NULL

Here is the list of the indexes defined for the IP Synonyms:

Table 16 IP Synonyms Indexes

IndexName Value

multi_ip_ct_1 Index for (entity_spec,ipaddr0,ipaddr1,ipaddr2,ipaddr3)

multi_ip_ct_2 Index for (ipaddr0, ipaddr1, ipaddr2, ipaddr3, udpport,context_name, context_engine)

3.2.3.3 OSIDN Synonym Constraints and IndexesHere is the list of the constraints defined for the OSIDN Synonyms:

Table 17 OSIDN Synonyms Constraints


Pk_osi_dn Primary key for pattern_flag

Nn_osidn Entity_spec NOT NULL

Nn_pattern Patternflag NOT NULL


35/128

35

Here is the list of the indexes defined for the OSIDN Synonyms:

Table 18 OSIDN Synonyms Indexes

IndexName Value

temip_syno_patternflag_index Index on „patternflag‟ attribute Pk_osidn Index on patternflag

3.2.3.4 Algorithmic Synonym Constraints and IndexesThe following table lists different constraints defined for the AlgoSynonyms:

Table 19 Algo Synonyms Constraints


pk_algo_rewrite_end PRIMARY KEY for Rewrite_end

nn_algo_start Rewrite_start NOT NULL

nn_algo_pars_regexp Parsing_regexp NOT NULL

nn_algo_pars_string Parsing_string NOT NULL

nn_algo_print_regexp Printing_regexp NOT NULL

nn_algo_print_string Printing_string NOT NULL

The following table lists different indexes defined for the Algo Synonyms:

Table 20 Algo Synonyms Indexes

IndexName Value

pk_algo_rewrite_end Index on „Rewrite_end‟ attribute

3.2.3.5 Class Synonym Constraints and IndexesThe following table lists different constraints defined for the ClassSynonyms:

Table 21 Class Synonyms Constraints


pk_syno_actual PRIMARY KEY for (version_actual_class)

pk_syno_virtual PRIMARY KEY for (version_virtual_entity)

nn_ syno_virtual version_virtual_class NOT NULL

nn_syno_actual version_actual_class NOT NULL

The following table lists different indexes defined for the Class Synonyms:

Table 22 Class Synonyms Indexes

IndexName Value


36/128

36

pk_syno_actual Index on „version_actual_class‟ attribute

pk_syno_virtual Index on „version_virtual_entity ` attribute

3.2.3.6 Instance Name Synonym Constraints and Indexes

The following table lists different constraints defined for the instancename class table

Table 23 Instance Name Synonyms Class Constraints


nn_inst_class_id Class_id NOT NULL

nn_inst_class_name Class_name NOT NULL

nn_inst_name_syno inst_name_syno NOT NULL

nn_parent_entity parent_entity NOT NULL

nn_real_inst_name real_inst_name NOT NULL

Note

Oracle doesn‟t allow using Unique or Primary Key constraints based onan index greater than 2000 characters so these constraints ontemip_syno_inst_name_inst will be checked by the software.

The following table lists different constraints defined for the instancename instance table:

Table 24 Instance Name Synonyms Table Constraints


Pk_syno_class PRIMARY KEY for class attribute

The following table lists different indexes defined for the instance nameinstance table:

Table 25 Instance Name Synonyms Table Indexes

IndexName Value

Pk_syno_class Index on class attribute

3.2.4 Synonyms Database SizingThe Available pre-defined sizes of the Synonym Database are:

Table 26 Synonym Database Predefined Database Size

Pre-definedDatabase Size

Synomym type Spacedefined forData

Space defined forindexes

SMALL

ASCII 50 Mo 50 Mo

IP 50 Mo 50 MoOSI 50 Mo 50 Mo


37/128

37

Pre-definedDatabase Size

Synomym type Spacedefined forData

Space defined forindexes

ALGO 50 Mo 50 Mo

CLASS 50 Mo 50 MoINST_NAME 50 Mo 50 Mo

MEDIUM

ASCII 100 Mo 100 Mo

IP 100 Mo 100 Mo

OSI 100 Mo 100 Mo

ALGO 100 Mo 100 Mo

CLASS 100 Mo 100 Mo

INST_NAME 100 Mo 100 Mo

LARGE

ASCII 300 Mo 350 MoIP 300 Mo 300 Mo

OSI 300 Mo 300 Mo

ALGO 300 Mo 300 Mo

CLASS 300 Mo 300 Mo

INST_NAME 300 Mo 300 Mo

Small databases are designed to store up to around 50 000 synonyms.

Medium databases should target up to around 200 000 synonyms.

Large databases can store around 1 000 000 synonyms.

These are only approximations as synonym size can widely vary.

In terms of behavior, the Synonyms Service:

Has neither long running transactions, nor long concurrenttransactions.

Mainly uses the Name Server FM for Synonym population and usesthe library for getting information to update the internal Cache.

3.2.5 Synonym Trigger ImplementationTriggers are automatically created on the Master server in order topropagate the modifications that occur on the database.

3.2.5.1 Trigger DefinitionThere exists one trigger for each Synonym type. When either creation ordeletion occurs on a database, they generate an Oracle alert with a titleand a message as follows:

The ASCII trigger named „trigger_ascii‟ has a title „ASCII‟ and insertsa character „A‟ at the beginning of the internal message.

The IP trigger named „trigger_ip‟ inserts has a title „IP‟ and inserts acharacter „I‟ at the beginning of the internal message.

The OSIDN trigger named „trigger_osi‟ has a title „OSI‟ and inserts acharacter „O‟ at the beginning of the internal message.


38/128


39/128

39

Whatever the Oracle alert receives, the Synonym Service handles it in thesame way, removing the entity processed from the cache.

If this comes from a deletion of a synonym, the cache does not containit anymore and the last reading operation will access the database.

Note

The result of this request depends on the propagation time of the Replica

database to update its snapshot regarding the Master server. If theoperation occurs whereas the Replica does not perform it, the synonymwill be found (old one). In the other case, the Replica snapshot has beenupdated previously and the operation does not find the synonym.

If this comes from a creation of a synonym, the cache does not containit anymore and the last reading operation will access the database. Thesame remark applies as in the previous note.

3.2.6 Synonyms Physical LayoutThe following table lists the different tablespaces created in the database:

Table 27 Synonyms Physical Layout

Tablespace Name Corresponding File Additional Information

SYNO_ASCII ${ASCII_DATA_LOC}/ascii01.dbf ASCII data storage purpose

SYNO_ASCII_IDX ${ASCII_IDX_LOC}/ascii_idx01.dbf ASCII index storage purpose

SYNO_ASCII_CONST ${ASCII_CONSTRAINT_LOC}/ascii _const01.dbf

ASCII constraints storagepurpose

SYNO_IP ${IP_DATA_LOC}/ip01.dbf IP data storage purpose

SYNO_IP_CONST ${IP_CONSTRAINT_LOC}/ip_constx01.dbf

IP constraints storagepurpose

SYNO_OSI ${OSI_DATA_LOC}/osi01.dbf OSI data storage purpose

SYNO_OSI_IDX ${OSI_IDX_LOC}/osi_idx01.dbf OSI index storage purpose

SNAPSHOT_LOG_SYNO

${DB_DATA_LOC}/snaplog01.dbf Snapshot refreshes storagepurpose. Only created onMaster server.

SYNO_ALGO ${ALGO_DATA_LOC}/algo01.dbf Algo. data storage purpose

SYNO_ALGO_IDX ${ALGO_IDX_LOC}/algo_idx01.dbf Algo. index storage purpose

SYNO_CLASS ${CLASS_DATA_LOC}/class01.dbf Class data storage purpose

SYNO_CLASS_IDX ${CLASS_IDX_LOC}/class_idx01.dbf'

Class index storage purpose

Oracle alertsemitted

IP

IST1 IST2 OSI

OSI1

ASCII

FCL_PM

Cache

Requestschannel

Alert receptionchannel

IP

IST1 IST2 OSI

OSI1

ASCII

Replica

Master WAN

Snapshot Read-Only (FastRefresh)


40/128

40

Tablespace Name Corresponding File Additional Information

SYNO_ENTY ${CLASS_DATA_LOC}/class_entity01.dbf

Class/Entity data storagepurpose

SYNO_ENTY_IDX ${CLASS_IDX_LOC}/class_entity__i

dx01.dbf

Class/Entity index storage

purposeSYNO_INST_CLASS ${INST_DATA_LOC}/inst_class01.d

bf'Instance class data storagepurpose

SYNO_INST_ENTY '${INST_DATA_LOC}/inst_entity01.dbf'

Instance entity data storagepurpose

SYNO_INST_CLASS_IDX

'${INST_IDX_LOC}/inst_class_idx01.dbf'

Instance class index storagepurpose

All variables ASCII_DATA_LOC, ASCII_IDX_LOC … are defined in thefile /var/opt/temip_oracle/syno/conf/temip_database_product_configuration.cfg and can be updated.

3.2.7 ReplicaThis section provides information related to the mechanism of Replicationused for the Synonyms Service:

A snapshot Read-only (Fast refresh) is used. The updates are stored inthe SNAPSHOT_LOG_SYNO tablespace.

There is one snapshot per Synonym type.

All snapshots use the same database link.

The refresh is scheduled (20 seconds). It can be set with the variable$SNAPSHOT_REFRESH_INTERVAL contained in the/var/opt/temip_oracle/syno/conf/temip_database_product_configuration.cfg (before the database creation).

3.2.8 TeMIP Synonyms Database ImplementationThe TeMIP synonyms database can be centralized or distributed over anumber of Oracle Database Sites (that is, on Oracle Servers hosting partor the entire TeMIP synonyms database). The Oracle replication featurecan be used to achieve TeMIP synonyms database access to the differenttables as necessary.

A given Oracle Server either stores synonyms locally or provides access toa maximum of one Table Instance of each type (ASCII, IP, OSI,

Algorithmic, Class and Instance Name).

Each Table Instance:

Can contain all the data belonging to the whole TeMIP distributedconfiguration or part of this data. As an example of the latter case, twoIP Synonym Table Instances may exist in the distributed databaseenvironment, one containing data provided by IST numbers 1 to n, theother one containing data provided by IST from number n+1.

Note

Each database server hosts a maximum of one table for each type ofsynonym (ASCII, IP, OSI, Algorithmic, Class, and Instance Name).


41/128

41

Can be from the types shown in the next table with associated accessrights and properties.

Table 28 Oracle Table Instances

Type Access Right Properties

Master Read-Write

Replica Read Single Replica 1: not directly updated. Possible delayfor updating the replica from the master

Although not described here, the use of updatable replicas can beconsidered by advanced Oracle users.

Note that Oracle Servers supporting the TeMIP Synonyms database mayor may not be TeMIP Directors. For example, Oracle Servers can be pre-existing enterprise database servers.

3.3 High AvailabilityThe Synonyms Service now relies on powerful Oracle features such as theTransparent Application Failover (TAF) and the Connect-Time Failover(CTF).

So now when a problem occurs during the execution of a statement orwhen trying to connect to a database, a selection of internal tools andfeatures are used to determinate when the service will become „in‟ orwhether it is unavailable. It runs a test of connections several times (nbretries) during a specified period (interval time) until it either succeeds orit reaches the deadline.

These parameters can be set using environment variables in order toperform retries according to the configuration of the customer (severalbackups). New variables corresponding to all potential Synonym Servicecan be set in the .temip_config.dat file.

This enables to any Synonyms Service to be scheduled differently ifneeded. Two general variables are defined(TEMIP_SYNO_FAILOVER_NB_RETRIES,TEMIP_SYNO_FAILOVER_INTERVAL_TIME) and can be used if nospecific variables are.

The replication and the failover have to be planned and implemented byOracle Administrators having a global view of the TeMIP platform. Onceall the different services are defined, some Oracle configuration files(tnsnames.ora) can be written and installed on the appropriated directors.

3.4 Planning the Database DeploymentThis part explains how to plan your TeMIP synonyms databaseconfiguration.

1 The Oracle advanced replication feature can potentially be used in the context of TeMIPsynonyms. Advanced replication provides real-time replica updates, but requires morenetwork bandwidth than single replication. In addition, advanced replication requires

experienced Oracle administrators to carry out the configuration and administrationtasks. Note that TeMIP does not provide any material aids (scripts, tools) for the supportof Oracle advanced replication.


42/128

42

The first section re-states the different requirements for each type ofsynonym.

The following sections deal with the Planning of the DatabaseDeployment: they introduce the different criteria to take into accountand describe the planning process to adopt.

3.4.1 Constraints and Requirements for using TeMIPSynonyms

The constraints and requirements are described in the following sectionsrelevant to the Synonym type. Additional constraints may be imposed byuser-defined Management Modules that use TeMIP synonyms.

3.4.1.1 ASCII Synonym Constraints and Requirements ASCII synonyms are used for instance naming flexibility (support ofseveral na ming “planes”), user -friendliness (“short -hand” form) especiallyat the PM level.

Access to the ASCII Synonyms Table is required by all applications using ASCII Synonyms (including the IST). Most users require only read accessto the ASCII Synonyms Table; however, selected users (including the IST)require both read and write access.

Although it may be possible to split the ASCII Synonyms data overdifferent Oracle sites, this could introduce constraints that couldpotentially impact all synonym user applications. Such an ASCIISynonyms Table split would not be recommended as the preferredsolution and would require advanced planning that is out of the scope ofthis document. Therefore, it is recommended that you use Oraclereplicatio

TeMIP Oracle Use Reference Guide

Documents