IBM Tivoli Netcool Performance Manager 1.4.1
Wireless Component
Document Revision R2E1
Deployment Guide
Note
Contents
About this document . . . v
Audience . . . v
Required skills and knowledge . . . v
References . . . v
The Tivoli Netcool Performance Manager - Wireless component user publications . . . v
Service Management Connect . . . vi
Tivoli Netcool Performance Manager technical training . . . vi
Support information . . . vi
Conventions used in this publication . . . vii
Typeface conventions . . . vii
Chapter 1. Introduction . . . 1
Training . . . 2Chapter 2. Architecture . . . 3
Overview . . . 3 Principal components . . . 3 Optional components . . . 4Sample system architecture . . . 4
Minimum configuration . . . 5
Chapter 3. Requirements . . . 7
Software prerequisites . . . 7
Kernel parameters . . . 8
Solaris kernel settings . . . 8
Linux kernel settings . . . 8
SWAP . . . 9
SWAP for Solaris . . . 9
SWAP for RHEL . . . 9
Solaris zones . . . 9
Prerequisite for hardware purchase and deployment 10
Chapter 4. File types and disk layout
11
Terminology definitions . . . 11RAID levels overview . . . 12
Database RAID and disk types . . . 12
Database data files and temp files . . . 12
Database online redo log files . . . 13
Database archive log files. . . 14
Hardware . . . 14
Configuration . . . 14
Database backup files . . . 14
Hardware . . . 14 Configuration . . . 14 Log files . . . 15 Hardware . . . 15 Configuration . . . 15 Report results . . . 15 Configuration . . . 15 Hardware . . . 15
Loader files (LIF files) . . . 16
Gateway files (raw files) . . . 17
Disk layout on the database server . . . 17
Chapter 5. System configuration. . . . 19
File system and SAN configuration . . . 19
Network configuration . . . 19
Database configuration . . . 19
Database memory configuration . . . 20
Application server configuration . . . 22
Loader configuration . . . 22
Gateway configuration . . . 23
Configuration of properties files . . . 24
Configuration of environment variables . . . . 24
Configuration of spool directories . . . 24
Jazz for Service Management and Tivoli Common Reporting . . . 25
Modeling . . . 25
IBM Tivoli Monitoring. . . 25
Chapter 6. Backup strategy . . . 27
Database backups . . . 27
Database backup storage . . . 27
Database backup procedures. . . 27
Prerequisites . . . 28
Database backup activities . . . 28
File system backup . . . 28
Cold standby . . . 29
Chapter 7. Database related
information . . . 31
Database OS partitions sizing . . . 31
Database extents sizing . . . 32
Setting the database block size . . . 34
Updating customer database template . . . 34
Manually setting memory parameters . . . . 35
Manually setting tablespace . . . 36
Notices
. . . 39
Terms and conditions for product documentation. . 41
Trademarks . . . 42
Glossary . . . 43
About this document
This information provides guidelines to be used when planning a deployment of an IBM Tivoli Netcool Performance Manager - Wireless Component system. This information must be used in conjunction with a customer specific sizing report and the Installation Guide.
This information does not describe Tivoli Netcool Performance Manager - Wireline Component deployments, or the IBM Tivoli Common Reporting enablement installation.
Audience
The audience for this information is professional and deployment services,
experienced system administrators and other professionals who are responsible for sizing, deploying and installing Tivoli Netcool Performance Manager.
Required skills and knowledge
Ensure that you are familiar with the following:
v Tivoli Netcool Performance Manager 1.4 or later Technology Packs. v IBM®System x hardware.
v Sun Microsystems Solaris, IBM AIX®, and Red Hat Enterprise Linux operating system.
v Oracle databases, tables and tablespaces.
v Linux and UNIX basics and system administration.
Familiarity with the relevant network and OSS systems.
References
Following are the references:
1. Oracle Database Backup and Recovery Reference, 11g Release 2 (11.2): http://www.oracle.com/corporate/pricing/sig.html
The Tivoli Netcool Performance Manager - Wireless component user
publications
Tivoli Netcool Performance Manager - Wireless component consists of the following publications:
Table 1. Tivoli Netcool Performance Manager - Wireless component user documentation
Document Description
Release Summary for Tivoli Netcool Performance Manager
Additional release-specific information not in the guides.
Installing Tivoli Netcool Performance Manager -Wireless Component
Instructions for installing and configuring the Tivoli Netcool Performance Manager software.
Upgrading Tivoli Netcool Performance Manager -Wireless Component
Instructions for upgrading Tivoli Netcool Performance Manager software.
Table 1. Tivoli Netcool Performance Manager - Wireless component user documentation (continued)
Document Description
Administering Tivoli Netcool Performance Manager -Wireless Component
Instructions and general information about how to maintain and support Tivoli Netcool Performance Manager
Using Tivoli Netcool Performance Manager - Wireless Component
Conceptual information and procedures for using Tivoli Netcool Performance Manager software for performance, trending analysis and performance alarms.
Installing and Using Tivoli Netcool Performance Manager - Application Studio - Wireless Component
Provides instructions for installation and usage of the Tivoli Netcool Performance Manager -Application Studio.
Tivoli Monitoring Integration - Wireless Component Provides instructions for integrating IBM Tivoli Monitoring with Tivoli Netcool Performance Manager.
Tivoli Netcool/OMNIbus Web GUI Integration -Wireless Component
Provides instructions for integrating IBM Tivoli Netcool/OMNIbus Web GUI with Tivoli Netcool Performance Manager.
The documentation is available on the knowledge center at http://www-01.ibm.com/support/knowledgecenter/SSBNJ7/welcome.
Service Management Connect
Connect, learn, and share with Service Management professionals: product support technical experts who provide their perspectives and expertise.
Access Network and Service Assurance community at https://www.ibm.com/ developerworks/servicemanagement/nsa/index.html. Use Service Management Connect in the following ways:
v Become involved with transparent development, an ongoing, open engagement between other users and IBM developers of Tivoli products. You can access early designs, sprint demonstrations, product roadmaps, and prerelease code.
v Connect one-on-one with the experts to collaborate and network about Tivoli and the Network and Service Assurance community.
v Read blogs to benefit from the expertise and experience of others. v Use wikis and forums to collaborate with the broader user community.
Related information:
Tivoli Netcool Performance Manager 1.4 community on developerWorks
Tivoli Netcool Performance Manager technical training
For Tivoli Netcool Performance Manager technical training information, see the following Tivoli Netcool Performance Manager Training website at:
https://tnpmsupport.persistentsys.com/training.
Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following ways for you to obtain the support you need:
Online
Access the IBM Software Support site at http://www.ibm.com/software/ support/probsub.html .
IBM Support Assistant
The IBM Support Assistant is a free local software serviceability workbench that helps you resolve questions and problems with IBM software
products. The Support Assistant provides quick access to support-related information and serviceability tools for problem determination. To install the Support Assistant software, go to http://www.ibm.com/software/ support/isa.
Troubleshooting Guide
For more information about resolving problems, see the problem determination information for this product.
Conventions used in this publication
Several conventions are used in this publication for special terms, actions, commands, and paths that are dependent on your operating system.
Typeface conventions
This publication uses the following typeface conventions:
Bold
v Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text
v Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes,
multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip:, and Operating system considerations:) v Keywords and parameters in text
Italic
v Citations (examples: titles of publications, diskettes, and CDs) v Words defined in text (example: a nonswitched line is called a
point-to-point line)
v Emphasis of words and letters (words as words example: "Use the word
that to introduce a restrictive clause."; letters as letters example: "The
LUN address must start with the letter L.")
v New terms in text (except in a definition list): a view is a frame in a workspace that contains data.
v Variables and values you must provide: ... where myname represents....
Monospace
v Examples and code examples
v File names, programming keywords, and other elements that are difficult to distinguish from surrounding text
v Message text and prompts addressed to the user v Text that the user must type
v Values for arguments or command options
Bold monospace
v Command names, and names of macros and utilities that you can type as commands
v Environment variable names in text v Keywords
v Parameter names in text: API structure parameters, command parameters and arguments, and configuration parameters v Process names
v Registry variable names in text v Script names
Chapter 1. Introduction
This document provides guidelines to be used when you plan the deployment of a Tivoli Netcool Performance Manager system. It provides guidance on how the system must be configured and what issues must be considered when you set up a Tivoli Netcool Performance Manager system.
This document is useful before you install Tivoli Netcool Performance Manager system, and after the hardware for the system is dimensioned. It gives guidance on how the hardware and software must be configured.
Dimensioning a Tivoli Netcool Performance Manager (Wireless) system is a complicated matter because of the large number of variables that are involved in customer networks. The accuracy of a hardware size has inherent risks as it is heavily reliant on precise entity counts. If Tivoli Netcool Performance Manager (Wireless) hardware proposed is too large then the cost of the system can be needlessly expensive and bids can be lost. If the hardware proposed is too small, you can face problems with the system and its performance. It results in possible large support costs because extra hardware might need to be purchased. There can be a considerable time lapse between early sizing (for example, Budgetary) and the Full (final) sizing. It is important to check the latest customer information and a Full sizing is performed by qualified IBM personnel to determine what customer hardware is required.
You can face challenges in the pre-sales cycle due to the following factors: v tight schedule for producing a sizing
v limited information available about customer network requirements
v people who have limited experience with Tivoli Netcool Performance Manager (Wireless)
Attention: Under any circumstances, you must not use a budgetary sizing to define the dimensioning and acquisition of Tivoli Netcool Performance Manager (Wireless) production hardware.
A Full Sizing must be performed by qualified IBM personnel before any hardware is purchased.
You must understand the difference between Budgetary and Full Sizing, and that both are used appropriately, limiting each one to its defined role. A Full (final) Sizing must be performed by qualified IBM personnel before any customer hardware is purchased. You can contact IBM Professional Service Personnel and begin this process. By not adhering to this process you can incur extra cost and significant delays to the implementation of a fully optimal system.
Training
For training material on the dimensioning procedure, log on to the following site:
Tivoli Technical Continuous Learning (TTCL) system at https://ttcl.centra.com/ login/index.aspx.
Course NSA38 for the Dimensioning Procedure (Search in catalog).
Chapter 2. Architecture
This information contains the architecture of the Tivoli Netcool Performance Manager system.
Overview
A Tivoli Netcool Performance Manager system consists of one or more Tivoli Netcool Performance Manager servers and a client layer. The client layer is a web-based user interface to the Tivoli Netcool Performance Manager application server.
The principal components can be installed on a single-server platform (a monolithic system) or on several different servers (a distributed system).
The server components might be deployed on Intel or AMD-based Red Hat Enterprise Linux servers, or on Oracle or Sun SPARC servers that run Solaris 10.
Principal components
Application framework
The core application that provides services to users to create and generate reports. It provides the web server for the user interface through a JBoss application server. It also runs an agent framework to gather information about data sources and information that is required to run reports. It provides platform management services to start, shut down, and monitor the application services.
Database component
An Oracle RDBMS is used to store Performance Management data from the network infrastructure, configuration data for the application, and time-based data for scheduling reports and maintenance tasks. If the database component is separate from the other components, then the Oracle client must be installed on the other component systems.
Loader component
The Loaders process the loader data files (LIF files) generated by the Gateways, and store the data in the Oracle database. Multiple different Loader processes might run simultaneously to process data from different network equipment vendors or from a single network equipment vendor and technology.
Gateway component
These services are provided by the Gateway framework, which transfers, parses and manipulates raw performance data from the network elements. Outputs from the Gateways are LIF files that are processed by the Loaders and stored in the Oracle database.
User management
User management is provided by an IBM Security Directory Server by using the Lightweight Directory Access Protocol (LDAP).
Optional components
Tivoli®Common Reporting
Provides the new Common Reporting GUI that is accessed by using a browser. To use Common Reporting, you must also install Tivoli Netcool Performance Manager - Application Studio on a Windows computer. Tivoli Netcool Performance Manager - Application Studio is an administrative and modelling tool for Common Reporting on Tivoli Netcool Performance Manager.
IBM Tivoli Monitoring
IBM Tivoli Monitoring software must be installed on a separate system to the application so that it can provide monitoring information if the application system fails.
Sample system architecture
You can use several system architectures for a Tivoli Netcool Performance Manager system. The appropriate system architecture is normally determined by using the Dimensioning procedure. Each server in the system must be sized according to the projected volumes and types of data that it must process. The projected growth of such data and any customer prerequisites must also be considered.
The following table shows different sample system architectures. These sample architectures provide example hardware for each architecture. The most suitable architecture must be chosen based on available system at the time of deployment.
Table 2. Sample architectures
System Type Database Component Application Component Loader Component Gateway Component Monolithic: 1 Server
Database component, Application component, Loaders, and Gateways on 1 server
Example: : IBM x3550 with 2 Intel Xeon Quad Core processors, 24 GB RAM
Monolithic: 2 Servers
Database component, Application component, and Loaders on 1 server
Example: IBM x3550 with 2 Intel Xeon Quad Core processors, 32 GB RAM
Gateways on separate servers Example: IBM x3550 with 2 Intel Xeon Quad Core processors, 12 GB RAM Distributed: 2 Servers Database component on 1 server Example: IBM x3850 with 2 Intel Xeon Quad Core processors, 64 GB RAM
Application component, Loaders, and Gateways on 1 server
Example: IBM x3550 with 2 Intel Xeon Quad Core processors, 32 GB RAM
Table 2. Sample architectures (continued) System Type Database Component Application Component Loader Component Gateway Component Distributed: 3 Servers Database component on 1 server Example: IBM x3850 with 4 Intel Xeon Quad Core processors, 128 GB RAM
Application component and Loaders on 1 server Example: IBM x3550 with 2 Intel Xeon Quad Core processors, 48 GB
RAM
Gateways on separate servers Example: IBM x3550 with 2 Intel Xeon Quad Core processors, 16 GB RAM Distributed: 3 Servers Database component on 1 server Example: IBM x3850 with 4 Intel Xeon Quad Core processors, 128 GB RAM Application component on 1 server Example: IBM x3550 with 1 Intel Xeon Quad Core processors, 32 GB RAM
Loaders and Gateways on another server
Example: IBM x3850 with 4 Intel Xeon Quad Core processors, 32 GB
RAM
Tivoli Netcool Performance Manager systems include the following servers in use: v IBM servers:
– x3850 – x3950
Each server might be suitable for certain tasks and must be sized with appropriate processors, memory, and disks to process the required data efficiently.
Minimum configuration
The minimum hardware requirements for a Tivoli Netcool Performance Manager server are:
v Processor with at least four Cores (IBM or Sun). v 24 GB core memory.
v 14 Disks (internal or on SAN) - 4 x 72 GB (146 GB disks can be considered) and 10 x 146 GB hard disks. Minimum disk size 72 GB and maximum disk size 300 GB.
v Optical drive (DVD ROM/R/RW).
Chapter 3. Requirements
Software and hardware requirements for deployment.
Software prerequisites
Third-party software: The following third-party software products are required before you install a Tivoli Netcool Performance Manager system.
Operating systems:
v Red Hat Enterprise Linux (RHEL) 5.9 and 6.x v IBM AIX 6.1 or later
v Oracle Solaris 10 Update 8
Database server:
v Oracle database 11.2.0.4 with partitioning option. Client:
v Oracle database 11.2.0.4 with partitioning option. v Oracle Instant Client 11.2 – Basic.
v Oracle Instant Client 11.2 – SQL*Plus Extension package.
The Oracle client is required on each component that does not reside on the same computer as the database component.
Other required software:
v JBoss application server 4.0.3 Service Pack 1 v Perl 5.6.1
v Jazz for Service Management 1.1.1.0
Note: For a complete list of software prerequisites, see Installing Tivoli Netcool Performance Manager - Wireless Component.
Software storage requirements: minimum disk storage that is required for each software component is shown in the following table.
Table 3. Software storage requirements
Software Location Minimum Size
Oracle 11 $ORACLE_HOME 2.5 GB
IBM Security Directory Server or IBM DB2®
/opt 1.5 GB
Application server components
/appl 512 MB
Database components /appl 150 MB
The hardware and software requirements for Jazz for Service Management can be found at the following location:
http://www-01.ibm.com/support/knowledgecenter/SSEKCU_1.1.1.0/ com.ibm.psc.doc_1.1.1.0/install/psc_c_install_prereqs.html
Disk space requirements for Security Directory Server:
http://www-01.ibm.com/support/knowledgecenter/SSVJJU_6.3.1/
com.ibm.IBMDS.doc_6.3.1/reference/r_ig_disk_requirement_for_installation.html
IBM Tivoli Monitoring is an optional component. The hardware and software requirements for it can be found at the following location: http://www-01.ibm.com/support/docview.wss?uid=swg27018000
Kernel parameters
The operating system kernel must be configured before installation to set the shared memory parameters that are required to install Oracle and Security Directory Server or DB2. These parameters can be set automatically by using the system_configurescript that is provided in the Platform package that is included in the Tivoli Netcool Performance Manager software package.
Solaris kernel settings
On Solaris 10, the usual method for configuring kernel parameters is to use the resource controls mechanism, through the projadd and projmod tools.
The kernel settings that are required for Solaris are shown here:
forceload: sys/shmsys forceload: sys/semsys set noexec_user_stack=1 set noexec_user_stack_log=1 set maxphys=1048576 set semsys:seminfo_semmnu=1024 set semsys:seminfo_semmsl=16010 set semsys:seminfo_semmni=4096 set semsys:seminfo_semmns=65535 set semsys:seminfo_semume=512 set semsys:seminfo_semopm=100 set semsys:seminfo_semvmx=32767 set shmsys:shminfo_shmmax=34359738368 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=1024 set shmsys:shminfo_shmseg=100
Linux kernel settings
On RHEL, these parameters are set in the /etc/sysctl.conf file or by using the
sysctlcommand.
The kernel settings that are required for Linux are shown here:
kernel.sem = 250 32000 100 128 kernel.shmmax = 68719476736 kernel.shmmni = 4096 kernel.shmall = 4294967296 fs.file-max = 753808 net.core.rmem_default = 4194304 net.core.rmem_max=4194304 net.core.wmem_default = 262144 net.core.wmem_max = 262144 net.ipv4.ip_local_port_range = 1024 65000
SWAP
The system must be configured with sufficient swap space. If the required amount of swap space is not allocated, installation might fail or the process fails to
initialize.
Extra swap space is required for the application and loader processes. The amount of allocated swap space on each server depends on the sizing recommendations.
For database servers, you must locate swap partitions on SAN storage.
SWAP for Solaris
Swap space must be configured depending on the amount of physical memory on the server.
An example of the swap setting for Oracle 11 on Solaris (monolithic and distributed systems) is:
v Dedicated distributed database server, swap allocation = the size of RAM. v Monolithic (single node) solutions, swap allocation = 2 times the size of RAM.
SWAP for RHEL
Swap space must be configured depending on the amount of physical memory on the server.
Example swap settings for Oracle 11 on RHEL are:
v Dedicated distributed database server, swap allocation = 2 times the size of RAM
v Monolithic (single node) solutions, swap allocation = 2.5 times the size of RAM
For example, on a dedicated system with 32 GB of memory, the swap size would be 64 GB.
For example, on a monolithic system with 32 GB of memory, the swap size would be 80 GB.
Solaris zones
The deployment of a Tivoli Netcool Performance Manager system is supported on Solaris 10 zones.
A single non-global zone can be installed as a Tivoli Netcool Performance Manager server in the same way as a stand-alone Solaris server. The usual application of this capability is to install a distributed system over two or more zones on a single SPARC platform. It helps limit the cost of Oracle licenses that depend on the number of processors.
In addition, the zones might be defined as containers that use the resource control features of the Solaris 10 operating system. For example, a single server with 128 GB of RAM might be split into two containers, one for the database server and the other for the Application server and Loaders. The Application container would occupy a non-global zone (zone 1) with its memory usage capped at 32 GB. The database server would be installed on another zone (zone 2) with memory capped at 72 GB. In this way, the system resources are allocated to the zones according to their sizing requirements.
If a Solaris server is to be installed using zones and containers, then only
non-global zones can be used as Tivoli Netcool Performance Manager servers. The global zone must not have any components that are installed on it.
On a zoned Solaris server, the kernel configuration must be completed for the global zone and non-global zones. The Platform package must be installed on the global zone and the system_configure script that is run to update the kernel parameters. On the non-global zones, system_configure must also be run to create the resource controls projects for Security Directory Server, DB2, and Oracle.
Prerequisite for hardware purchase and deployment
v RAID 10 required and is the only supported RAID configuration for ALL Oracle file systems (/oradata*, /oralogs*, and /oradump*)
v RAID 5 is not supported and must not be used forTivoli Netcool Performance Manager database file systems.
v RAID 3 is not supported and must not be used for Tivoli Netcool Performance Manager database file systems.
v RAID 4 is not supported and must not be used for Tivoli Netcool Performance Manager database file systems.
v RAID 6 is not supported and must not be used for Tivoli Netcool Performance Manager database file systems.
v RAID Oracle redo logs (oralogs1 and oralogs2) must be placed on separate LUNs to that of the Oracle data files.
v RAID file systems for Oracle files require a minimum Stripe/Segment Size of 512 KB.
v Network attach storage that is not supported, v All external file system must be stored on SAN only.
v Average Service Time per LUN is recommended to be < 5 ms for optimal performance.
v IO Wait Time per LUN is recommended to be < 35 ms (average sample interval <= 10 seconds) for optimal performance.
v A minimum of 2 GB of cache is required per Fibre Channel controller. (average sample interval <= 10 seconds)
v The Underlying IP Network must support min 1 GB/s transfer rates. v Linux supported ext3 file systems only.
v Solaris supported UFS file systems (/oradata*, /oralogs*, and /oradump), ZFS file systems (/, /appl, and /opt)
v No remotely shared file systems are recommended and supported. v Oracle RAC is not supported
v Periodic system audits and analysis are recommended to ensure optimal performance and identify any future growth needs.
Chapter 4. File types and disk layout
Supported file types and disk layout.
Terminology definitions
Table 4. Storage terminology
Term Definition
Spindle A Spindle is a physical hard disk.
Disk Group A Disk Group is a set of physical hard disks (or spindles) that are grouped into a disk array.
See section “RAID levels overview” on page 12, for details about disk arrays.
Disk array Same as Disk Group.
RAID A RAID is a logical device that uses a Disk Group, applying specific rules to form one storage unit.
LUN A LUN is a logical device that is part of a disk array, or is an entire disk array. A LUN is exported from SAN and presented to an OS as one single logical disk device. Multiple LUNs can be exported to an OS and presented as different devices that share physical RAID array.
SCSI disk A SCSI disk is a fast physical hard disk that is used for performance. The main beneficial characteristic is RPM (rotations per minute). SATA disk A SATA disk is normally slower than a SCSI disk but can have the advantage of having greater capacity than a SCSI disk. SATA disks can be used to store files where IO performance is not the major factor.
SAS Serial Attached SCSI. A computer bus that is used to move data to and from storage devices.
Note: All external file systems must reside on SAN.
RAID levels overview
Different RAID levels provide a different level of protection.
The following is a summary of the RAID levels that are used in Tivoli Netcool Performance Manager application environments and the advantages of each level: v RAID-0 (block-level striping without mirroring) offers high performance, but
does not provide any data redundancy.
v RAID-1 (mirroring without striping) offers high performance and data protection for read-intensive applications. It is most suited to applications that require high data availability, good read response times, and where cost is a secondary issue. v RAID-5 (block-level striping with distributed parity) offers both data protection
and increased throughput. It stripes data and parity across all drives in the array. Because of the way that data is written to data files in small blocks, RAID-5 must not be used for Tivoli Netcool Performance Manager systems. v RAID-10 (mirrored and striped sets, also known as RAID 1+0) offers higher
performance than RAID-1 and more reliability than RAID-5. RAID-10 is the best fault-tolerant solution in terms of protection and performance.
Database RAID and disk types
There are various disk RAID technologies available. Depending on the type of database files, different disk types and RAID levels are suitable.
Note: In a Tivoli Netcool Performance Manager application environment only RAID-10 and RAID-1 array types must be used on mount points that store the application data. Any other array type is not supported.
Note: Estimates for the total size of disk space that is allocated to each mount point must be known before you start any deployment activity. You must complete dimensioning the system before that.
The following sections provide examples, per data file and per mount point, for a target server.
Database data files and temp files
The Oracle database stores all loaded application data in data files. Data files must be placed on devices with good I/O performance.
The Tivoli Netcool Performance Manager database stores application data in data files and allocates temporary segments in temp files when necessary. The files are stored on disk devices mounted to four mount points:
v /oradata01 v /oradata02 v /oradata03 v /oradata04
Hardware
v Small (72 GB per disk; depending on disk availability 146 GB or 300 GB disks can also be considered). Fast SCSI disks (at least 10 k RPM. 15 k RPM achieves a greater I/O performance increase).
Configuration
All disks that are allocated to store database data files must be grouped into one RAID 1+0 disk array that spreads workload to all allocated spindles.
4 LUNs are exported from this array and presented to an OS to mount into four mount points:
v /oradata01 v /oradata02 v /oradata03 v /oradata04
Database online redo log files
Database online redo log files store transactions history.
They are one of the most demanding points in terms of sequential I/O operations performance. Online redo log files must be protected on a hardware level, placed on the dedicated disks or dedicated mirrored storage devices.
Hardware
v 4 small (72 GB per disk, 146 GB, or 300 GB disks can also be considered) and fast SCSI disks (at least 15 k RPM). Set up as 2 RAID-1 devices (two mirrors), exporting 1 LUN for each.
v For small proof of concept deployments, 2 small (72 GB per disk, 146 GB, or 300 GB disks can also be considered) and fast SCSI disks (at least 15 k RPM). Set up as two dedicated disk devices, exporting 1 LUN for each.
Note: This configuration does not offer data redundancy and must be considered only as a proof of concept and not with production data.
Configuration
Production systems
v 4 Disks (2 disk mirrors, 2 x RAID-1).
v 1 LUN is exported to an OS from each disk mirror.
v LUNs that were exported in the previous step are mounted to /oralogs1 and /oralogs2mount points.
Proof of concept systems (no data redundancy)
v Dedicated disks.
v 1 LUN is exported to an OS from each disk mirror.
v LUNS is mounted to /oralogs1 and /oralogs2 mount points.
Note: If only bigger disks are available to store online redo log files, they must be partitioned to use only the first 100 GB of the disk and leave the rest of the disk deallocated. Normally external disk cylinders provide better sequential I/O performance.
Database archive log files
Archive log files store database transactions history and can be used for database recovery operations. They are important files in any database environment. These files can be placed to slower but larger disks as I/O performance is not a major factor for a disk volume where archive log files are stored.
Tivoli Netcool Performance Manager database during normal operation generates tens of GBs of Archive log files per day. As a result, a large disk volume is required to store them.
Hardware
v Slower but larger SATA disks (7200 RPM) of appropriate total size must be grouped into one RAID-10 array.
Configuration
v 1 LUN is exported from the disk array that is created in the previous step and mounted to /oradump/archivelogs mount point.
Database backup files
Database backups are an important part of any production environment and must be taken regularly.
One backup approach for backing up the Tivoli Netcool Performance Manager database environment is a proxy full database backup that is stored on disk, with possible subsequent backups to tape to increase data safety. The backup database image is updated on disk regularly by applying recent transactions from the archive log files.
To store a backup copy, enough disks must be allocated to store files of approximately the same size as the total Tivoli Netcool Performance Manager database plus 10%.
See Chapter 6, “Backup strategy,” on page 27, for details on backing up the database.
Hardware
v Slower but larger SATA disks (7200 RPM) of appropriate total size must be grouped into one RAID-10 array.
Configuration
v 1 LUN is exported from the disk array that is created in the previous step that is mounted to /oradump/backups mount point.
Log files
Tivoli Netcool Performance Manager maintains all its application log files in /appl/virtuo/logs. A cron job, created during installation, archives all log files to /data/trace_archive1by default (in gzip format). You must manage the available file system space where the /data/trace_archive1 directory is stored .
Hardware
In most cases, both directories can be stored on the root file system. If
/data/trace_archive1needs to be preserved for a long time, slower but larger SATA disks (7200 RPM) of appropriate total size must be grouped into one RAID-1 or RAID-10 array, either on the SAN or internal to the application server computer.
Configuration
In most cases, both directories can be stored on the root file system.
Alternatively, 1 LUN is exported from the disk array that is created in the previous step and mounted to /data/trace_archive1 mount point.
Report results
Tivoli Netcool Performance Manager report results are stored in /appl/virtuo/var/rg.
This directory contains two sub directories: v Logs - report result logs.
v Spool - result results (XML files) and exports (CSV, XML, XLS).
These directories are not archived by the system. You must manage the available file system space where these directories are stored.
Configuration
In most cases, both directories can be stored on the /appl file system.
Alternatively, 1 LUN is exported from the disk array that is created in the previous step and mounted to /appl/virtuo/var/rg mount point.
Hardware
In most cases, both directories can be stored on the /appl file system. If you want to preserve reports and their associated logs for a long time, slower, group larger SATA disks (7200 RPM) of appropriate total size into one RAID-1 or RAID-10 array. You can store them either on the SAN or internal to the application server computer.
Loader files (LIF files)
Loader files, or LIF files, are generated by the Gateway component and contain formatted raw performance data from the network. These files are processed by the data loader processes and the information is stored in the database.
The loader LIF files are stored in /appl/virtuo/var/loader/spool by default. As LIF files can take a large amount of disk space (especially in a backlog scenario), it is important to carefully select where they are located. Depending on the
deployment topology (monolithic or distributed) and the available hardware, LIFs can either be on the Loader servers or on the SAN.
The number of days LIF files are kept is configurable. The number of days to keep LIF files is partly determined by the frequency of backups. If backups are taken weekly, you must keep eight days of LIF files so that the LIF files can be reloaded easily. Normally three days are acceptable but it varies from deployment to deployment.
LIF file size must be carefully assessed. When you move from legacy products, you must know LIF file sizes.
You can estimate the daily LIF file size from the EDDS (Estimated Daily Database Size). 10 GB of EDDS normally corresponds to 70 GB of LIF files (it can vary depending on the Technology Packs and the percentage of counters loaded).
For example, for a system with an EDDS of 100 GB and a 5-day backlog retention policy, the LIF file size might be estimated to 100*7*5 = 3.5 TB logical, and 7 TB when taking into account RAID-1. 100 GB of EDDS requires a minimum of eight disks (30 GB EDDS can saturate two disks in RAID-1), a possible configuration includes eight 1-TB SATA-2 disks, or preferably 16 500-GB disks. The disks are configured in RAID-10 to take into account extra IO during backlog processing.
Backlog scenarios need to be taken into account when you compute the total disk space required for storing LIFs.
When you store LIF files, you must also consider the large number of concurrent random reads and writes. 30 GB daily data size (EDDS) can saturate the IO capabilities of two 7200-RPM SATA-2 disks that are configured in RAID-1.
Configuration
Depending on the configuration, the disks that hold the LIFs can be stored on the Loader servers.
Alternatively, 1 LUN is exported from the disk array that is created in the previous step and mounted to /appl/virtuo/var/loader/spool.
Alternatively, 1 LUN is created for each Technology Pack or data source and mounted to /appl/virtuo/var/loader/spool/<techpack or datasource>.
Hardware
Several large SATA-2 disks that are configured in RAID-1 or RAID-10 (depending on size and configuration).
Gateway files (raw files)
Raw files are generated on the gateways, converted to LIF files and transferred to the application server. They must be maintained on the gateway until the day's data is successfully loaded into the database. Raw, gateway files must be placed on RAID-1 devices.
The gateways are installed in $WMCROOT/gways. All gateway framework files are in the directory: $GATEWAY_ROOT.
Each gateway has spool directories that are configured for input files, intermediate files, and loader files.
v IN_DIR=/spool/input_d v INT_DIR=/spool/inter_d v OUT_DIR=/spool/output_d
Spool directories must be separated from the main installation directory to avoid memory issues as spool directories grow. The preceding example assumes that spool directory is created from root directory.
Disk layout on the database server
A list of the minimum disk requirements for the database component is provided in the following table. The minimum files system sizes that are provided are only a minimum and the file systems are sized according to the customers-specific
requirements.
Details on the RAID type and LUN setup that is required for each file system and data file type are given in the previous sections.
Table 5. Minimum disk requirements
File system Software Typical Size
Minimum Disks
Required RAID Type
/ Operating system 8 GB 2 (typically on internal disks) 1 swap Operating system 8 GB /var Operating system 8 GB /appl Oracle and
Tivoli Netcool Performance Manager
24 GB
/export/home User home accounts 2 GB /data/ trace_log1 Trace log location 8 GB /data/ trace_archive1 Trace archive location 8 GB /oralogs1 Oracle redo log
location 1
8 GB 2 1
Table 5. Minimum disk requirements (continued)
File system Software Typical Size
Minimum Disks
Required RAID Type /oralogs2 Oracle redo log
location 2
8 GB 2 1
/oradata01 Oracle storage location 1 (typical size -400 GB) 32 GB (min) 4 (Typically many more depending on the estimated size of the database. Total size is calculated based on output for sizing report) 1+0
/oradata02 Oracle storage location 2 (typical size -300 GB)
32 GB (min) Total size is calculated based on output for sizing report. /oradata03 Oracle storage
location 3 ((DBSize – 700G)*0.5)
32 GB (min) Total size is calculated based on output for sizing report. /oradata04 Oracle storage
location 4 ((DBSize – 700G)*0.5)
32 GB (min) Total size is calculated based on output for sizing report. /oradump/ archivelogs Oracle Archive log location (SATA disks) (Required Archive logs space is 50 * EDDS)
100 GB (min) 2 Disks for RAID-1 Or 4 Disks for RAID-10 (Typically many more depending on the estimated size of the database) 1+0 /oradump/ backups Oracle backup location (SATA disks) (Required backup space must be 1.2 * database Size)
100 GB (min) 2 Disks for RAID-1 Or 4 Disks for RAID-10 (Typically many more depending on the estimated size of the database) 1+0
Chapter 5. System configuration
File system, network, and database configurations.
File system and SAN configuration
The following are suggested file system and SAN configurations:
v On Linux, all database server file systems must be configured with file system type ext3. For performance reasons, access time logging for files and directories must be removed (defaults, noatime, nodiratime).
v ext3 supports three types of journaling modes: v Journal - has higher performance overhead.
v Ordered - is the default setting and suggested option.
v Writeback - provides the fastest access to the data at the expense of data consistency.
v On Solaris, all database file systems (/oradata*, /oralogs*, and /oradump) must be configured as UFS, while all other application-related file systems (/, /appl, and /opt) must be configured as ZFS.
v A minimum of 2 GB of cache is required per Fibre Channel controller. v Direct-IO must be enabled for Oracle by setting the Oracle
filesystemio_optionsparameter:
filesystemio_options = setall
v Individual SAN LUNs must be created for each /oradata01.04 File system, with a minimum Stripe/Segment Size of 512 KB and RAID type 1+0 (mirroring and striping).
v Oracle redo logs (oralogs1 and oralogs2) must be placed on separate LUNs.
Network configuration
The following are suggested network configurations:
v In gigabit networks, large maximum transmission units (MTU) sizes (also known as JumboFrames) can provide better network performance. To transfer large amounts of data at gigabit speeds, increasing the default MTU size can provide significant performance gains. A sample MTU Jumbo size is 9000.
v The Underlying IP Network must support 1 GB/S transfer rates.
Database configuration
Database memory, database redo logs and database temporary tablespace configurations.
Database memory configuration
Following are the main memory components for Oracle: v SGA (Shared Global Area)
v PGA (Program Global Area)
Both parameters depend on the amount of data loaded each day into the database and are calculated as part of the Dimensioning procedure.
8 GB of the target server must be reserved for the OS and background tasks.
SGA
The SGA is calculated as part of the Dimensioning procedure. The Dimensioning procedure estimates the amount of daily loaded data (EDDS - Estimated Daily Database Size) based on network size. The SGA is then calculated at 1.3 * EDDS.
The SGA is made up of two main components, SHARED_POOL_SIZE and DB_CACHE_SIZE.
v DB_CACHE_SIZE- for optimal performance, store a full day of data in to the database cache. Because of the load patterns, an undersized database cache might double most IOs, and a READ bottleneck on the /oradata* file systems during loading, especially later in the day.
For the resizing of an existing system, the required database buffer cache can be computed from the size of the daily partitions of a running system.
v SHARED_POOL_SIZE- for Tivoli Netcool Performance Manager, a minimum of 3 GB must be configured for the SHARED_POOL_SIZE.
Automatic shared memory management:
Automatic Shared Memory Management (ASMM) is Oracle automatic management of SGA memory.
Important: ASMM must not be used with Tivoli Netcool Performance Manager because of Tivoli Netcool Performance Manager use of generated SQL and because memory would not be used optimally on the system workloads.
The SGA value that is an output from the Dimensioning procedure is the total size of SGA. ASMM is configured ON by default in Tivoli Netcool Performance Manager and must be turned OFF after installation. The total size of the SGA must be divided into specific SGA parameters that are buffer cache and shared pool size.
The following table provides an example of SGA parameter settings that are used for a server. The server is dedicated to the database, with 128 GB RAM, 80 GB SGA, and 40 GB PGA (8 GB of the total RAM is reserved for the OS).
Table 6. Breakdown of database SGA parameters
Parameter Setting Details
sga_max_size 81920M Set by Oracle to total SGA size.
sga_target 0 Disables ASMM when set to
0.
Table 6. Breakdown of database SGA parameters (continued)
Parameter Setting Details
db_cache_size 77G Available buffer pool cache memory.
log_buffer 256M Dependent on system
resources and load activity. Normally 11 - 400 MB. java_pool_size 100M Set to 100M for Java pool. large_pool_size 100M Set to 100M for large pool.
To disable ASMM, run the following commands that are connected to the database with SYSDBA privileges:
ALTER SYSTEM SET sga_target=0 SCOPE=spfile sid='*'; ALTER SYSTEM RESET sga_max_size SCOPE=spfile sid='*';
ALTER SYSTEM SET db_cache_size=<db_cache_size> SCOPE=spfile sid='*';
ALTER SYSTEM SET shared_pool_size=<shared_pool_size_at_least3G> SCOPE=spfile sid='*'; ALTER SYSTEM SET large_pool_size=100M SCOPE=spfile sid='*';
ALTER SYSTEM SET java_pool_size=100M SCOPE=spfile sid='*';
The database must be restarted to enable these changes.
PGA: PGA is used by Oracle for sorting data for individual sessions. Normally the PGA is set to approximately 20% of the SGA. Because of the number of large sorts on a typical Tivoli Netcool Performance Manager database, the PGA must be set to approximately 25% of the database cache.
The following table provides an example of PGA parameter settings that are used for a server that is dedicated to the database. The server has 128 GB RAM, 80 GB SGA, and 40 GB PGA (8 GB of the total RAM is reserved for the OS).
Table 7. Breakdown of PGA parameters
Parameter Setting Details
pga_aggregate_target 40G Target aggregate PGA memory available to all server processes.
Database redo logs
Oracle redo logs record all changes to the data files. The normal redo log setup consists of five groups; each group has two members. These members are split between the two locations, /oralogs1 and /oralogs2.
Five redo log groups are normal for systems that are going to be set up in archive log mode. It is suggested when the system is being backed up.
The size of the redo logs depends on the amount of activity on the system. It is usual for redo log groups that switch once every 20 minutes. The size of the system affects the switching frequency.
For small to medium systems, the redo logs can be set between 400 MB and 1G for each member. It results in 400 MB * 2 members * 5 groups => 4 GB. 4 GB is divided evenly between /oralogs1 and /oralogs2.
For a larger system, the redo logs can be sized at 3 GB each for each member. The results in 3 GB * 2 members * 5 groups => 30 GB. 30 GB is divided evenly between the /oralogs locations.
The configuration and sizing of the database redo logs are updated and delivered to the customer in a customer database template, vtdb_<customer_name>.dbt.
See section “Updating customer database template” on page 34, for information on updating the database redo logs with the correct sizings and locations.
Database temporary tablespace
Oracle temporary tablespaces are used to manage space for database sort
operations and for storing global temporary tables. If a large sort operation cannot fit in memory, then space will be allocated in a temporary tablespace for doing the sort operation.
In Tivoli Netcool Performance Manager , large reports or complex summaries, which join across a number of large tables will require a large temporary tablespace. A suitably sized TEMP tablespace is 80 GB-100 GB.
Application server configuration
On the Application Server component, JBoss must be configured with 3 GB of Java heap space (“–Xms3G –Xmx3G”). This setting can be configured in the file:
$WMCROOT/conf/as/jvm-default.ini.
To change the setting to 3G, make the following update to the jvm-default.ini file:
-Xms3G -Xmx3G -XX:+AggressiveHeap -XX:MaxPermSize=96m
The Security Directory Service, which is required for LDAP authentication and authorization, uses approximately 2 GB of Random Access Memory (RAM), other Tivoli Netcool Performance Manager Java processes use approximately 2 GB.
An extra 8 GB RAM must be reserved for the OS and background tasks.
Loader configuration
The number of loaders to configure on a system depends on the number of technology packs and the amount of data to load on the system.
There is a minimum of one loader per datasource, and in most cases two datasources per technology pack:
v The Performance Counter datasource v The Hierarchy datasource
Certain technology packs, such as the Ericsson UTRAN Technology Pack, have more datasources, the PDF counter datasource in the Ericsson UTRAN Technology Pack.
Most small datasources (such as the hierarchy datasource or the performance counter datasource for small technology packs with few entities), require only one single-threaded loader with 512 MB to 1 GB of memory. For example, JVM arguments: “–Xms1G –Xmx1G”.
Larger datasources require the use of one or more multithreaded loaders. For example, it is possible to configure one multithreaded loader with two LIF-parser threads and four DB-writer threads for each 10000 cell of an average technology pack. Each such loader requires more memory as they process several LIFs in parallel. For example, “–Xms3G –Xmx3G” to configure 3 GB of memory.
The following list gives an example of a possible configuration for a system with 20000 Nokia UTRAN cells and 10000 Ericsson cells with PDF counters. The information about memory requirements is provided from the Dimensioning procedure, and depend on the actual network size, the load interval (for example, 15 minutes), and the percentage of counters that are loaded.
Nokia hierarchy One single threaded loader with 512 MB RAM Nokia PM Two multithreaded loaders with 3 GB RAM each Ericsson hierarchy One single threaded loader with 512 MB RAM Ericsson PM One multithreaded loader with 3 GB RAM Ericsson PDF One multithreaded loader with 3 GB RAM
In this example, the system would consist of a total of 6 loaders and 13 GB of RAM.
The following must also be set:
v The ’insert.max.batch’ size from the lc_loader_config_properties table must be set to the default value of 5000.
v You must leave an extra 8 GB of RAM for the OS and background tasks. v
– For loaders, allow 0.2 GB of memory for every 1 GB of data that goes into the database each day (EDDS). Minimum memory per loader (for example, for small hierarchy loaders) is 400 MB.
Gateway configuration
The Gateway framework uses the following configuration files. They are in the vstartdirectory:
v EngineConfig.pm– configuration file of the first stage of the Gateway.
v UserConfig.pm– a user configurable Perl module for configuring the Gateway Post Parser.
v TransferConfig.pm– configures the transfer in of raw files and transfer out of processed LIF files.
v Gateway_start.sh– this script is used to start the Gateway.
Within the Gateway configuration, there are configuration directories for every vendor subsystem and data revision. They are contained within a directory called config. Following are the contents of these directories:
v The docs directory contains documentation on the configuration for each vendor data revision supported.
v The configuration directories are named based on the vendor subsystem, for example ericsson-bss.
Within each vendor subsystem directory, there are directories for each data revision supported. For example, r12_ascii, r12_asn1. These directories contain the
configuration files that are to be referenced by the Gateway framework to parse the vendor data. For example, EngineConfig.pm, UserConfig.pm,
StatisticsConfig.pm, TransferConfig.pm, NotificationConfig.pm.
The StatisticsConfig.pm, TransferConfig.pm, and NotificationConfig.pm files can be obtained from the Gateway framework example directory. If the Statistics Configuration is configured, the file_statistics and block_statistics directory must be created manually by the user, and the path that is specified in the StatisticsConfig.pm.
Configuration of properties files
The following are some of the environment variables that are required in the properties file for each Gateway configuration:
v LOG_LEVEL- specifies the log level that was previously defined in gateway_start.sh.
v LOG_FILE- specifies the path and file name of the log file that was previously defined in gateway_start.sh.
v MAX_NUMBER_OF_PROCESSES- specifies the number of Gateway processes allowed to be created for multiple independent blocks that are configured in the UserConfig.pm. By default, this variable must be set to 1.
Configuration of environment variables
The following environment variables must be set:
v GATEWAY_ROOT: the base path to where all Gateway components are installed.
GATEWAY_ROOT=${WMCROOT}/gways
v TZ: the time zone as defined in RFC 822
Universal: GMT, UT
US zones : EST, EDT, CST, CDT, MST, MDT, PST, PDT Military : A to Z (except J)
Other : +HHMM or -HHMM
ISO 8601 : +HH:MM, +HH, -HH:MM, -HH
v PERL5_BASE: the full path to where Perl base is installed, which contains the bin and lib directories.
PERL5_BASE=/usr
v PERL5: the path of the Perl command, which is normally in the bin directory of PERL5_BASE. If it is not in the bin directory, it must be set.
Configuration of spool directories
Create the spool directories for input files, intermediate files, and loader files. Set the directories in the properties file for the following variables:
v IN_DIR=/spool/input_d v INT_DIR=/spool/inter_d v OUT_DIR=/spool/output_d
The spool directories must be separated from the main installation directory to avoid memory issues as spool directories grow. The preceding example assumes that spool directory is created from root directory.
Jazz for Service Management and Tivoli Common Reporting
Installation and configuration of Jazz for Service Management and Tivoli Common Reporting is documented within the Installing Tivoli Netcool Performance Manager
-Wireless Component.
Modeling
The installation, configuration, and usage of Tivoli Netcool Performance Manager -Application Studio that can be used to create enhanced Cognos 10 models is described in Installing and Using Tivoli Netcool Performance Manager - Application
Studio 1.4.1.
IBM Tivoli Monitoring
IBM Tivoli Monitoring monitors and optimizes hardware and application
performance. The IBM Tivoli Monitoring application deploys agents to monitor the performance of target systems and to relay the data back to the IBM Tivoli
Monitoring system. You can store and report on the data in the IBM Tivoli Monitoring system.
Details of installing the IBM Tivoli Monitoring agents and using them with IBM Tivoli Netcool Performance Manager are covered in the Tivoli Monitoring Integration
- Wireless Component.
Details of how to integrate Tivoli Netcool Performance Manager with IBM Tivoli Monitoring are covered in the Tivoli Monitoring Integration - Wireless Component. This document also provides instructions on how to deploy the following Tivoli Netcool Performance Manager agents on IBM Tivoli Monitoring:
v Application server v Loaders
v Gateways
Chapter 6. Backup strategy
A database and file system backup strategy is required for backing up the Tivoli Netcool Performance Manager system. Frequent Tivoli Netcool Performance Manager production database backups must be taken. The frequency of database backups is determined by customer data backup policy and hardware availability.
It is important to back up the Oracle database regularly. Backups of the database must be taken more often than backups of the system.
Database backups
Database backup is an important process that is initiated and carried out on the Tivoli Netcool Performance Manager platform regularly. Data is constantly being read from, and written to, the Oracle database. Procedures must be in place to back up and archive the data correctly.
Database backup storage
Two disk areas must exist on the database server where files related to database backups are stored.
v /oradump/archivelogs– mount point that mounts an appropriate LUN exported from dedicated RAID-10 disk array of large SATA disks, where Archive log files are accumulated between database backup image recovery cycles.
The database during normal operation generates tens of gigabytes of Archive log files per day. As result a large disk volume is required to store them.
v /oradump/backups– mount point that mounts an appropriate LUN exported from dedicated RAID-10 disk array of large SATA disks, where a database backup image is stored.
To store a backup copy, sufficient number of disks must be allocated to store files approximately of the same size as the total database size + 10%.
Database backup procedures
Frequent database backups must be taken. The frequency of database backups is determined by customer data backup policy and hardware availability.
The following outline of the database backup approach is based on the use of the Oracle Recovery Manager (RMAN) that is a part of the Oracle Server software. For detailed information about the Oracle Recovery Manager read the Oracle
documentation, see Oracle Database Backup and Recovery Reference, 11 g Release 2
(11.2) at http://www.oracle.com/technology/documentation/index.html.
The following database backup approach consists of a number of activities that allow the recovery of database function and data in the event of hardware failure.
Prerequisites
v The database is running in ARCHIVELOG mode.
v Disk space to store Archive log files is sufficient and available on a database server; an appropriate LUN is mounted to /oradump/archivelogs mount point. v Disk space sufficient to store one full copy of a database is available on a
database server; an appropriate LUN is mounted to /oradump/backups mount point.
Database backup activities
1. At the start of a Tivoli Netcool Performance Manager application production cycle, a full database backup is taken with RMAN. Database file images are stored in a database backup copy directory: /oradump/backups.
2. Between backup image recovery cycles Archive log files are generated by the database and stored in the following directory: /oradump/archivelogs.
3. At the start of each backup image recovery cycle, newly generated and unused Archive log files are applied to a backup copy of the database. It helps protect the Tivoli Netcool Performance Manager system from loss of data, regular file system backups must be made in addition to backing up the Oracle database. After successful application of these files, previously applied Archive log files can be removed from disk to create more space for the new Archive log files. 4. A database backup copy can be copied to tape by using the normal OS files
backup procedures or Oracle RMAN, further securing customer data.
File system backup
To protect the Tivoli Netcool Performance Manager system from loss of data, regular file system backups must be made in addition to backing up the Oracle database.
The following file systems must be included in the backup: v / v /var v /opt v /appl v /export/home v /data/trace_log1 v /data/trace_archive1
A backup schedule must include full and incremental backups of these file
systems. Ensure that the backup media are correctly labeled and stored in a secure location, and that the integrity of the backups is checked periodically.
Cold standby
A cold standby is a system, that can with a small amount of configuration, take over from your existing Tivoli Netcool Performance Manager wireless system if a failure occurs.
A Tivoli Netcool Performance Manager wireless cold standby mirrors the infrastructure of your existing Tivoli Netcool Performance Manager wireless system. If your existing Tivoli Netcool Performance Manager wireless system experiences a serious error, you can quickly configure the cold standby to act as failover.
The steps that are required to set up a cold standby are described in detail in the
Administering Tivoli Netcool Performance Manager - Wireless Component.
Chapter 7. Database related information
Database OS partitions sizing
The following is an example layout of tablespaces and disk partitions for a large system.
v /oradata01- holds the system tablespaces, temporary tablespace, and smaller application tablespaces. Their sizes are relatively static.
v /oradata02- holds the Undo tablespace. You must keep the tablespaces separate from the other tablespaces, especially Traffic tablespaces, to avoid contention. v /oradata03And /oradata04 - hold all Traffic tablespaces. Can be sized only by
getting information of the Technology Pack tables, customer data, and volume of data per day. This must be obtained from the Dimensioning procedure.
v /oradump- holds Archive logs when the database is in archive log mode. It contains customer data and depends on the backup policy that is implemented by the customer.
Note: If required, you can spread the traffic tablespaces across oradata01 to oradata04 partitions to avoid congestion of data.
Table 8. Layout of tablespaces and disk partitions
Disk Partition Tablespaces Tablespace Size (GB) Disk size (GB)
/oradata01 SYSTEM 66 SYSAUX 66 WM_CLIENT 20 WM_FLEXPM 20 WM_SA 20 WM_QUEUES 20 ENTERPRISE 20 TEMP 80
Total disk size 400
/oradata02 UNDO 100
Total disk size 300 /oradata03 TRAFFIC_SMALL <data dependent>
TRAFFIC_MEDIUM <data dependent> TRAFFIC_LARGE <data dependent>
Total disk size xxx /oradata04 TRAFFIC_JUMBO <data dependent>
TRAFFIC_JUMBOPLUS<data dependent>
Total disk size xxx /oralogs1 redo log group1,
member a
3 (range 1-3GB) redo log group2,
member a
3 (range 1-3GB)
Table 8. Layout of tablespaces and disk partitions (continued)
Disk Partition Tablespaces Tablespace Size (GB) Disk size (GB) redo log group3,
member a
3 (range 1-3GB) redo log group4,
member a
3 (range 1-3GB) redo log group5,
member a
3 (range 1-3GB)
Total disk size 70 /oralogs2 redo log group1,
member b
3 (range 1-3GB) redo log group2,
member b
3 (range 1-3GB) redo log group3,
member b
3 (range 1-3GB) redo log group4,
member b
3 (range 1-3GB) redo log group5,
member b
3 (range 1-3GB)
Total disk size 70 /oradump Archive logs and
backups
<data dependent>
Total disk size xxx
The configuration and sizing of the database tablespaces are updated and delivered to a customer in a customer database template:
vtdb_<customer_name>.dbt.
See “Updating customer database template” on page 34, for information about creating and updating a customer's database template with the correct sizings and locations.
Database extents sizing
Tivoli Netcool Performance Manager systems are deployed with a database, which contains five default tablespaces for holding traffic data. These tablespaces are as follows: v TRAFFIC_SMALL v TRAFFIC_MEDIUM v TRAFFIC_LARGE v TRAFFIC_JUMBO v TRAFFIC_JUMBOPLUS
The default traffic tablespaces are configured with different extent sizes so that data can be stored in the correct tablespace for the associated data growth rate. The aim is to ensure that data is stored in the database for efficient data access and data storage. Tables must be stored in tablespaces with appropriate extent sizes.
The default extent sizes that are included with a Tivoli Netcool Performance Manager system are listed in the following section. You must update the default
