Oracle Database Preinstallation – Part 8

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.

Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.

I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.

Contact: Franz

Oracle Database Preinstallation – Part 8

Creating Database Operating System Groups and Users with Job Role Separation

Remember to add the oracle software owner (oracle, oinstall, or similar), to the required operating system groups, after you have created them.  This is to ensure that Oracle Universal Installer (OUI) will pick them up as an option, during the database part of the installation.

Provide common User IDs (UID)’s and Group IDs (GID)’s, and confirm that they are unused before you create or modify groups and users with these ID’s.  If you are unsure, the system administrator may be able to explain.

Creating the Oracle Inventory Group

You need to create this group when you install the Oracle software on the system for the first time.  During the installation of the software OUI, will create the oraInst.loc file.  This file will contain the name of the Oracle inventory group, which may be “oinstall”, and of course the path of the Oracle Inventory directory.

It is possible to configure one group as the access control group for Oracle Inventory, for the database administrators “OSDBA”, and for all the other access control groups that are used by Oracle software for operating system authentication.  The result of this approach is that this group must then be the primary group for all users that are granted administrative privileges.  Obviously this has security implications.  Anyway to get started you will need to login as “root”, and determine if the Oracle Inventory Group exists.  If it does not exist, then you will Create the Oracle Inventory Group.

Determining if the Oracle Inventory Group Exists

Look in the oraInst.loc file and look at the content.  You should find something similar to this:

Inventory_loc=<”location of the Oracle Central Inventory”>

Inst_group=<”name of the group that has permissions to write to the central inventory”>

If you find an existing Oracle Inventory, then you should use the same Oracle Inventory for all Oracle Software Installations.  You must make sure that all the Oracle software users, that will perform installations, have permissions to write to this directory.

Verify that the Oracle Inventory Groups exists:

$ grep oinstall /etc/group

Verify that the oraInst.loc file exists:

$ more /etc/oraInst.loc

Output example:

Inventory_loc=/u01/app/oraInventory

Inst_group=oinstall

Creating the Oracle Inventory Group

If you determine that the Oracle Inventory group does not exist, then you can create it.  If the Oracle Inventory group does exist, then you will find that the /etc/oraInst.loc file exists.

$ /usr/sbin/groupadd oinstall

Creating the OSDBA Group for Database Installations

If you find that the OSDBA group does not exist, because this is the first installation of Oracle Database software on the system.  Or you may find that the OSDBA group does exist, but you want to create a new OSDBA group, so that you can give a group of operating system users database administrative privileges, for a new or different Oracle database Installation.

If any of the above reasons are valid then you can go ahead and create the OSDBA group.  If there is no group with the name “dba”, then you can give the new group the name “dba”.

$ /usr/sbin/groupadd -g  502 dba

Creating the OSOPER Group for Oracle Automatic Storage Management

If you decide that you will use a separate OSOPER group for ASM, then you can create it.  If the group name “asmoper” does not exist, then you can call this group “asmoper”.

$ /usr/sbin/groupadd -g 505 asmoper

Creating the Oracle Software Owner User

There may be three different reasons why you may want to create the Oracle Software Owner User.

1) You have determined that an Oracle software owner user does not exist.  This would be expected if this was the first installation of Oracle software on the system or server.

2) The Oracle software owner user does exist.  However you have decided to use a different operating system user, which will be granted different group memberships.  This scenario could enable you to give database administrative privileges to those different groups, in a new Oracle database installation.  This will separate the privileges between the two databases, between different Operating System users, and prevent users from accidently logging onto the wrong database, and performing administrative functions.

3) You may have created an Oracle software owner for Oracle Grid Infrastructure, for example “grid”, and you want to create a separate Oracle software owner for the Oracle Database software, such as “oracle”.

Determining if an Oracle Software Owner User Exists

If you know that the software owner would be either “oracle” or “grid”, then you can check if they exist like this:

$ id oracle

uid=301(oracle) gid=301(oinstall) groups=302(dba),303(oper)

$ id grid

uid=7001(grid) gid=7001(oinstall) groups=7001(oinstall),7002(asmadmin),7003(asmdba),7006(dba)

Verify that the Oracle software owner has the Oracle Inventory group (oinstall), as its primary group.

Verify that the user is also a member of the appropriate groups, for example: OSDBA, ASMDBA, OSBACKUPDBA, OSDGDBA, OSKMDBA etc.  These group memberships must be allocated according to the security and infrastructure design that you have in place or have created for this implementation.

Now you need to decide whether you are going to create a new Oracle Software Owner User, or if you are going to modify and existing Oracle Software Owner User, to bring the group assignments etc in line with your plan.  If you are going to modify an existing user, it is always better to first check with your System Administrator, if changing the credentials of a specific user will have any impact on other areas on the server.

Creating an Oracle Software Owner User

If the user “oracle” does not exist, then create the user with the name “oracle”.

$ /usr/sbin/useradd -u 502 -g oinstall -G  dba,asmdba oracle

=> -u specifies the user ID.  If you leave this option out, then the operating system will automatically generate a user ID.  You must make a note of the oracle user ID, because you will need it again, later on in the pre-installation.

=> -g specifies the primary group, which must be the Oracle Inventory group, which will typically be “oinstall”.

=> -G specifies the secondary groups, separated by commas.  The OSDBA group must be included, and depending on the requirements, the OSOPER, and ASMDBA groups as well.

Now all you need to do is to set the password of the new user.

$ passwd oracle

Modifying an Existing Oracle Software Owner User

Let’s say you have found the Oracle Software Owner User “oracle”, however its primary group is not “oinstall”, and it is not a member of the OSDBA, or OSOPER groups.  Also you have confirmed with the system administrator, that it is ok to change this operating system user.  The you can go ahead and change it.  Notice how you will specify the primary group with the -g option, and the seconday groups with the -G option.

$ /usr/sbin/usermod -g oinstall -G dba,asmdba,oper  oracle

Franz Devantier,

Need a database health check?

devantierf@gmail.com

Classifieds

Year of the Stem Cell

Devantier Hosting, from $2.75

Host then Profit GVO

Global Domains International

Cash in on Banners

Hot Link Cycler

A to Z AdBoard

Ad Viralizer

Traffic Exchange Profits

Easy Downlines

Fast Cash and Traffic

Simple Safelists

Traffic Wave - Autoresponder

Traffic Hoopla

Business Related Social Media

Oracle Database Preinstallation – Part 7

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.

Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.

I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.

Contact: Franz

Oracle Database Preinstallation – Part 7

Creating Required Operating System Groups and Users

If the Oracle software was previously installed on your system, then you may not have to do this.  However it is always best to verify the configuration that has been defined, if it is already in place. 

Otherwise you will need to create several operating system groups and users.

If you prefer to allocate operating system user privileges, so that you can use one administrative user and one group for your operating system authentication for all of the administrative privileges, then you can use the oracle user as the installation owner, and use one group as the primary group for any user requiring administrative privileges for Oracle ASM, and Oracle database Administration.  This group must then also be the Oracle Inventory group.  To simplify using the defaults for the Oracle tools, the group name should then be oinstall.  From a security point of view this is a big problem.

A better approach is to create custom configuration groups and users, based on job role separation.  A custom configuration would for example have groups and users, that divide access privileges granted by membership in separate or different operating system groups and users.  You could still in this scenario create a single user, which would own both the Oracle Database, and the Oracle Grid Infrastructure installation.  Of course this brings with it a security consideration.  It would still be far better to create a user to own the Oracle database, and a separate user to own the Oracle Grid infrastructure installation.

For a standalone server installation, the owners and or users of the Oracle database and grid infrastructure, must both belong to the Oracle Inventory group for example “oinstall”.  A user that has been created to own wither the Oracle database installation, or all the Oracle installations is referred to as the oracle user, although the username, may not be “oracle”.  A user that is created to own the Oracle Grid Infrastructure software is called the grid user.

Creating Custom Configuration Groups and Users for Job Roles

To start with you will need to log in as “root” to create these groups or users.  If your company does not give you access to the root user, even after motivation, then you should look for another job.  Alternatively you can multiply the time required for the operation by at least 10 times.  Then you will need to sit with the System administrator who does have root access, and patiently talk them through the process, step by step.  You should set up a server or a laptop at home with the installation on it, so that you can practice the full installation for yourself, in order to minimize your disability with not having “root” access.

Understanding Restrictions for Oracle Installations with Job Role Separation

Always best in the long run to go with the Oracle recommendations, because they are there for good reasons.  Oracle recommends that you should have one software owner for each Oracle Software installation.  This makes a lot of sense, because it separates the different installations logically from each other, ie, you don’t end up writing in each other’s configurations files etc.  Actually the worst that I have seen at some large well known telecom companies in Southern Africa, is different databases, that have their data-files mingled together in the same directory structures.  Of course this becomes a nightmare when management decides to move databases around and clean-up “obsolete” data-files.  In this specific case, I pointed out the situation, before any actions were taken.

So you need to create separate Oracle software owners, create separate users, create separate operating system privilege groups for different Oracle software installations.  Each of these separate users must have the Oracle central inventory group or the OraInventory group, as their primary group.  Members of this group have write privileges to the Oracle central inventory or oraInventory directory, as well as being granted permissions for various Oracle Restart resources and directories in the Oracle Restart Home.  Oracle DBA’s need write access amongst other privileges to these directory structures.  The Oracle documentation tends to refer to this group as the “oinstall” group, although it could be called something else.

The database software owner which is usually “oracle”, must also have the OSDBA group of the Oracle Grid infrastructure home, so that database instances can log on to Oracle ASM.  “oracle”, should also have the OSOPER group assigned as a secondary group.  The OSOPER group is optional to a certain extent, but not creating it, does raise additional security issues.  Usually the Oracle software owner users are referred to as the oracle users, regardless of what the username is.

For a standalone server installation, the owners of the Oracle Database software, and the Oracle Grid Infrastructure software, must both belong to the Oracle inventory group “oinstall”.

Each Oracle software owner must be a member of the central inventory group.  You can have only one central inventory group for Oracle installations on a server.  If you do create a separate central inventory group, then you stand a chance of corrupting the central inventory.  On a standalone server, the grid user or the owner of the Grid infrastructure software, must be in the OSDBA group of every database home on that server.

So you can see that even with separate software owners, and users, and groups, things can still get very much intertwined with each other.  So you have to be careful, and you have to have a properly designed infrastructure to protect your database investment.  By the way, using the services of an Oracle database architect up front, will probably save you multiple nightmares down the line.

Database Groups for Job Role Installations

If you are installing the Oracle Database, then you need to create the following operating system groups.

=> OSDBA group, which may be “dba”.

The first time that you install the Oracle Database software on the system, you will need to create this group.  The members of the OSDBA group contains operating system user accounts that have database administrative privileges, such as SYSDBA privilege.

=> OSOPER group for the Oracle Database installation, typically “oper”.

Although this is an optional group, there are strong motivations from a database security perspective to create this group.  Having access to this group will allow you to have a separate group of operating system users, that have a limited set of database administrative privileges, that are given by the SYSOPER privilege.  This group can’t directly connect to the database as SYSOPER, unless this privilege is explicitly granted to them.  Members of the OSDBA group by default have all the privileges that are granted to the SYSOPER privilege.  Oracle Universal Installer will prompt you for the name of this group, which is typically “oper”.

The OSOPER group is ideal to grant to junior DBA’s, so that the mistakes that they potentially make on the database installations while they are learning there trade is limited.  Later on, when they start becoming more proficient, and are giving more responsibilities, they can receive the appropriate privileges. 

Oracle Grid Infrastructure Groups for Job Role Installations

If you are preparing to install Oracle Grid Infrastructure, then you will need additional groups to the Oracle Database installation.  You can take the decision here to use the same group as the OSASM and OSDBA groups, to be able to grant system privileges to administer both Oracle ASM instances and Oracle database instances.  However it is always more secure to separate the duties, and create or designate a unique group, separate from the database administrators groups.

=> OSDBA group for Oracle ASM, which is usually called “asmdba”.

It is better practice to have separate OSDBA groups for the Oracle database installation and the Oracle Grid infrastructure installation.

The Oracle Grid infrastructure software owner “grid”, must be a member of the OSDBA group.  Membership of the OSDBA group enables access to the files managed by Oracle ASM.

If you do have a separate OSDBA group for Oracle ASM, then the Oracle restart software owner must also be a member of the OSDBA (dba) group for each database, and also must be a member of the OSDBA (asmdba) group for ASM.   

=> OSASM group for Oracle ASM “asmadmin”

SYSASM privileges for Oracle ASM files provide administrator privileges for storage files.  Typically you would think of the operating system group whose members are granted the SYSASM privileges as the OSASM group, which typically translates to “asmadmin” from the Linux perspective.  Oracle ASM can support multiple databases.

If you are a member of the OSASM group, then you can use SQL to connect to an Oracle ASM instance as SYSASM, using the operating system authentication mechanism.  With the SYSASM privilege you can mount and dismount disk groups, and carry out other storage administration tasks.  The SYSASM privilege will not provide any access to the RDBMS instance.

■The OSASM group for Oracle ASM (typically, asmadmin)

SYSASM privileges for Oracle ASM files provide administrator privileges for storage file. In Oracle documentation, the operating system group whose members are granted SYSASM privileges is called the OSASM group, and in command lines, is referred to as asmadmin. Oracle ASM can support multiple databases.

Members of the OSASM group can use SQL to connect to an Oracle ASM instance as SYSASM using operating system authentication. The SYSASM privileges permit mounting and dismounting of disk groups, and other storage administration tasks. SYSASM privileges provide no access privileges on an RDBMS instance.

This is why you need to create the OSASM group.  If you don’t designate a separate group as the OSASM group, then the OSDBA group that you define is also by default the OSASM group.  This means that you can access the database with SQL queries as well as manage the ASM disks.  It is far better to keep the duties separated by creating the OSASM group.

OSOPER from for Oracle ASM, “asmoper”.

This is an optional group.  Again it comes down to Oracle database security considerations.  Creating this group will give you a separate group of operating system users, who have a limited set of Oracle instance administrative privileges.  Now that is exactly what you want.  This is the SYSOPER for the ASM privileges.  These privileges includes starting up and stopping the Oracle ASM instance.  By default the members of the OSASM group will also have all the privileges granted by the SYSOPER group for ASM privileges.  So the OSOPER group is a limited privilege version of the SYSOPER group.

If you define a OSOPER group for Oracle ASM, then the Oracle Grid Infrastructure owner must be a member of this group.

Franz Devantier,

Need a database health check?

devantierf@gmail.com

Classifieds

Year of the Stem Cell

Devantier Hosting, from $2.75

Host then Profit GVO

Global Domains International

Cash in on Banners

Hot Link Cycler

A to Z AdBoard

Ad Viralizer

Traffic Exchange Profits

Easy Downlines

Fast Cash and Traffic

Simple Safelists

Traffic Wave - Autoresponder

Traffic Hoopla

Business Related Social Media

Oracle Database Preinstallation – Part 6

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.

Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.

I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.

Contact: Franz

Oracle Database Preinstallation – Part 6

Ephemeral Ports

This is a short lived transport protocol port for Internet Protocol (IP) communications, which is automatically allocated from a predefined range by the TCP/IP software.  Ephemeral ports are used by Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control transmission Protocol (SCTP), as the port assignment for the client end of a client server communication, to a well-known port on a server.

On servers, ephemeral ports may be used as the port assignment on the server end of a communication.  This may be done to continue communications with a client that initially connected to one of the server’s well-known service listening ports.  File Transfer Protocol (FTP) and Remote Procedure Call (RPC) applications are tow protocols that can behave in this way.  By servers we include workstations that are running services and receive connections, initiated by other clients, such as Remote Desktop Protocol (RDP).  Ephemeral port allocations are temporary, and only valid for the duration of the communication session.  When the communication session completes, the port will again become available for reuse, which is why they are also called dynamic ports.

The Internet Assigned Numbers Authority (IANA) suggests the range of 49152 to 65535 for these dynamic or ephemeral ports.  Most Linux kernels use the port range of 32768 to 61000, with the exception of “FreeBSD release 4.6”, which uses the IANA port range.  Previous versions of Berkeley Software Distribution (BSD), used the port range of 1024 to 5000 as ephemeral ports.

Microsoft windows up to and including the XP operating system, use the port range of 1025 to 5000 as ephemeral ports by default.  Windows server 2003 also uses the port range of 1025 to 5000 by default as ephemeral ports.  From Windows Vista onwards, and Server 2008 onwards, windows uses the IANA range by default as ephemeral ports.  In addition to the default ephemeral port range, all versions of Microsoft since Windows 2000, allows the use of a non-default port range of 1025 to 65535 to be used as ephemeral ports.  There is a popular misconception in Microsoft circles that 1025 to 65535 is the default or in fact required range for ephemeral ports, so watch out for that one.

Verify UDP and TCP Kernel Parameters

You need to have some idea of the anticipated server workload, so that you can set enough ephemeral ports to cater for the anticipated workload.  If you are not going to set it to the IANA range, then at least make sure that the lower range is set to at least 9000 or higher.  In this way you will be avoiding well known ports.  You need to be out of the port range that is commonly used by oracle, and other services.  You definitely want to avoid becoming entangled with reserved ports, with your ephemeral port ranges.  If you are confident that your lower range of your ephemeral ports is at least 9000, and you have a large enough range to cater for the expected workload, then you can ignore the warnings generated by Oracle Universal Installer (OUI) with regards to your ephemeral port range.

If you are using IPV4 for example, you can check your current range of ephemeral ports something like this:

$ cat /proc/sys/net/ipv4/ip_local_port_range

32768 61000

From this you can see that the ephemeral ports are set to the default Linux port range.  If it is necessary you can update the UDP and the TCP ephemeral port range to values that are suitable for the anticipated system workloads; emsuring that the ephemeral port range starts at a minimal of 9000.  Be careful with the below command because it will overwrite the ip_local_port_range file.

$ echo 9000 65500 > /proc/sys/net/ipv4/ip_local_port_range

Oracle recommends that you should make these setting permanent, so that after rebooting, you still have the same ephemeral port configuration.  As the root user, you can open /etc/sysctl.conf.  If the values are not suitable, then you can add or change the following entry.

net.ipv4.ip_local_port_range = 9000 65500

After making this change you must restart the network:

$ /etc/rc.d/init.d/network restart

You can also refer to your Linux distribution system administration documents, for the information about automating the ephemeral port ranges over system restarts.

Installing the cvuqdisk Package for Linux

Next you need to decide whether you are going to enable or disable the Cluster Verification Utility for shared disk checks.

However firstly you will need to install the operating system package cvuqdisk.  Without this the Cluster Verification Utility (CVU) cannot find the shared disks, and when you run the CVU utility, you will get this error. “Package cvuqdisk not installed”. 

Make sure that you use the cvuqdisk RPM package that matches your hardware, for example x86_64 or i386.

If you are going to disable the CVU, then you don’t need to install the package, and you can disable it like this:

$ vi $ORACLE_HOME/cv/admin/cvu_config

And add this line to the file:

CV_RAW_CHECK_ENABLED=FALSE

Below is an example of the steps that you could go through to install the cvuqdisk rpm package.

=> Either download or locate the package on the installation media, or if you installed the Oracle Grid Infrastructure it will be in $ORACLE_HOME/cv/rpm

=> log in as root or switch user to root

=> Check if there is an existing version already installed.

$ rpm -qi cvuqdisk

=> If there is an existing version, then first deinstall it.

$rpm -e cvuqdisk

=> Set your environment variable CVUQDISK to point to the group that owns cvuqdisk, which would be “oinstall” or “oracle”,

$ CVUQDISK_GRP=oinstall; export CVUQDISK_GRP

=> Now you can change to the directory, where the cvuqdisk rpm package resides and install it.

$ rpm -iv cvuqdisk-1.0.9-1.rpm

You are done.

Checking the Network Setup

Usually the computer that you are installing the Oracle Database is connected to the Network.  Typically it will have local storage to hold the Oracle database installation.  It will also have a display monitor, and a DVD drive.  In this case the installation is fairly straight forward, once you have verified the pre-requisites.  However not all computers that we need to install Oracle on, are set up in this way.

Installing on DHCP Computers

Dynamic Host Configuration Protocol (DHCP) assigns dynamic IP addresses on a network. Dynamic addressing enables a computer to have a different IP address each time it connects to the network. In some cases, the IP address can change while the computer is still connected. On a DHCP system, you can have a mixture of static and dynamic IP addresses.

The DHCP software tracks the IP addresses, which helps with the network administration. With setup, you can add a new computer to the network, without manually assigning an IP address to the newly added computer.

Installing on Multihomed Computers

A Multihomed computer is one which contains multiple IP addresses.  Typically the computer would have multiple network cards on the computer.  Each IP address is associated with a host name.  Of course you can also set up aliases for each of the host names.  OUI by default uses the ORACLE_HOSTNAME environment variable to find the host name.  Ok, but what if ORACLE_HOSTNAME is not set, for whatever reason?  Then OUI will determine the host name from the /etc/hosts file.  These are the two places to look if you need to do some trouble shooting.

Clients who need to connect to the computer will need to connect using the host name or by using one of the aliases.  To verify that this mechanism is working, you can ping the host name from a client computer with the short name, which is the host name only.  Then you can try the long name, which is the host name and the domain name together.  Both of these test must be successful.

You can install Oracle Database on a multihomed computer. A multihomed computer is associated with multiple IP addresses. This is typically achieved by having multiple network cards on the computer. Each IP address is associated with a host name. In addition, you can set up aliases for the host name. By default, Oracle Universal Installer uses the ORACLE_HOSTNAME environment variable setting to find the host name. If ORACLE_HOSTNAME is not set and you are installing on a computer that has multiple network cards, then Oracle Universal Installer determines the host name from the /etc/hosts file.

Clients must be able to access the computer either by using this host name or by using aliases for this host name. To verify, ping the host name from the client computers using the short name (host name only) and the full name (host name and domain name). Both tests must be successful.

Setting the ORACLE_HOSTNAME Environment Variable

In the Bourne, Bash, or Korn shell (Hopefully you will be using the Bash shell, because it is the latest)

$ ORACLE_HOSTNAME=hostname.domain.example.com

$ export ORACLE_HOSTNAME

Or more simply

$ export ORACLE_HOSTNAME=hostname.domain.example.com

If for some reason you insist on using the C shell.

$ setenv ORACLE_HOSTNAME=hostname.domain.example.com

Keep in mind that this configuration will only last for the duration of your shell.  You may consider setting up this variable in your .profile file, when you log in as oracle or oinstall for example.  Or configuring it, when you source the environment.

Installing on Computers with Multiple Aliases

Sometimes a computer can have multiple aliases, which all resolve to the same IP address.  It is best to set the ORACLE_HOSTNAME environment variable to the computer name, and not to one of the aliases.  Make sure before you start the installation, by doing a ping over the network, to see if you can see the computer.

Installing on Non-Networked Computers

You can of course install the Oracle database on a computer that is not connected to a network.  If such a computer, for example a laptop is configured for DHCP, and you do plan to connect to a network after the installation.  Then before you start, you must verify that the computer can connect to itself, by running a ping command to the computer that you are on.  Ping for only the host name, and then for the host name plus the domain name, which is the fully qualified name.  The fully qualified name should be in the /etc/hosts file.  The ping command should be returning the IP address of the computer that you are on.  If the ping command fails, then you need to resolve this issue, possibly with the system administrator, before you continue with the installation.  Otherwise after the installation, you may not be able to connect to the network, and the exercise may not have been a productive one.

Connecting the Computer to the Network after Installation

Now you should be able to connect to a network, after you have completed the Oracle Database installation.  Typically this network connectivity is essential, to facilitate the running of the application etc, unless it is a very small installation, with the application, database, and user or users all connecting directly to the one computer.  The computer should be able to use a static IP address or DHCP, depending on the network that you connect to.

Franz Devantier,

Need a database health check?

devantierf@gmail.com

Classifieds

Year of the Stem Cell

Devantier Hosting, from $2.75

Host then Profit GVO

Global Domains International

Cash in on Banners

Hot Link Cycler

A to Z AdBoard

Ad Viralizer

Traffic Exchange Profits

Easy Downlines

Fast Cash and Traffic

Simple Safelists

Traffic Wave - Autoresponder

Traffic Hoopla

Business Related Social Media

Oracle Database Preinstallation – Part 5

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.

Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.

I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.

Contact: Franz

Oracle Database Preinstallation – Part 5

Compiler Requirements

Both for Linux x86 and Linux x86_64, you will need the intel C++ Compiler version 10.1 or later.  Remember we are working with the 11.2 database here on a Linux operating system.  Specifically Oracle Linux.  You will also need the version of GNU C and C++ Compilers that are listed under “Package Requirements” in my previous article.  You will need to find the Pro*C/C++ Oracle call interface, and the Oracle C++ call interface that is compatible that comes with Oracle database 11.2.  The Oracle XML developers kit (XDK) for Oracle 11.2 must also be installed, from the Oracle installation media.

You need to be aware that on Linux x86 and Linux x86_64, the intel C++ Compiler version 10.1 can only be used with the standard template libraries of the gcc versions that are mentioned in the “Package Requirements”, in my previous article.  You would use these to build the Oracle C++ Call Interface (OCCI) applications.  XDK is supported with the same compilers as OCCI, so once you have OCCI in place you are good to go for the XDK components.

Additional Software Requirements

Before you consider which software should be installed with your Oracle installation, you need to decide what components from the Oracle installation you are going to use.  While it would be easier to install the Operating System packages now, and add the appropriate functionality into the Oracle binaries later on, it makes sense to do as part of your pre-requisites.

For example you may be considering the following components in your Oracle binaries:

=> Oracle ODBC Drivers

=> Oracle JDBC/OCI Drivers

=> Linux-PAM Library

=> Oracle Messaging Gateway

=> Programming Languages

=> Specific Browser Requirements

=> Oracle Database Vault (Comes with the Oracle binaries, but is not linked in by default)

Depending on your Operating System

I have focussed on Oracle Linux running on an Intel chip, so if you are using another version of Linux on other hardware, then you will need to refer again to the Oracle installation documentation.

Oracle ODBC Drivers

Oracle Linux 4 and red Hat Enterprise Linux 4

unixODBC-2.2.11 (32 bit) or later

unixODBC-devel-2.2.11 (32 bit) or later

Asianux Server 3, Oracle Linux 5, and Red Hat Enterprise Linux 5

unixODBC-2.2.11 (32 bit) or later

unixODBC-devel-2.2.11 (32 bit) or later

In order to use ODBC on Linux x86_64, you will need to install a few additional ODBC .rpm’s

Oracle Linux 4 and Red Hat Enterprise Linux 4

unixODBC-2.2.11 (32 bit) or later

unixODBC-devel-2.2.11 (64 bit) or later

unixODBC-2.2.11 (64 bit ) or later

Asianux Server 3, Oracle Linux 5, and Red Hat Enterprise Linux 5

unixODBC-2.2.11 (32 bit) or later

unixODBC-devel-2.2.11 (64 bit) or later

unixODBC-2.2.11 (64 bit) or later

Oracle Linux 6, and Red Hat Enterprise Linux 6

unixODBC-2.2.14-11.el6 (x86_64) or later

unixODBC-2.2.14-11.el6.i686 or later

unixODBC-devel-2.2.14-11.el6 (x86_64) or later

unixODBC-devel-2.2.14-11.el6.i686 or later

Oracle JDBC/OCI Drivers

For Linux x86 and Linux x86-64

Use Java SE Development kit 1.6.0_21 (JDK 6) or Java SE Development kit 1.5.0_24 (JDK 5).  You will need to verify that you are using the JNDI extension with the Oracle Java Database Connectivity, as well as the Oracle Call Interface drivers.  Although the above is not mandatory for the installation of Oracle 11.2, because JDK 1.5 (JDK 5) is installed by default; you may still experience problems when you use your JDBC/OCI drivers, if it does not comply.

Linux-PAM Library

PAM stands for (Pluggable Authentication Modules).  So we are looking at the Pluggable Authentication Modules for Linux library, or Linux-PAM library.  This one is fairly straight forward, you just need to install the latest Linux-PAM library.  This library enables the system administrator to choose how applications authenticate users.  From a security perspective, having this package in place upfront, will give you more options with regards to user authentication.

Oracle Messaging Gateway

IF you are going to be integrating Oracle streams and / or Advanced Queuing (AQ) with IBM WebSphere or TIBCO Rendezvous, then you will need to link the Oracle Messaging Gateway into your Oracle binaries.

More specifically:

=> IBM WbeSphere MQ V6.0, client and server, with corrective service diskette 5 (CSD05) or later.  MQSeriesClient, MQSeriesServer, MQSeriesRuntime

=> TIBCO Rendezvous 7.3

Programming Languages

If you are going to use Pro*COBOL, then you will find that there is a product that is certified for use.  This product is Micro Focus Server Express 5.1

Micro Focus does tend to be expensive, and so if you have time for some research, you can look at the many open source Cobol compilers on the market.  Before going into production, you will need to do extensive testing to make sure that your compiler is up to the task.  Of course Testing also cost money, so this tends to even things out. 

In a high throughput critical production environment, it would be better to pay the license for Micro Focus, because then you know that there will be no surprises waiting for you.

Specific Browser Requirements

You need to use a web browser that supports JavaScript, and HTML 4.0 and CSS 1.0 standards, in order to meet the requirements to run Oracle Enterprise Manager Database Control for 11.2.

These browsers meet the minimal requirements:

Netscape Navigator 8.1

Netscape Navigator 9.0

Microsoft Internet Explorer 6.0 SP2

Microsoft Internet Explorer 7.0 SP1

Microsoft Internet Explorer 8.0

Microsoft Internet Explorer 9.0

Firefox 2.0

Firefox 3.0.7

Firefox 3.5

Firefox 3.6

Safari 3.1

Safari 3.2

Safari 4.0.x

Google Chrome 3.0

Google Chrome 4.0

Oracle Database Vault

There is one major requirement that must be met, before you can link Oracle Database Vault into the binaries and implement it.  Your DB_BLOCK_SIZE parameter must be 4096 or larger.  In 11.2 it is 8192 by default.  This parameter can only be set during database creation, so if it is set to a value that is less than 4096, then the only way to change it would be to recreate the database.  It is a good idea to have your pre-requisites on a tick sheet, and when your create the database, just tick it off, so that you know this pre-requisite has been met.

Fixup Scripts

When you run the Oracle Universal Installer (OUI), if there are any pre-requisites that are not met, then it stops.  OUI shows you which areas need to be attended to, before you can continue.  Very often there will also be a reference to “fixup scripts”, that you will need to run as “root”.  Remember that you are running OUI as “oracle”, or the oracle installation user.  However after running the fixup scripts, there is still no guarantee that the pre-installation requirements have been met.  You should still go through the exercise of checking the pre-installation requirements before trying to install the software again. 

In fact it is very bad practice to just run OUI, run the fixup scripts, and try to get Oracle installed on the box, as many DBA’s do.  Some DBA’s even override the failed pre-requisites at this stage.  The result of this is that, one small problem during the installation of the software, can translate into hundreds of difficult or impossible to resolve problems later on.  The remedy for such a situation may be running through all the pre-installation checks again, re-installing Oracle 11.2, rebuilding the databases, and re-importing your data back in again.  Linking the application back in again and etc.  Such a situation could potentially translate into a lot of downtime on a production installation, so make sure that your pre-requisites have been properly verified. 

Franz Devantier,

Need a database health check?

devantierf@gmail.com

Classifieds

Year of the Stem Cell

Devantier Hosting, from $2.75

Host then Profit GVO

Global Domains International

Cash in on Banners

Hot Link Cycler

A to Z AdBoard

Ad Viralizer

Traffic Exchange Profits

Easy Downlines

Fast Cash and Traffic

Simple Safelists

Traffic Wave - Autoresponder

Traffic Hoopla

Business Related Social Media