Ingres for Linux
Getting Started r3
P00274-1E
This documentation and related computer software program (hereinafter referred to as the “Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by Computer Associates International, Inc. (“CA”) at any time.
This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright laws of the United States and international treaties.
Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the license for the software are permitted to have access to such copies.
This right to print copies is limited to the period during which the license for the product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to return to CA the reproduced copies or to certify to CA that same have been destroyed.
To the extent permitted by applicable law, CA provides this documentation “as is” without warranty of any kind, including without limitation, any implied warranties of merchantability, fitness for a particular purpose or noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or indirect, from the use of this documentation, including without limitation, lost profits, business interruption, goodwill, or lost data, even if CA is expressly advised of such loss or damage.
The use of any product referenced in this documentation and this documentation is governed by the end user’s applicable license agreement.
The manufacturer of this documentation is Computer Associates International, Inc.
Provided with “Restricted Rights” as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.
2004 Computer Associates International, Inc.
All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Contents
Chapter 1: Welcome! A New Era for Information Management...... 1-1 A Complete Relational Solution ...... 1-1 Open Source...... 1-2 Easy-To-Manage Environment ...... 1-3 Web Application Development ...... 1-3 Connectivity and Access in a Distributed Environment ...... 1-3 Access and Integrate Any Data ...... 1-4 Modern Solutions for a Distributed Environment ...... 1-4 Scalability and Reliability ...... 1-5 A Foundation for Business Infrastructure...... 1-5 Summary ...... 1-6 Ingres Users ...... 1-6 What You Need to Know ...... 1-7 RPM Packaging...... 1-7 Documentation Set...... 1-8
Chapter 2: Installing Ingres on Linux System Requirements ...... 2-1 Hardware Requirement...... 2-1 Software Requirements ...... 2-2 Preparing for Installation ...... 2-2 Determining Your Installation Configuration ...... 2-3 Choosing File Locations ...... 2-5 Choosing the Default or Custom Installation Method ...... 2-9 Using the Installation Worksheet ...... 2-10 Licensing Ingres ...... 2-10 Installing Ingres ...... 2-11 Using the Default Installation Method ...... 2-11 Using the Custom Installation Method ...... 2-12
Contents iii
Installing Multiple Instances ...... 2-14 Post-Installation Tasks ...... 2-15 Accessing the Instance ...... 2-15 Starting and Stopping the Instance ...... 2-16 Customizing Your Installation ...... 2-17 Preparing Your Installation for General Use...... 2-17 Enabling Recovery of Your Master Database ...... 2-17 Authorizing Users to Start and Stop Servers...... 2-17 Allowing Users to Access Tools and Databases ...... 2-18 Creating Databases ...... 2-18
Chapter 3: Configuring Ingres Grid Option Overview...... 3-1 Requirements ...... 3-2 Preparation ...... 3-2 Installing Ingres ...... 3-3 Configuring Client Applications to Access an Ingres Cluster...... 3-4
Chapter 4: Understanding the Interfaces The Ingres ODBC Driver ...... 4-1 Ingres JDBC Driver ...... 4-2 Running the Data Access Server ...... 4-2 Ingres OpenAPI ...... 4-2 Embedded SQL ...... 4-3 Ingres Web Deployment Option ...... 4-3 Developing Ingres Applications ...... 4-4
Chapter 5: Frequently Asked Questions Questions About Ingres for Linux...... 5-1
Appendix A: Tips for a Successful Implementation File Locations ...... A-1 System Files...... A-1 Database Files ...... A-1 Checkpoint, Journal, and Dump Files...... A-2
iv Getting Started
Temporary Work Files...... A-3 Transaction Log Files ...... A-3 Configuration Parameters ...... A-4 General Installation Parameters ...... A-5 DBMS Server Parameters ...... A-5 Creating an Installation Code ...... A-6 Specifying the World Region and Time Zone ...... A-6 Supported Character Sets ...... A-8 Configuration Tasks Performed During Installation ...... A-9 DBMS Server Configuration Tasks ...... A-9 Ingres Servers ...... A-10
Appendix B: Installation Worksheet Using the Worksheet ...... B-1 Installation Worksheet...... B-1
Appendix C: RPM Packages RPM Packages for Installation...... C-1
Index
Contents v
Chapter 1 Welcome!
Congratulations on selecting Ingres, the complete information management solution! Like tens of thousands of users around the globe, you will soon discover how you can develop and deploy robust, mission-critical applications in a variety of environments.
This guide provides all the information you need to make a quick and productive start with Ingres.
A New Era for Information Management
The IT requirements of most organizations have changed significantly in recent years. To keep pace with the Internet explosion, organizations must look at more than just their Web presence. A successful business must be able to integrate existing applications and data with the latest technology to gain maximum impact.
Ingres enables your organization to take advantage of the new opportunities brought by the Internet while still protecting your investment in existing applications and databases.
As hardware, operating systems, and technology standards have evolved, Ingres has kept pace with the changes and has been adapted to use the latest technology, such as multiple processors and 64-bit architecture, as well as standards such as XML and Unicode. In addition, new environments such as Windows XP, and Linux for zSeries and S/390 have been added to the already extensive list of supported platforms.
A Complete Relational Solution
The heart of the Ingres solution is the robust, high-performance relational database management system (RDBMS). On this firm foundation, you can build the best in mission-critical applications that use the advanced features and functionality now available in Ingres.
Welcome! 1–1 A Complete Relational Solution
The following sections outline what Ingres has to offer.
Open Source
As of this release, Ingres is contributed to the open source community.
The open source model provides many business and technical advantages, such as:
■ Ability to receive features more quickly
■ Ability to extend Ingres to meet specific requirements
■ Collaboration on projects
■ Building relationships with leading open source application vendors
■ More easily extending support to non-traditional or emerging platforms
■ Enhancing security by providing code that is less vulnerable to attack
Features Included
The following Ingres components are contributed to open source:
■ Ingres DBMS and associated database administration tools
■ Embedded SQL precompilers
■ Character-based querying, reporting, and application development tools
■ Connectivity components, including ODBC, JDBC, and the .Net Data Provider
■ Ingres Distributed Option
■ Ingres Replicator Option
■ Ingres Web Deployment Option
■ TP monitors including CICS, Tuxedo, and Encina
Features Not Included
The following features are not included in the open source:
■ Visual DBA suite
■ Support for spatial objects
■ B1 security
■ Advantage™ OpenROAD, Advantage™ Enterprise Access, and Advantage™ EDBC products
1–2 Getting Started A Complete Relational Solution
The Visual DBA suite and spatial object library are available for download from http://ca.com/opensource.
Easy-To-Manage Environment
Technology is becoming increasingly sophisticated, but that does not mean administration and management should become equally complicated. Ingres has long had the reputation for being easy to manage, requiring far less maintenance than the competition. Long-term cost of ownership is often forgotten when choosing a database, and Ingres is hard to beat in this area.
For more specialized management requirements, the Ingres Management Architecture (IMA) tools provide the framework to access system data for monitoring and managing installations. Using IMA, you can create system management applications using standard SQL tools and access multiple installations across Ingres Net.
Web Application Development
Ingres Web Deployment Option provides users with a secure and reliable foundation for Internet-based electronic commerce and enables businesses to take advantage of all that the Web has to offer.
Applications developed with Ingres Web Deployment Option can be used to provide full read/write access to enterprise-wide corporate data. Database- driven web sites provide much greater flexibility and can reflect changes in dynamic content as they happen.
For more information about Ingres Web Deployment Option, see the chapter “Understanding the Interfaces” and the Web Deployment Option User Guide.
Connectivity and Access in a Distributed Environment
Open connectivity has always been a priority for the Ingres community.
Ingres Net, coupled with the Ingres ODBC and JDBC drivers, let you take complete advantage of the technologies that drive the business environment. Almost every commercial application or application development system is ODBC compliant, and through this route, Ingres allows transparent access to enterprise data repositories. More importantly, applications developed in this way are independent of hardware, networking protocols, and operating systems. So with Ingres, you can integrate the entire enterprise—from PCs to mainframes.
Welcome! 1–3 A Complete Relational Solution
Whereas most commercial drivers use a slow, dynamic SQL to access Ingres, the Ingres ODBC driver uses the native API (application programming interface), effectively making ODBC a native language for Ingres.
For more information about the Ingres ODBC and JDBC drivers, see the chapter “Understanding the Interfaces.” For more information about Ingres Net, see the Connectivity Guide.
Of course, if you prefer, you can use the OpenAPI to provide access to all distributed databases and take advantage of an alternative to embedded SQL. For more information about Ingres OpenAPI, see the chapter “Understanding the Interfaces.”
Access and Integrate Any Data
Modern applications require that data from multiple sources on different platforms must be accessed in a single application. Advantage Enterprise Access products provide a common, portable, open interface across a variety of operating environments. The enterprise data access options offer solutions for full, transparent, read/write access to all existing data without changing its location or structure.
The Advantage Enterprise Access products provide a single, standard interface for both relational and pre-relational databases. Real-time access is provided for a variety of client applications running on Windows, OpenVMS, UNIX, and Linux workstations, as well as through web browsers. Popular application development tools like Microsoft Visual Basic and PowerBuilder can utilize this technology, meaning that your options are unlimited.
Databases supported include all popular UNIX or Microsoft Windows-based database management systems such as Oracle, Informix, Sybase, and Microsoft SQL Server. On the OS/390 platform, a separate product called Advantage EDBC gives the same level of access to Advantage™ CA-IDMS® Database, Advantage™ Datacom® Database, DB2, VSAM, CICS/VSAM, and IMS — so you can truly take your data from anywhere.
For more information on Advantage Enterprise Access and Advantage EDBC, visit the Computer Associates web site at http://ca.com.
Modern Solutions for a Distributed Environment
Distributed databases are becoming increasingly prevalent. The ability to manage and distribute data across many locations while still guaranteeing security and integrity is essential. Ingres enables users to work in a distributed environment that is simple to manage, is easy to customize, and provides fault- tolerant data replication with total integrity.
1–4 Getting Started A Complete Relational Solution
Ingres Distribution Option supports distributed databases across a wide variety of hardware, software, and networking architectures. Regardless of whether the data resides on desktops, mainframes, or anything in between, Ingres Distributed Option enables you to treat all your enterprise data as a single, global Ingres database. For more information, see the Distributed Option User Guide.
Ingres Replicator Option now provides better fault-tolerant data replication and guaranteed data integrity than ever before. By operating through its own server, its performance is enhanced.
Two-way replication allows your business to carry on when the network link is down. This process holds the data and completes the replication as soon as the network becomes available. Data is readily available to users at anytime or anywhere, and can be administered using the enhanced graphical user interface (GUI) of Visual DBA. For more information about Ingres Replicator Option, see the Replicator Option User Guide.
For more traditional environments, the Ingres character-based tools including Embedded SQL and Vision are available. With additional platform-specific, TP monitoring, and UNIX cluster support options, Ingres can provide the integrity and reliability you need in a distributed environment by ensuring that transactions do not get lost or damaged. Embedded SQL programming kits are available for C, COBOL, Fortran, and several other 3GLs. For more information about Embedded SQL, see the chapter “Understanding the Interfaces” in this guide and the Embedded SQL Companion Guide.
Scalability and Reliability
The Ingres Grid Option on Linux provides support for Linux Cluster environments. Ingres exploits cluster file systems such as Oracle Cluster File System (OCFS), and OpenDLM Distributed Lock Manager (DLM) based on the AIX DLM released by IBM to the open source community. This support gives you the ability to achieve scalability and reliability on a low-cost clustering platform.
A Foundation for Business Infrastructure
Ingres is the foundation on which many mission-critical applications have been built. A fundamental requirement for any business venture is to function reliably while ensuring data integrity. This requirement calls for applications of the highest order that can reliably support all aspects of business processing. The inherent robustness and reliability of Ingres make it an ideal choice of a database engine for building these critically important applications upon which you can confidently bet your business.
Welcome! 1–5 Ingres Users
Ingres underpins many of the Computer Associates solutions that manage global businesses. In addition to being present in the newest breed of Computer Associates applications for use in CRM, Mobile, B2B, B2C, and XSP environments, Ingres can be found in a number of possibly unexpected places such as X-ray machines, flight-deck control systems, air-traffic control systems, telephone switches, and military command and control systems.
The common denominator in all of these applications is the requirement for a low cost, resilient, reliable, mission critical database engine that requires minimum maintenance while delivering maximum performance and availability. Wherever Computer Associates Infrastructure Management tools require a relational database, you will find Ingres at their heart.
Our confidence in Ingres and our commitment to its future is demonstrated by the standardization of Ingres as the underpinning database technology for many Computer Associates flagship products.
Summary
Ingres has made great strides to give you the power and flexibility that modern applications dictate. Many businesses still depend on a more traditional type of application, and these applications must be capable of coexisting with the latest technology. Ingres ensures that you can use the best of both worlds.
You can find out more from the Ingres online documentation, or by visiting the Computer Associates web site at http://ca.com.
Ingres has never been in better shape, and we are working hard to make it even better. For every business, you can be sure that with Ingres as the foundation for your applications, you could not have made a better choice.
Ingres Users
Ingres is designed for a wide variety of users, from application developers and database management experts, to users with little computer experience. Although an individual can fill more than one of the functions described here, Ingres users include four basic types:
■ System Administrator—The system administrator is responsible for general Ingres operations and for designating who can use Ingres. See your system administrator for information about obtaining access to Ingres.
1–6 Getting Started What You Need to Know
■ Database Administrator—A database administrator is responsible for one or more Ingres databases. The database administrator creates and maintains the database, ensuring that the data is accurate and protected and that only approved users have access to the data. See your database administrator for specific information about your databases.
■ Application Developer—An application developer uses Ingres tools to create customized applications.
■ User—A user (sometimes referred to as an end user) runs an Ingres or customized user application to examine or update data in an Ingres database.
The Ingres user interfaces include tools for all these types of users.
What You Need to Know
This guide is intended for all Ingres users, including the system administrator, the database administrator, application developers, and users. Some chapters assume you are already familiar with:
■ Basic programming concepts
■ Basic relational DBMS concepts
To follow the instructions in this guide, you must have a working knowledge of operating system management or be in close contact with the operating system administrator. You must also be familiar with the windowing system on the target platform of the installation, including terminology, navigational techniques, and working with standard items, such as menus and dialogs.
Note: Some procedures in this guide require operating system privileges (or permissions). If you do not have these privileges and the operating system expertise associated with them, have the operating system administrator perform these tasks.
RPM Packaging
Ingres for Linux r3 is distributed as a collection of Red Hat Package Manager (RPM) packages. For more information on RPM, see rpm.org, your UNIX man page, or your Linux info program.
Welcome! 1–7 Documentation Set
Documentation Set
The documentation package for Ingres for Linux installs into a specific directory (usr/share/doc) and can be easily accessed from the desktop. A link to the documentation is created for all Ingres for Linux r3 installations.
1–8 Getting Started
Chapter 2 Installing Ingres on Linux
This chapter provides system, product, and pre-installation requirements for installing Ingres on Linux and guides you through the installation process. It then discusses post-installation requirements and tasks.
System Requirements
Ingres for Linux requires the following hardware and software.
Hardware Requirement
Disk space and memory requirements are dependent upon a number of factors, such as number of users, size of the transaction log file, number and size of databases, and so on.
Ingres has the following hardware requirements and recommendations:
Element Typical Requirements Number of disks At least two separate storage devices for your databases and checkpoint files are strongly recommended (see Choosing File Locations in this chapter). Disk space The amount of space required on any one particular disk is determined by the number of disks in your configuration, the packages you are installing, and the locations you choose for your files (see Choosing File Locations in this chapter). The default file size for your primary and backup transaction log files is 32 MB. However, the recommended size is between 100 and 400 MB, or even larger.
Installing Ingres on Linux 2–1 Preparing for Installation
Element Typical Requirements For help in determining space requirements for II_DATABASE, II_CHECKPOINT, II_JOURNAL, II_DUMP, and II_WORK, see the Database Administrator Guide. Physical memory 256 MB is the recommended minimum for a DBMS Server installation. 512 MB or more is preferred.
Software Requirements
The required operating system is any Linux with glibc 2.2 or 2.3, and kernel 2.4. Red Hat Enterprise Linux 3 or SUSE Linux Enterprise Server (SLES) 8 is recommended.
Red Hat Package Manager (RPM) 4.1.1 or higher is required to install Ingres for Linux.
Preparing for Installation
After verifying your system requirements, you are ready to prepare your system for installation. The basic steps are summarized below, and then discussed in detail subsequently:
■ Determine your installation configuration and the RPM packages to be installed.
■ Choose file locations.
■ Choose the default or custom installation method.
■ Complete the Installation Worksheet, indicating the Ingres components you want to install.
Note: Make sure you thoroughly understand the issues regarding system resources, storage locations, and other configuration parameters before installing Ingres. If you are not sure, have someone more knowledgeable in these areas perform the following tasks.
2–2 Getting Started Preparing for Installation
Determining Your Installation Configuration
An Ingres installation consists of a set of product components that share a unique system-file location, ownership, and installation code (II_INSTALLATION).
You can configure an installation in many ways, depending on the packages you install and the parameters you set. For example, you can configure an installation as a stand-alone system or as a client that accesses databases on a remote DBMS Server installation. A network may contain many different types of Ingres installations.
The configuration is determined by the packages you install. The major configuration options and their corresponding RPM packages are described in the next section.
The RPM packages available to install are listed in the appendix “RPM Packages.”
The base package, ca-ingres, is a prerequisite for all other packages and must be installed prior to, or at the same time as, the other packages.
Major Configurations
The following table describes the major configurations and their corresponding RPM packages.
Package to Install Configuration Option Description Stand-alone installation An installation that only provides local access to local ca-ingres databases. It includes the Name Server and DBMS ca-ingres-dbms Server, and has its own set of Ingres tools. It does not include a Communications Server. Networked DBMS An installation that lets remote clients access its ca-ingres Server installation databases through a network. (If Ingres tools are ca-ingres-dbms installed, local users also can access its databases). It contains a Name Server, Communications Server, ODBC ca-ingres-net driver, and JDBC driver. ca-ingres-jdbc ca-ingres-odbc ca-ingres-das
Installing Ingres on Linux 2–3 Preparing for Installation
Package to Install Configuration Option Description By installing Ingres tools and then modifying the connection data, you can add outgoing client capabilities to a networked DBMS Server installation. This enables it to act both as a client of a remote DBMS Server and as a DBMS Server to its own remote clients. (For more information about defining connection information for vnodes, see the Connectivity Guide.) Networked DBMS with An installation that allows access to multiple databases— ca-ingres Ingres Distributed local and remote, Ingres and non-Ingres— ca-ingres-dbms Option simultaneously. In addition to Star, it contains a Name Server, Communications Server, ODBC driver, and JDBC ca-ingres-esql driver. It may also contain Ingres tools. ca-ingres-jdbc ca-ingres-net ca-ingres-das ca-ingres-star Client installation An installation that has its own set of Ingres tools and ca-ingres accesses databases on a networked DBMS Server ca-ingres-net installation on a remote node. A client-only installation consists of a Name Server, Communications Server, ca-ingres-jdbc ODBC and JDBC drivers, and Ingres tools. It does not ca-ingres-das contain a DBMS Server. ca-ingres-odbc You can configure a networked DBMS Server installation as a client of another DBMS Server on a remote node. To do so, install Ingres tools on the DBMS Server, and then add client capabilities by using netutil (or the Ingres Network Utility or Visual DBA GUI tools). Although you can set up a client in a non-Linux environment to access an Ingres database in a Linux environment, that is beyond the scope of this guide. (For more information, see the Connectivity Guide.)
In addition, the following components and development tools can be added:
Component or Tools Package Applications-By-Forms ca-ingres-abf Ingres Bridge ca-ingres-bridge C2 Security ca-ingres-c2audit
2–4 Getting Started Preparing for Installation
Component or Tools Package Embedded SQL precompilers ca-ingres-esqlc Ingres Web Deployment Option ca-ingres-ice Querying and reporting tools ca-ingres-qr_run Ingres Replicator Option ca-ingres-rep Tuxedo ca-ingres-tuxedo Vision forms-based application development tools ca-ingres-vision
After performing the initial installation, you can install other packages later to add more capabilities to your installation. For example, you can add networking capabilities to a stand-alone installation that is connected to a network. Alternatively, you can add client capabilities to a networked DBMS Server installation.
Choosing File Locations
This section presents some guidelines for choosing file locations and instructions on how to specify them. For example, use the disk configuration information in the following sections to help you decide on locations for the system (executable) files for Ingres and Ingres tools.
Note that installer-defined directory is a location chosen by the installer. In the installer-defined directory, the install program creates an appropriate directory tree in which it stores the appropriate files. (The appendix “Installation Worksheet” lists the locations you must specify.)
When specifying a file location, use only the path name for the installer-defined directory at the top of the directory tree. Do not include the subdirectories that the install program creates within the installer-defined directory. (For more information about file locations, see File Locations in the appendix “Tips and Tricks for a Successful Implementation.”)
Warning! We strongly recommend that you do not use ReiserFS for database locations. Severe performance degradation was noticed when using this file system.
Installing Ingres on Linux 2–5 Preparing for Installation
DBMS Server Disk Configurations
The following examples illustrate some typical disk configurations for a stand- alone or networked DBMS Server installation.
Tip: To avoid a single point of failure, you should set up at least a two-disk installation. Configurations with three or more disks can provide better performance and additional data recovery options. Although you can put all files on a single disk, you are strongly advised against doing so, because you could lose all of your data if the disk fails.
For any server configuration, you can set up an optional backup transaction log device on a separate disk from the primary transaction log. This setup enables recovery of unsaved, committed transactions if the primary transaction log device fails.
Four-Disk System A configuration with four or more disks provides the best performance and recovery options. For best performance, configure your system with the operating system on a separate disk and your Ingres files on three or more other disks, as described for a three-disk system. If possible, put your backup transaction log on a separate disk from both your database and primary transaction log. Also, you can use more than one disk partition for your transaction log.
Three-Disk System The following three-disk configuration provides better performance and recovery than a two-disk system: Disk 1—Operating system, checkpoint, journal, and dump files Disk 2—Product system files, transaction log, and work files Disk 3—Databases
2–6 Getting Started Preparing for Installation
Your backup transaction log can reside on either Disk 1 or Disk 3, as indicated by the oval surrounding its directory tree and the parentheses around the log_file and dual_log configuration parameters in the following diagram:
(dual_log)
Disk 1
inst.-def. dir._DUAL II_CHECKPOINT II_JOURNAL inst.-def. dir. ingres II_DUMP log ingres dual_log.l01 (secondary log file) ckp jnl dmp
default default default iidbdb mydb iidbdb mydb iidbdb mydb
chkpts chkpts jrnls jrnls dump files dump files
(log_file)
Disk 2
inst.-def. dir.
II_SYSTEM inst.-def. dir. ingres II_WORK log ingres ingres_log.l01 work (primary log file) bin system files default createdb (etc.) iidbdb mydb
work files work files
(dual_log)
Disk 3 inst.-def. dir._DUAL
ingres II_DATABASE inst.-def. dir. log ingres dual_log.l01 (secondary log file) data
default iidbdb mydb
db files db files
Installing Ingres on Linux 2–7 Preparing for Installation
You can recover databases and committed transactions if Disk 3 fails. If Disk 2 fails, you can recover your committed transactions if you have a backup transaction log; if you have no backup log, you will lose committed transactions that have not been written to the database.
Two-Disk System In a two-disk system, shown next, all Ingres files reside on Disk 1, except databases and an optional backup transaction log file, which reside on Disk 2. This system allows recovery of databases and committed transactions if Disk 2 fails. However, if Disk 1 fails and you do not have a secondary log device, you will lose unsaved, committed transactions.
(log_file)
II_SYSTEM Disk 1 II_WORK inst.-def. dir. II_CHECKPOINT II_JOURNAL ingres II_DUMP inst.-def. dir. log ingres work ingres_log.l01 (primary log file) bin default system createdb (etc.) jnl iidbdb mydb files work files default work files ckp dmp iidbdb mydb default default jrnls jrnls iidbdb mydb iidbdb mydb
chkpts chkpts dump files dump files
(dual_log)
Disk 2
inst.-def. dir._DUAL
II_DATABASE inst.-def. dir. ingres
log ingres dual_log.l01 (secondary log file) data
default iidbdb mydb
db files db files
2–8 Getting Started Preparing for Installation
One-Disk System A single-disk system is a high-risk setup and is not recommended. Because all files reside on one disk, as shown below, you could lose all your data if the disk fails. You should checkpoint to magnetic tape on single-disk systems.
Note: The default installation method installs Ingres as a one-disk system.
(log_file)
II_SYSTEM Disk II_WORK inst.-def. dir. II_CHECKPOINT II_JOURNAL ingres inst.-def. dir. II_DUMP II_DATABASE log ingres ingres_log.l01 bin (primary log file)
createdb (etc.)
system files
ckp data
default default mydb iidbdb mydb iidbdb work chkpts db files db files chkpts jnl default dmp mydb default iidbdb iidbdb mydb default work files work files mydb jrnls jrnls iidbdb dump files dump files
Choosing the Default or Custom Installation Method
You must choose one of two installation methods:
■ Default—The default installation method uses default configuration parameter settings, and installs Ingres on one disk.
■ Custom—The custom installation method lets you customize the configuration parameters.
The following table compares the default and custom installation methods:
Task Default Custom Defining installation Default. User-defined. parameters The value for II_TIMEZONE_NAME will be You can customize them to NA-PACIFIC until you change it using what you want. ingsetenv. For instructions, see Customizing Your Installation in this chapter.
Installing Ingres on Linux 2–9 Preparing for Installation
Task Default Custom Upgrading from a previous Your installation is upgraded, but your You can choose to upgrade release databases are not. You must run upgradedb your databases. to upgrade your databases after the installation is complete. (For details, see the Database Administrator Guide.) Specifying file locations Automatic. User-defined. All files are put in the default directory of You specify where you want II_SYSTEM on one disk. files to be located, up to four or more different disks. For Note: If you have all your files on one disk more information, see and you have a disk failure, you could lose Choosing File Locations in data. this chapter. Specifying the installation Default, which is II. User-defined. code Note: If you have more than one installation You specify the installation on the same node, they cannot have the same code. installation code.
Using the Installation Worksheet
Before installing Ingres and Ingres tools, make a copy of the blank Installation Worksheet (provided in the appendix “Installation Worksheet”) for each instance you intend to create. Then fill in values for the required general and DBMS Server parameters. When done, keep the completed list with this guide in a safe, accessible place for future reference.
Licensing
Before installing Ingres, make sure you agree to the terms of the Computer Associates open source license.
Run the license agreement, CATOSL. The agreement is in the root of the CD- ROM or downloaded with the Ingres RPM packages. Issue this command: ./ingres-CATOSL
Read the license agreement and accept it. If you do not accept it, the installation process will fail.
2–10 Getting Started Installing Ingres
Installing Ingres
You must install Ingres using either the default or custom installation method. This section describes both.
Using the Default Installation Method
The default installation method installs the product on one disk using the default configuration settings.
Note: Before running the install program, make a complete backup of your system.
This procedure transfers all pertinent files from the distribution medium to the II_SYSTEM location for your Ingres instance on this node.
By default, the II_INSTALLATION variable is set to II, and all the others default to the value of II_SYSTEM.
The default installation method installs the specified Ingres packages under /opt/CA/IngresII, where II is the default value specified in II_INSTALLATION. This directory will also be the value of II_SYSTEM.
In addition to creating a system directory, it creates an operating system user and a system group, both with the default name “ingres,” if needed.
Installing the Software
The base package, ca-ingres, is a prerequisite for all other packages and must be installed prior to, or at the same time as, the other packages. For a list of available packages and full package names, see the appendix “RPM Packages.”
To install a single package, invoke RPM with the appropriate installation flags, including the full path to the package you want to install, as follows: rpm –Uvh
To install more than one package at a time, pass multiple file names, specifying the full path to each package, as follows: rpm –Uvh
To install all packages in the same directory, specify the following: rpm –Uvh
Installing Ingres on Linux 2–11 Installing Ingres
Choosing a Different Installation Location
To install a package with an II_SYSTEM value other than the default, use the – prefix flag when invoking RPM. The following command will install the specified package with II_SYSTEM=/home/ingres/IngresII: rpm –Uvh –-prefix=/home/ingres/IngresII
Note: All packages installed in a single installation must have the same value of II_SYSTEM. If you use the prefix flag to install the base package, you must install all subsequent packages with the same –prefix value.
Using the Custom Installation Method
The custom installation method lets you change the instance identifier, file locations, and other configuration parameters for the instance.
Specifying Configuration Parameters
For a complete description of parameters available for configuration, see Configuration Parameters in the appendix “Tips for a Successful Installation.” The parameters are also listed on your “Installation Worksheet.”
You can use the following methods to override the installation default values:
■ Set environment variables before installation.
■ Create a response file.
Setting Environment Variables Before Installation
The first way to override installation defaults is to set environment variables before installing. These values are then used during the installation process.
For example, to have II_INSTALLATION set to A1 instead of II, simply set an environment variable of the same name before installing, as follows: For bash: export II_INSTALLATION=A1 For tcsh: setenv II_INSTALLATION A1
Creating a Response File
The second method is to create a response file that defines the desired values, which are then used during the installation process. You can use any name for the response file.
2–12 Getting Started Installing Ingres
Each entry in the response file should be on a separate line and of the form:
Next, set the environment variable II_RESPONSE_FILE to point to the file you created, using the absolute path and file name, as follows: For bash: export II_RESPONSE_FILE=
Note: The response file must be in a directory that is globally readable or the install process will fail.
Response File Examples
Examples of response files are shown here.
Two-Disk System The following response file shows Ingres installed on two disks, as follows:
■ Disk 1—System files, checkpoint, journal, work, and dump locations, and transaction log
■ Disk 2—Databases and backup transaction log
The machine has one CPU, is located in Tokyo, and requires the shiftjis character set.
Note: As the checkpoint, journal, work, dump, and transaction log locations all reside with the system files, you do not need to specify a location because the default location is II_SYSTEM.
The response file for this configuration is as follows: II_DATABASE=/disk2 II_DUAL_LOG=/disk2 II_TIMEZONE_NAME=JAPAN II_CHARSET=shifjis
Four-Disk System The following response file shows Ingres installed on four disks, as follows:
■ Disk 1—Checkpoint, journal, and dump locations
■ Disk 2—System files, transaction log, work files
■ Disk 3—Databases
■ Disk 4—Backup transaction log
The machine has two CPUs, requires a 500 MB transaction log, and is located in New York. You want the database to comply with the ANSI/ISO Entry SQL-92 standard.
Installing Ingres on Linux 2–13 Installing Ingres
The response file for this configuration is as follows: II_DATABASE=/disk3 II_CHECKPOINT=/disk1 II_JOURNAL=/disk1 II_DUMP=/disk1 II_WORK=/disk2 II_LOG_FILE=/disk2 II_DUAL_LOG=/disk4 LOG_KBYTES=500000 II_NUM_PROCESSOR=2 II_TIMEZONE_NAME=NA-EASTERN SQL92=ON
Installing the Software
After you have specified configuration parameters using either of the above methods, you install the RPM packages, as described in Installing the Software under the Using the Default Installation Method section in this chapter.
Installing Multiple Instances
You can have more than one installation on the same computer. Each installation on that computer must have a unique installation code. For example, you can install and run Ingres 3 and Ingres tools under one installation code, while maintaining an existing 2.6 or 2.5 installation under a different installation code.
Tip: Do not delete or alter any files that the install process places into the $II_SYSTEM/ingres directory and its subdirectories. Also, do not place any user files or directories into this directory and its subdirectories. Lastly, do not alter the permissions on this directory and its subdirectories or on any files in this directory structure. Doing so compromises the security and integrity of your databases.
RPM does not allow multiple instances of the same package on one machine. To allow multiple Ingres instances on one machine, you must have a unique set of package names for each instance you want installed.
To do this, you must rebuild each RPM package to include an installation ID that is unique to the machine. Use the iirpmrename command.
For example, to rebuild the base package to use an II_INSTALLATION of XX, run: iirpmrename
2–14 Getting Started Post-Installation Tasks
This creates a new RPM package in the current working directory called Ingres- XX-3.0.0404-1.i586.rpm.
You can then install this package using the instructions described in Using the Default Installation Method in this chapter. The package will install with II_SYSTEM=/opt/CA/IngresXX and II_INSTALLATION=XX.
Note: While you can still override the value for II_INSTALLATION using the response file or other methods mentioned above, we do not recommend it.
Post-Installation Tasks
This section describes how to access the newly installed instance and how to start and stop Ingres.
Accessing the Instance
When the installation is complete, an environment file is written to the home directory of the operating-system user ID defined during installation (the default is “ingres”). The name of the environment file is dependent on II_INSTALLATION.
The following examples assume an operating system user ID of ingres. For bash: /home/ingres/.ingXXbash For tcsh: /home/ingres/.ingXXtcsh where XX is the installation ID of the installation environment.
When the installation is complete, the instance will be running. To access your installation, you must source the environment file that was created during installation.
The following examples assume an operating-system user ID of ingres. For bash: ./home/ingres/.ingXXbash For tcsh: source /home/ingres/.ingXXtsch where XX is the installation ID of the instance.
Installing Ingres on Linux 2–15 Post-Installation Tasks
For other users to have access to the instance and the Ingres tools, they must have access to the above scripts. The scripts can be copied to the home directory of any user.
Starting and Stopping the Instance
After you have installed Ingres, the instance is running.
To stop the instance: 1. Make sure you are logged on to your system through the Ingres system administrator account for the instance. 2. Shut down any components that are running, using the following command: % ingstop
To start the instance: 1. Make sure you are logged on to your system through the Ingres system administrator account for the instance. 2. If necessary, shut down any components of the instance that are running currently, using the following command: % ingstop 3. Enter the following command to start your installation: % ingstart The ingstart command performs the following tasks:
■ Checks that you have sufficient operating system resources to run the Ingres components you have installed; if not, ingstart issues an error message and exits.
■ Starts all servers that are part of your installation. (For descriptions of server types, see Ingres Servers in the appendix “Tips for a Successful Implementation.”)
If ingstart fails due to insufficient resources, see System Requirements in this chapter or information in the System Administrator Guide.
2–16 Getting Started Customizing Your Installation
Customizing Your Installation
The configuration installed by RPM is suitable for moderate hardware (about 512 MB of memory) and a moderate number of users (about 32). If you want to further customize your installation, you may need to change default values for some configuration parameters to suit your particular needs or enhance performance.
To view or change the default values for these or other configuration parameters in your installation, use the CBF utility or the ingsetenv command. For example, use CBF to change the size of the transaction log file or to edit the number of concurrent users. Some changes, such as those to the logging system, cannot, or should not, be made while the DBMS Server is running. Any change made with CBF while servers are running is not effective until you restart the servers. For more information about using the CBF utility or the ingsetenv command, see the System Administrator Guide and the Command Reference Guide, respectively.
For information about DBMS Server or Ingres Distributed Option configuration options, see the System Administrator Guide and the Distributed Option User Guide.
Preparing Your Installation for General Use
You will need to complete some or all of these additional tasks so that your users can access and use the new installation:
■ Enable recovery of your master database.
■ Authorize users to start and stop servers.
■ Allow access on systems using shadow passwords.
■ Allow users to access tools and databases.
■ Create or upgrade databases.
Enabling Recovery of Your Master Database
To help recover your master database (iidbdb) if it becomes corrupted, make sure iidbdb has been checkpointed and that journaling has been enabled. This is the automatic default. For details, see the Database Administrator Guide.
Authorizing Users to Start and Stop Servers
If you plan to have users other than the system administrator start and stop the Ingres servers, you need to edit the config.dat file. For details, see the System Administrator Guide.
Installing Ingres on Linux 2–17 Preparing Your Installation for General Use
Allowing Users to Access Tools and Databases
To enable users to access Ingres tools and Ingres databases, the system administrator must:
■ Edit the user login files to facilitate user access to the Ingres tools needed to query the databases
■ Authorize users to access specific databases, using the accessdb command or create user statement
For more information, see the System Administrator Guide.
Authorizing Database Access
The install process identifies only the owner of the system administrator account to your installation, to permit authorized access to the databases. To authorize database access for other users, use the accessdb command or the create user statement, as described in the Command Reference Guide.
Creating Databases
For each new installation, someone must create the needed databases using the createdb command, as described in the Database Administrator Guide. Only the user databases need to be created; the iidbdb master database is created during installation.
2–18 Getting Started
Chapter 3 Configuring Ingres Grid Option
This chapter describes requirements for the Ingres Grid Option on Linux and how to install and configure it.
Overview
Ingres Grid Option is a variation of a typical Ingres installation in which Ingres runs simultaneously on multiple host machines to provide cooperative and transparent access to one or more databases. Use of the Ingres Grid Option requires specialized hardware and third-party software, and is incompatible with the following Ingres features:
■ Row-level locking
■ Update mode locks
■ Online checkpoints
■ Two-phase commit (2PC)
■ Replication
■ C2 auditing
Ingres is installed in the typical manner, except most file locations must be on cluster file systems—that is, file systems using hardware and software that allow safe simultaneous update access from all machines intended to be part of the cluster. Certain other locations must not be on cluster file systems if the file system supports only block-oriented data transfer (for example, Oracle Cluster File System).
Once installed, you run the iimkcluster utility to convert the initial installation into one of the cluster members (nodes), and the iisunode utility to add more nodes.
Client applications access individual cluster members (if run locally, or if a virtual node (vnode) is defined for only one cluster member), or any cluster member, or a select subset of cluster members if the vnode used to access the cluster defines multiple network addresses.
Configuring Ingres Grid Option 3–1 Requirements
At each step, make sure that Ingres, and the applications using Ingres, perform as expected. Certain of the restrictions on lock granularity and available lock modes are handled internally by Ingres, but may result in increased contention or deadlocks.
Requirements
Before installing Ingres Grid Option on Linux, make sure you have the following:
■ A hardware cluster in which multiple machines can share the same physical storage. This cluster may take the form of a Storage Area Network (SAN), shared 1394b/“Firewire” drives, or shared Small Computer Systems Interface (SCSI) drives.
■ Cluster file system software to allow simultaneous update access to the shared storage from multiple machines. An example is Oracle Cluster File System (OCFS).
■ A coordinated set of open source software that allows the coordination of these resources, and has been tested with Ingres Grid Option. You can download this software from the Computer Associates Technical Support web site, accessible from http://ca.com.
Preparation
1. Check the Computer Associates Technical Support web site for the latest cluster installation procedures and supported hardware and software. Download the required software.
2. Install any required non-Ingres cluster support software, and perform the procedures recommended by the provider for verifying correct installation.
3. Plan your storage location layout as described for a stand-alone Ingres installation, with the restriction that your data (II_DATABASE), transaction log (II_LOG_FILE, II_DUAL_LOG), checkpoint (II_CHECKPOINT), journal (II_JOURNAL), and dump (II_DUMP) locations must all reside on a cluster file system.
3–2 Getting Started Installing Ingres
Certain cluster file systems (for example, OCFS) restrict support to file operations involving fixed-size transfer units and do not support the use of these file systems for general use. In these cases, do not locate II_SYSTEM and the work directory (II_WORK) on a cluster file system device. If you have this type of cluster file system, II_SYSTEM and II_WORK can be installed on any storage available to all the cluster nodes. Such storage might reside on a Network Access Server (NAS), or be provided by a Network File System (NFS) mount point, or a SAN device running a general purpose non- clustered file system. In each case, the directory paths to all the locations must be the same from each node in the Ingres cluster.
Installing Ingres
Follow these steps to install Ingres and configure the Ingres Grid Option: 1. Install Ingres in a stand-alone configuration using the locations decided upon under Step 3 in Preparation in this chapter. 2. Verify that the stand-alone Ingres installation operates correctly. Typically, it is easier to resolve any configuration issues at this stage because only one machine is in use. In addition, aside from the cluster file system support, Ingres is using operating system software only. 3. When you are confident that the stand-alone Ingres is operating correctly, shut down the installation. As the user that owns the installation, execute the iimkcluster utility, as follows: iimkcluster The utility prompts you for a node number and a nickname. Node numbers are unique integers in the range 1 through the maximum supported cluster members for your platform (currently 16). During a partial cluster failure, the surviving cluster member (node) with the lowest node number is responsible for recovering transactions on behalf of the failed nodes, so you should assign low numbers to the more powerful machines in the cluster. The nickname is an optional simple alias, which you can use in any context in which you could specify a nodename parameter. The nickname appears in the error log in lieu of the machine name. The iimkcluster utility renames the transaction logs and certain diagnostic log files (iircp.log, iiacp.log, and so on) by appending the host name of the machine on which the cluster member is running. Also created is a sub- directory in the $II_SYSTEM/ingres/files/memory directory with the name of the host machine, as well as directory $II_SYSTEM/ingres/admin/hostname to which the symbol.tbl is relocated.
Configuring Ingres Grid Option 3–3 Configuring Client Applications to Access an Ingres Cluster
This step keeps entities that are normally operated upon by only one node separate from corresponding objects that will be created by the other nodes. 4. Restart Ingres. Confirm that all processes have started. Confirm the initial node is operational by performing a few sanity checks such as creating and destroying a scratch database. You should also perform application testing to confirm that certain Ingres Grid Option restrictions, such as lack of support for row-level locking, will not impact the usability of your applications. 5. Shut down Ingres. 6. For each additional cluster member (node), run the iisunode utility, as follows: iisunode The utility prompts you for a unique node number and nickname. Once entered and confirmed, iisunode does the following:
■ Adds the same directories for the new node as iimkcluster created for the initial node
■ Duplicates the configuration information from the initial node
■ Creates a private symbol.tbl file based on the initial nodes symbol.tbl file.
■ Creates the transaction logs for this node 7. Start Ingres individually on each node, and verify correct operation.
Configuring Client Applications to Access an Ingres Cluster
Applications can access Ingres configured for Ingres Grid Option by using any of the following methods:
■ Running directly on one of the cluster member machines
■ Connecting directly to a specific cluster member using a vnode defined with the network address of the cluster member
■ Selecting a connection to any available member of the cluster, or a subset thereof, by using a vnode defined with multiple network addresses
For information on setting up vnodes, see the Connectivity Guide.
3–4 Getting Started
Chapter 4 Understanding the Interfaces
Ingres provides several tools for interfacing with the database. These include:
■ Ingres ODBC driver
■ Ingres JDBC driver
■ Ingres OpenAPI
■ Embedded SQL
■ Ingres Web Deployment Option
This chapter gives an overview of each tool and explains where to find more information in the Ingres guides.
The Ingres ODBC Driver
The Ingres ODBC driver is compliant with Microsoft Open Database Connectivity (ODBC) interface specifications. ODBC is a specification for an application programming interface (API) that enables applications to access multiple database management systems using the SQL language.
ODBC permits maximum interoperability—a single application can access many different database management systems. This enables an ODBC developer to develop, compile, and deploy an application without targeting a specific type of data source. Users can then add the database drivers that link the application to the database management systems of their choice.
The Ingres ODBC driver is installed during the installation process. It includes the Ingres ODBC Call-level Interface (CLI), which provides access to the ODBC application environment without the need to use a third-party driver manager. The Ingres ODBC driver is supported on all platforms on which Ingres runs.
For important information and a free download of the latest version of the Ingres ODBC driver, see the Computer Associates web site, http://ca.com.
For more information on the Ingres ODBC driver, including supported functions and how to configure and connect to a data source, see the Connectivity Guide.
Understanding the Interfaces 4–1 Ingres JDBC Driver
Ingres JDBC Driver
The Ingres JDBC product includes three units:
■ Data Access Server (DAS)
■ JDBC driver
■ Information utility
The Ingres JDBC driver is a pure Java implementation of the JDBC 3.0 API released with the Sun Java SDK version 1.4. The driver supports application, applet, and serlet access to Ingres data sources through the Data Access Server (DAS).
The information utility, JdbcInfo, loads the Ingres JDBC driver and displays its internal release information.
Running the Data Access Server
The Ingres DAS is started and stopped using the standard installation startup and shutdown commands.
You can also stop the server using the following command: iigcstop addr
To obtain the server address, use the IINAMU utility and issue the following command: show dasvr
For more information on the Ingres JDBC driver, see the Connectivity Guide.
Ingres OpenAPI
Ingres OpenAPI is a C programming language interface for accessing an Ingres database. It enables you to develop applications using a set of functions that are called directly with normal function-call facilities. This interface provides an alternative to embedded SQL, which requires a preprocessor in addition to a C compiler.
4–2 Getting Started Embedded SQL
For more information, see the OpenAPI User Guide, which provides:
■ Requirements for creating an Ingres OpenAPI application
■ A description of the header files, library, and environment variables used by an Ingres OpenAPI application
■ How to use the synchronous and asynchronous sample code included with the Ingres OpenAPI product
Embedded SQL
The term embedded SQL (ESQL) refers to SQL statements embedded in a host language such as C or Fortran. The ESQL statements include most interactive SQL statements, plus statements that fulfill the additional requirements of an embedded program.
All ESQL statements must be processed by the ESQL preprocessor, which converts the ESQL statements into host-language source-code statements. The resulting statements are calls to a runtime library that provides the interface to Ingres. After the program has been preprocessed, you must compile and link it according to the requirements of the host language.
For more information, including details about using ESQL with a particular host language and instructions on compiling and linking, see the Embedded SQL Companion Guide. You can also see the SQL Reference Guide, which describes ESQL independently of any host language.
Ingres Web Deployment Option
The Ingres Web Deployment Option provides the foundation for Internet-based electronic commerce. It enables a Web client to retrieve data from or update an Ingres database.
You can specify actions to perform in your Web application using special HTML variables defined by the Web Deployment Option. For example, there are variables to:
■ Execute dynamic SQL statements.
■ Run Ingres database procedures.
■ Run Report-Writer reports.
■ Run client applications.
Understanding the Interfaces 4–3 Developing Ingres Applications
A page generated by setting HTML variables can contain data from only a single SQL statement. When you need data from more than one statement, you can create Web Deployment Option Macro XML documents. A macro document contains one or more special tags that define an SQL statement to be executed. Macro XML allows you to create Web pages that include data from several database tables and provides many formatting options that control the way the data is presented to the Web client.
Additionally, the Web Deployment Option provides macro tag extensions for use with an XML-aware editor, so that adding XML elements to your documents is easier than ever. You can simply point and click to automatically generate macro syntax within your working environment. For more information, see the Distributed Option User Guide.
Developing Ingres Applications
Ingres provides an extensive set of application development tools, which include:
■ Vision
■ Application-By-Forms (ABF)
■ Visual Forms Editor (VIFRED)
■ Forms Runtime System (FRS)
For information on these tools, see the Forms-based Application Development Tools User Guide.
4–4 Getting Started
Chapter 5 Frequently Asked Questions
This chapter answers common questions about Ingres for Linux. It provides, at a glance, valuable information to further your knowledge about your new software.
Questions About Ingres for Linux
Question: Linux provides multiple sh-type shells. Which should I use with Ingres? Answer: On Linux systems the file /bin/sh is a link to a shell such as bash, ash, ksh, or zsh. This shell is invoked when a Bourne shell script is run. Ingres was developed and tested on a Linux system using GNU bash, version 2.05b-50. Limited, successful testing has also been done with the ksh and zsh shells.
Question: I am having trouble creating databases with the createdb program; the program is issuing strange error messages. Why? Answer: Make sure that you are not running the “createdb” program that is provided by PostgreSQL. Make sure that the PATH setting for the shell from which you install and start Ingres includes Ingres executable directories before other executable directories.
Question: Where are function keys PFK1 through PFK4 on my PC keyboard? Answer: Although key bindings and terminal settings vary with equipment and with character sets, the following should work if you are running Ingres on a Linux console in vt100 mode. Set TERM to vt100 and set TERM_INGRES to vt100f. The keys PFK1 through PFK4 should be bound to the top row of the numeric keypad.
Question: How can I map function keys PFK1 through PFK4 for an xterm? Answer: Running Ingres in an xterm, set TERM to xterm and set TERM_INGRES to vt100fx. Then use xmodmap to determine and set your function keys. The command xmodmap –pke should show current settings. (Use man xmodmap to determine the syntax for your version of xmodmap.)
Frequently Asked Questions 5–1 Questions About Ingres for Linux
You will probably find that there are no bindings for KP_F1 through KP_F4; you will need to bind them. For example: to bind keys Shift+F1 through Shift+F4, create a file “mykeys” that contains: keycode 67 = F1 KP_F1 keycode 68 = F2 KP_F2 keycode 69 = F3 KP_F3 keycode 70 = F4 KP_F4 Then issue the command: xmodmap mykeys Shift+F1 through Shift+F4 will now be defined as PFK1 through PFK4.
Question: What compiler and compiler switches were used to create the Linux version of Ingres? Are additional switches needed for compiling C-language application programs? Answer: Ingres was compiled using the GCC compiler version 3.2.2 with the following switches:
-O -fPIC -fsigned-char -fno-strength-reduce -fwritable-strings -D_REENTRANT -DLINUX -D_GNU_SOURCE -DXLIB_ILLEGAL_ACCESS - D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
Question: Do I need to modify system kernel parameters before running Ingres? Answer: No. Standard kernels and kernels compiled with default values (without modifying the Linux source headers) should provide adequate resources. For additional information, please see the Readme file. You might, however, need to increase the maximum allowable size for shared memory segments. You can do this by running /sbin/sysctl –w kernel.shmmax=
5–2 Getting Started Questions About Ingres for Linux
Question: Do I need to change the permissions for /dev/kmem to run Ingres on Linux? Answer: No. While this step is required on some UNIX-type systems, it is not required for this version of Ingres for Linux.
Question: When I try to compile the Fortran code generated by the ESQLF pre- compiler using g77, it fails with 'Unrecognized statement name.....'. Why? Answer: The g77 compiler (which is bundled with many if not all Linux distributions) does not support some of the statements that the ESQLF pre- compiler generates. More information is available at gnu.org.
Question: When using alternative Ingres character sets, is there anything I need to do, apart from setting II_CHARSETXX, to get the characters to display correctly? Answer: As long as your terminal is using the same character set as Ingres, you should not have a problem. If you are having trouble with characters not being displayed properly, try starting the terminal with a specific character set. For example, if you are using shiftjis (Japanese Double Byte character set) as the II_CHARSETXX setting in a 'kterm', start the kterm with the following command: kterm -km sjis
This command ensures that the terminal starts up with the correct character set. If you encounter problems using double byte character sets and kterm, try using the rxvt terminal instead. For example: rxvt -km sjis for shiftjis.
Frequently Asked Questions 5–3
Appendix Tips for a Successful A Implementation
This appendix provides additional information about specifying system file locations and configuring Ingres.
File Locations
The following sections provide additional guidelines for choosing locations for your Ingres system files. Use the information in this section as a supplement to the guidelines presented in Choosing File Locations in the chapter “Installing Ingres on Linux.”
System Files
The location you choose for the system (executable) files for Ingres and the tools will also contain the error log and configuration files. For performance reasons, choose a location for these files on a separate disk from your databases. On a three-disk system, choose a disk location that is separate from both your operating system and databases. Choose this location carefully, because you cannot easily change it after you have specified it.
You define this location with the II_SYSTEM environment variable. In the II_SYSTEM directory, the install process creates the II_SYSTEM/ingres directory and additional subdirectories for the appropriate system, error, and configuration files.
Database Files
The location for your databases contains the master database, iidbdb, which stores information about all Ingres databases, their locations, and the users who can access them. By default, this location also contains all user databases, unless the database administrator specifies an alternate location for a database when creating it. Choose this location carefully, because you cannot change it easily after specifying it initially.
Tips for a Successful Implementation A–1 File Locations
When choosing this location, keep the following in mind:
■ Place database files on a separate disk from checkpoint, journal, and dump files to maximize chances for data recovery.
■ On systems with three or more disks, do not place the database files on the same disk as your operating system, as it forces Ingres database scans to compete for I/O with system operations.
■ Place database files on a separate disk from the transaction log files to improve system performance by optimizing disk I/O.
■ Do not place database files on a device that is likely to become full as databases are added. Full disks can become fragmented, causing slow disk retrievals and degraded system performance.
You define the default location for your databases with the II_DATABASE environment variable. In this location, the install program creates the following directory tree: $II_DATABASE/ingres/data/default
Checkpoint, Journal, and Dump Files
Checkpoint, journal, and dump files provide for data recovery in case of a database disk failure. Checkpoints alone provide for data recovery up to the time of the checkpoint. Checkpoints and journals provide for recovery up to the time of failure. Checkpoint, journal, and dump files provide online checkpoints.
Checkpoints, journals, and dump files can reside on the same device because journals and dump files are useful in recovery only if the associated checkpoint is also available. By default, the install program places journal and dump files in the same location as the checkpoint files. The default location for checkpoint files is II_SYSTEM, if II_SYSTEM differs from II_DATABASE. If you use the default installation method, all files are placed under II_SYSTEM on a single disk.
Tip: Do not place the checkpoint device on the same disk as the database files. Storing data and backups on the same device provides poor insurance against disk failure. On single-disk systems, we recommend checkpointing to magnetic tape. Checkpointing to disk provides little safety if the disk fails.
Choose these locations carefully, because you cannot change them easily after specifying them initially.
A–2 Getting Started File Locations
You define the default locations for your checkpoint, journal, and dump files with the II_CHECKPOINT, II_JOURNAL, and II_DUMP environment variables. In the defined directory, the install program creates the following subdirectories: $II_CHECKPOINT/ingres/ckp/default $II_DUMP/ingres/dmp/default $II_JOURNAL/ingres/jnl/default
Temporary Work Files
Work files are temporary files created during external sorts and other DBMS Server operations that require large amounts of temporary file space.
Work files can reside on the same device as the checkpoint files because work files are useful in recovery only if the associated checkpoint is also available. However, for highest performance, assign your temporary work files to a different physical device than your database, checkpoint, journal, or dump files. Choose this location carefully, because you cannot change it easily after specifying it initially.
The following examples show you how to define the default location for your work files.
You define this location with the II_WORK environment variable. In the defined directory, the install program creates the following subdirectories, in which it places the appropriate work files: $II_WORK/ingres/work/default/iidbdb $II_WORK/ingres/work/default/dbname
Note: For more information about temporary files and sorting, see the Database Administrator Guide.
Transaction Log Files
The transaction log file stores uncommitted transactions and buffers committed transactions before they are written to the database. Ingres uses one logical installation-wide log file to store information about all pending transactions in the installation. Each logical log file may consist of up to 16 physical disk files, which helps to alleviate I/O bottlenecks.
To ensure that no committed transactions are lost if the primary transaction log devices fail, Ingres can maintain a backup of the primary transaction log file on the storage locations you specify. To enable the backup transaction log, set the environmental variable II_DUAL_LOG to the location of the backup log file (either in the response file or prior to installing packages).
Tips for a Successful Implementation A–3 Configuration Parameters
Note: For Ingres for Linux, the backup transaction log is disabled by default. (In this case, ensure that the location you intend to use for your primary transaction log file has built-in fault tolerance—for example, a fault-tolerant disk array or “mirrored” disk sub-system.)
Choosing Locations for Transaction and Backup Transaction Logs
Keep the following in mind when choosing the locations for the transaction or backup transaction log file:
■ If possible, avoid installing the primary and backup transaction log files on I/O-bound disks, because this can increase data acquisition times of the Recovery Server and archiver process and slow down all users.
■ If possible, put the transaction log file on separate disks from your database, checkpoint, dump, and journal files so that you can recover your unsaved, committed transactions if any of these disks fail.
The following example shows you how to define the locations for your transaction and backup transaction log files. For UNIX, these location(s) are defined by the log_file (primary) and dual_log (backup) configuration parameters. In each directory, the install program creates the following subdirectories, in which it places the appropriate transaction log files: $II_SYSTEM/ingres/log "$II_SYSTEM"_DUAL/ingres/log
Using Configuration-By-Forms (cbf), you can add, modify, or delete locations for your primary and dual transaction log files.
Note: To change your log file locations, you must first destroy your log file, and then create a new one. For more information on configuring transaction log files using the cbf utility, see the Command Reference Guide.
Configuration Parameters
This section describes all installation and configuration parameters used during installation. The general installation parameters apply to all installations. The DBMS Server parameters pertain only to installations containing those products. Use the information provided here to help you complete your Installation Worksheet, as needed.
A–4 Getting Started Configuration Parameters
General Installation Parameters
The following table lists the general installation parameters:
Parameter Description Ingres installation Directory specification for the location of the product’s system (executable) directory (II_SYSTEM) files.
DBMS Server Parameters
The following table describes the parameter settings used when installing the Ingres DBMS Server:
Parameter Description Default Installation code Installer-defined, two-character code that identifies II (II_INSTALLATION) an installation. For details, see Creating an Note: Value is II only if Installation Code in this appendix. you have not renamed the package. User ID (II_USERID) System administrator user ID. This user ID defines ingres the Linux user ID that owns the Ingres installation. The ID is added to the Linux system if it does not exist. Group ID Group ID to which the system administrator user ID ingres (II_GROUPID) belongs. This group ID defines the Linux group ID that owns the Ingres installation. The ID is added to the Linux system if it does not exist. Database location Location for the Ingres master database (iidbdb) and II_SYSTEM (II_DATABASE) the default location for Ingres database files. Checkpoint files Location for the checkpoint files that serve as a static II_SYSTEM location backup of the database. (II_CHECKPOINT) Journal files location Location for the journal files that provide a dynamic II_CHECKPOINT (II_JOURNAL) record of changes made to Ingres databases since the last checkpoint. Dump files location Location for the dump files used to perform online II_CHECKPOINT (II_DUMP) backups. Temporary work files Location for temporary files created during external II_SYSTEM location (II_WORK) sorts and other DBMS Server operations.
Tips for a Successful Implementation A–5 Configuration Parameters
Parameter Description Default Default transaction log The default size (32 MB per file) is probably 32 file size adequate for most installations. You should change the file size only if you have an existing application that requires a larger transaction log file.
Creating an Installation Code
The installation code is an installer-defined, two-character code that identifies a specific installation on a node and allows all processes and images to be installed and shared successfully.
The first character of II_INSTALLATION must be a letter; the second character can be a letter or numeral. If you have more than one installation on the same node, each installation on that node must have a unique installation code.
Tip: If you are using the default installation method, it will automatically define the installation code as II. Make sure that any other installations on the same node have different installation codes, or set the installation code before you install using setenv. For instructions, see Setting Environment Variables Before Installation in the chapter “Installing Ingres on Linux.”
Specifying the World Region and Time Zone
The value for the time zone for your installation is stored in the II_TIMEZONE_NAME environment variable.
In the default installation method, the value for II_TIMEZONE_NAME is NA- PACIFIC. If you are in a different time zone, you must change the value of II_TIMEZONE_NAME.
For your convenience, the list in Time Zone Names in this appendix provides all time zone names from which you can choose, organized by world region. In some cases, the time zone name is a positive or negative offset from Greenwich Mean Time (for example, GMT2 or GMT-2). If you are unable to locate the correct time zone within one of the designated world regions, use the GMT-OFFSET world region and specify one of the GMT offsets as your time zone.
A–6 Getting Started Configuration Parameters
The time zone parameter tells Ingres what adjustments to make for Daylight Savings Time. If you must make other adjustments for special time changes imposed in your area (such as for energy conservation purposes), you can use the iizic time zone compiler provided on your distribution medium. For details on the iizic compiler, see the System Administrator Guide.
Time Zone Names
The following list displays the world regions and time zone names:
Africa North America Southeast Asia
GMT NA-PACIFIC INDONESIA-WEST GMT1 NA-MOUNTAIN INDONESIA-CENTRAL GMT2 NA-CENTRAL INDONESIA-EAST GMT3 NA-EASTERN MALAYSIA GMT4 NA-ALASKA PHILIPPINES CANADA-ATLANTIC SINGAPORE Asia CANADA-NEWFOUNDLAND THAILAND CANADA-YUKON VIETNAM INDIA MEXICO-GENERAL GMT7 JAPAN MEXICO-BAJANORTE GMT8 KOREA MEXICO-BAJASUR GMT9 HONG-KONG PAKISTAN North-Atlantic GMT-Offset PRC GMT5 EUROPE-WESTERN GMT-12 GMT6 EUROPE-CENTRAL GMT-11 GMT7 EUROPE-EASTERN GMT-10 GMT8 IRELAND GMT-9 GMT9 POLAND GMT-9-and-half GMT10 TURKEY GMT-8 GMT11 UNITED-KINGDOM GMT-7 GMT GMT-6 Australia GMT1 GMT-5 GMT2 GMT-5-and-half AUSTRALIA-LORD-HOWE- GMT3 GMT-4 ISLAND GMT-3 AUSTRALIA-NORTH South America GMT-3-and-half AUSTRALIA-WEST GMT-2 AUSTRALIA-SOUTH BRAZIL-EAST GMT-1 AUSTRALIA-TASMANIA BRAZIL-WEST GMT AUSTRALIA-QUEENSLAND BRAZIL-ACRE GMT1 AUSTRALIA-VICTORIA BRAZIL-DENORONHA GMT2 AUSTRALIA-NSW CHILE-CONTINENTAL GMT3 AUSTRALIA-YANCOWINNA CHILE-EASTER-ISLAND GMT3-and-half GMT6 GMT4 Middle East GMT5 GMT5 GMT4 EGYPT GMT5-and-half GMT3 IRAN GMT6 ISRAEL South Pacific GMT7 KUWAIT GMT8 SAUDI-ARABIA NEW-ZEALAND GMT9 GMT2 US-HAWAII GMT9-and-half GMT3 GMT10 GMT10 GMT4 GMT11 GMT10-and-half GMT12 GMT11 GMT-12 GMT12 GMT-11 GMT13 GMT-10
Tips for a Successful Implementation A–7 Configuration Parameters
Supported Character Sets
The following table lists the Ingres-supported character sets for Linux. Select the character set carefully, because changing this value later can corrupt the data in your databases.
Character Set Description Format alt Support of Cyrillic on DOS Single byte arabic Arabic-449-Plus Single byte chineset Traditional Chinese - Taiwan Double byte chineses Simplified Chinese - PRC Double byte chtbig5 Traditional Chinese - Taiwan, BIG5 Double byte chteuc Traditional Chinese - Taiwan, EUC Double byte chthp Traditional Chinese - Taiwan, HP ROC15 Double byte csgb2312 Simplified Chinese - GB2312 Double byte csgbk Simplified Chinese - GBK Double byte cw Cyrillic on Windows 3.1 Single byte decmulti DEC Multinational (superset of ASCII) and default for VMS Single byte dosasmo IBM DOS ASMO Arabic (cp708) Single byte elot437 Greek for PC/RS6000/SCO-UNIX Single byte greek DEC Greek Elot Single byte hebrew DEC Hebrew Single byte hproman8 HP Roman8 (superset of ASCII) Single byte ibmpc437 IBM PC Code Page 437 (US and English) Single byte ibmpc850 IBM PC Code Page 850 (Multilingual), includes accented Single byte characters ibmpc866 IBM PC 866 (Cyrillic for DOS) Single byte is885915 ISO 8859/2 (Latin and some Greek). Identical to ISO 8859/1 Single byte Latin, except for eight characters, including the Euro currency symbol (€, Unicode U+20AC). iso88591 ISO 8859/1 Latin and default for UNIX (superset of ASCII) Single byte iso88592 8859/5 (Latin and Cyrillic) Single byte iso88595 8859/9 (Latin and some Turkish) CP 920 Single byte
A–8 Getting Started Configuration Tasks Performed During Installation
Character Set Description Format iso88599 ISO 8859/15 (Latin and Euro sign) Single byte kanjieuc EUC Japanese Double byte koi8 KOI 8-bit (ISO 6937/8), Russia Single byte korean Korean Double byte pc857 IBM PC Code page 857 - Turkish Single byte pchebrew IBM PC / MSDOS Hebrew Single byte shiftjis Shift-JIS Japanese Double byte slav852 IBM PC Code Page 852 (Slavic) Single byte thai DEC Thai Tis Single byte warabic Universal Character Set, requires 4 octets or 32 bits Single byte whebrew Microsoft Windows Hebrew Single byte win1250 Eastern Europe: Windows page 1250 Single byte win1252 Windows code page 1252 - Latin 1 (Western Europe) and Single byte default for Windows wthai IBM/Windows Thai (cp874) Single byte
Configuration Tasks Performed During Installation
The following sections describe the tasks performed by the DBMS Server installation process.
DBMS Server Configuration Tasks
The following tasks are performed during DBMS Server installation:
■ Assigns a unique installation code that you specify for this installation
■ For new installations, creates the default directory for your databases according to your specification, and creates the system catalogs master database
■ For new installations, creates directories for the checkpoint, journal, dump, work, primary transaction log, and backup transaction log files, according to the locations you specify
Tips for a Successful Implementation A–9 Configuration Tasks Performed During Installation
■ Allows you to specify or change (for an upgrade) the transaction log size, number of concurrent users, time zone setting, and the character set (for new installations only) for this installation
■ Checkpoints the iidbdb master database
■ Checks that your system has adequate resources to run as it has been configured
■ Upgrades all databases for an existing Ingres Server installation, if you elected to do so during a Custom installation.
For more information about the system catalogs, see the Database Administrator Guide.
Ingres Servers
The following server types are available, depending on your particular installation:
Server Type Description Bridge Server Enables network communications between an Ingres client using one network protocol and an Ingres server using another network protocol. Communications Provides network communications that let users connect to Server databases belonging to other installations through Ingres Net. DBMS Server Allows users access to your installation’s databases. Data Access Translates requests from the Ingres JDBC Driver and Server forwards them to the appropriate DBMS Server. ICE Server Allows developers to build World Wide Web applications that can access enterprise-wide corporate data. JDBC Server Acts in tandem with the JDBC driver to provide JDBC access to Ingres. Name Server Keeps track of all the servers associated with an installation. Recovery Server Handles online recovery from server and system failures. Remote Allows the execution of remote operating system Command Server commands. Star Server Allows users to connect to multiple databases simultaneously through Ingres Distributed Option.
A–10 Getting Started
Appendix B Installation Worksheet
This appendix provides a worksheet to aid in installing Ingres on Linux. After installing the product, keep the completed worksheet for future reference.
Using the Worksheet
The Installation Worksheet is divided into the following separate lists of parameters, which are required for installing Ingres or for setting up some components:
■ General installation parameters
■ DBMS server parameters
Value Column The Value column on your worksheet shows the default value in brackets. If you do not want to use the default, enter a different value in this column.
Tip: You cannot change the character set from its current setting (II_CHARSET) at any time without risking the corruption of your data. For information about changing the file location parameters in this list, see the System Administrator Guide.
Installation Worksheet
Worksheet for Installation______on Host______
Required Parameter Value General Installation Parameters Location for system files for Ingres and Ingres tools [II_SYSTEM] (II_SYSTEM) DBMS Server Parameters
Installation Worksheet B–1 Using the Worksheet
Required Parameter Value Installation code (II_INSTALLATION) [II] Database location (II_DATABASE) [II_SYSTEM] User ID (II_USERID) ingres Group ID (II_GROUPID) ingres Checkpoint files location (II_CHECKPOINT) [II_SYSTEM] Journal files location (II_JOURNAL) [II_CHECKPOINT] Dump files location (II_DUMP) [II_CHECKPOINT] Temporary work files location (II_WORK) [II_SYSTEM] Default transaction log file size [32 MB]
Transaction log file location [II_SYSTEM] Backup transaction log file location [II_DUAL_LOG] Number of Concurrent Users [32] Region and time zone (II_TIMEZONE_NAME) [NA-PACIFIC] Character set (II_CHARSET) [ISO88591] Comply with ANSI/ISO Entry SQL-92 database [no] standards? Region and time zone for this client [NA-PACIFIC] (II_TIMEZONE_NAME) Listen address for the DBMS server that will handle this [II_INSTALLATION] client’s requests
B–2 Getting Started
Appendix C RPM Packages
This appendix lists Ingres for Linux RPM packages available for installation.
RPM Packages for Installation
The following table lists the RPM packages you can install for Ingres 3 for Linux.
RPM Package Description Comments ca-ingres-3.0.0404-0.i386.rpm Core package Pre-requisite of all other packages ca-ingres-abf-3.0.0404-0.i386.rpm ABF ca-ingres-bridge-3.0.0404-0.i386.rpm Bridge Server Requires Net ca-ingres-c2audit-3.0.0404-0.i386.rpm C2 Security Requires DBMS ca-ingres-cluster-3.0.0404-0.i386.rpm Grid Option Requires DBMS ca-ingres-das-3.0.0404-0.i386.rpm Data Access Server ca-ingres-dbms-3.0.0404-0.i386.rpm DBMS Server ca-ingres-esql-3.0.0404-0.i386.rpm Embedded SQL pre-compilers ca-ingres-ice-3.0.0404-0.i386.rpm Web Deployment Option Requires DBMS ca-ingres-jdbc-3.0.0404-0.i386.rpm JDBC Server ca-ingres-net-3.0.0404-0.i386.rpm Communications Server ca-ingres-odbc-3.0.0404-0.i386.rpm ODBC driver ca-ingres-ome-3.0.0404-0.i386.rpm Object management ca-ingres-qr_run-3.0.0404-0.i386.rpm Query and reporting tools ca-ingres-rep-3.0.0404-0.i386.rpm Replicator Option Requires DBMS and Net ca-ingres-star-3.0.0404-0.i386.rpm Distributed DBMS Requires DBMS and Net ca-ingres-tuxedo-3.0.0404-0.i386.rpm Tuxedo
RPM Packages C–1 RPM Packages for Installation
RPM Package Description Comments ca-ingres-vision-3.0.0404-0.i386.rpm Vision forms-based application development tool ca-ingres-documentation-3.0.0404- Ingres manuals Independent of other packages. 0.i386.rpm Do not rename. Non- relocatable. If you install multiple instances of Ingres, this package is installed only once, because all instances of a given version can share the same manuals.
C–2 Getting Started
Index
A D access Data Access Server, 4-2, A-10 to databases, 2-18 running, 4-2 to tools, 2-18 data recovery, 2-6, 2-9 accessing the instance, 2-15 databases application development, 4-3 authorizing user access, 2-18 using OpenAPI, 4-2 creating, 2-18 file locations, A-1 iidbdb (master), A-1, A-5 B location, 2-8 DBMS Server, A-10 disk configurations, 2-6 Bridge Server, A-10 file locations, 2-6 parameters, A-5
C default installation method, 2-11 disk configuration requirements, 2-5 character sets, A-8 Distributed Option, 1-5 character-based tools, 1-5 dump files, location, A-2 checkpoint file location, 2-9, A-2 client installation, 2-4 E cluster. See Grid Option Communications Server, 2-3, 2-4, A-10 Embedded SQL, 1-5, 4-3 configuration Enterprise Access products, 1-4 parameters, 2-12, 2-17 environment variables types, 2-3 II_CHECKPOINT, A-3, A-5 configuring Ingres, A-4 II_DATABASE, 2-2, A-2, A-5 changing parameters, 2-17 II_DUMP, 2-2, A-3, A-5 customizing installation, 2-17 II_GROUPID, A-5 DBMS Server, A-5, A-9 II_INSTALLATION, 2-3, 2-12, 2-15, A-5 II_JOURNAL, 2-2, A-3, A-5 custom installation method, 2-12 II_RESPONSE_FILE, 2-13 II_SYSTEM, 2-12, A-1, A-5
Index–1
II_TIMEZONE_NAME, 2-9, A-6 Web Deployment Option. See Web Deployment II_USERID, A-5 Option II_WORK, A-3, A-5 installation setting before installation, 2-12 location, choosing a different, 2-12 parameters, A-4 preparing for, 2-2 F worksheet, B-1 installing file locations, choosing, 2-5 choosing files locations, A-1 multiple instances, 2-14 time zones, A-6 using the custom method, 2-9, 2-12 G using the default method, 2-9, 2-11
Grid Option, 1-5, 3-1 J
H JDBC driver, 4-2 JDBC Server, A-10 hardware requirements, 2-1 journals, file location, A-2
I L
ICE Server, A-10 license agreement, 2-10 II_CHECKPOINT, 2-2, A-5 logging system, making changes to, 2-17 II_DATABASE, 2-2, A-5 II_DUMP, 2-2, A-5 M II_GROUPID, A-5 II_INSTALLATION, 2-3, 2-12, 2-15, A-5 master database, recovering, 2-17 II_JOURNAL, 2-2, A-5 multiple installations, 1-3 II_RESPONSE_FILE, 2-13 II_SYSTEM, 2-12, A-5 II_TIMEZONE_NAME, 2-9 N II_USERID, A-5 Name Server, A-10 II_WORK, A-5 Net, 1-3 iimkcluster utility, 3-1, 3-3 iisunode utility, 3-1 Ingres O Grid Option. See Grid Option Net. See Net open source, 1-2 Replicator Option. See Replicator Option
Index–2 Getting Started
OpenAPI, 4-2 backup, 2-6, 2-7, 2-8 locations, 2-7, 2-8, A-3 recovery, 2-6 R U recovering databases, 2-9 master database, 2-17 user transactions, 2-6, 2-9 access to databases, 2-18 access to tools, 2-18 Recovery Server, A-10 authorization to start and stop servers, 2-17 Remote Command Server, A-10 types, 1-6 Replicator Option, 1-5 requirements, system, 2-1, 2-2 V response file, 2-12 RPM, 1-7, 2-2 Vision, 1-5 packages, 2-3, C-1
W S
Web Deployment Option, 1-3, 4-3 server, types, A-10 web-based applications, creating, 4-3 software requirements, 2-2 work files, location of, A-3 Star Server, A-10 worksheet for installing, 2-10 starting and stopping Ingres, 2-16 system files, A-1 X requirements, 2-1
XML web authoring tools, using with Web Deployment Option, 4-4 T transaction log files
Index–3