Re: dbstart script failure on 8i
Date: Fri, 05 Jan 2001 17:39:41 GMT
Message-ID: <9350sr$s0c$1_at_nnrp1.deja.com>
In our last gripping episode Paul Bennett <spacey845_at_my-deja.com> wrote:
> In article <3A551C07.FFEB12A1_at_NYCap.RR.Com>,
> Stephen Murphy <SMurphy1_at_NYCap.RR.Com> wrote:
> > Been there, done that.....
> >
> > There is an official fix available from Oracle but I don't have it
at
> > home. It fixes the check for PL/SQL and also fixes some $VARIBLE
setting
> > which was not done quite right.
> >
> > Connor McDonald wrote:
> > >
> > > Paul Bennett wrote:
> > > >
> > > > I have Oracle 8i on AIX 4.3.2, and the dbstart script doesn't
start any
> > > > instances, but claims that it has.
[snip]
> > > > I've patched the script to work around it at the moment, but I'm
> > > > concerned that this meas that PL/SQL isn't (properly) installed.
> > > >
[snip]
> > > You've done the right thing - its a known bug - because PL/SQL is
no
> > > longer option (ie its mandatory) it no longer appears in the
banner.
> > >
> > > Fixed in a patch release somewhere..
>
> Thanks!
>
> I'm suffering from a bout of PHB interference. Anyone got any ideas
> where can I get the official patch?
>
> ---
> Pb
> My opinions are my own and should not be taken as
> representing any other group or entity.
>
> Sent via Deja.com
> http://www.deja.com/
>
[Quoted] I believe this is what you are looking for. This was found on Metalink, and also included are the referenced support notes regarding Server manager desupport and the CONNECT INTERNAL desupport:
Doc ID: Note:98418.1
Subject: WARNING: "dbstart" does not work with 8.1.6 Instances
Type: PROBLEM
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 07-FEB-2000
Last Revision Date: 13-JUL-2000
Language: USAENG
Problem Description
"dbstart" is a shellscript used on Unix platforms to start databases listed in the "oratab" file. It is often called from system startup scripts.
The "dbstart" script shipped with all versions of Oracle up to and
including 8.1.6 does not start any 8.1.6 instances if they are down.
"dbstart" will report "Database <SID> warm started" rather than
starting
the instance. This problem only affects 8.1.6 (or later) instances.
The change in the banner may affect users custom startup / shutdown scripts.
"dbshut" has no problem.
Please note there are 2 related issues which should be born in mind when changing any startup / shutdown scripts:
Advance notification of Server Manager desupport
[NOTE:74943.1]
Advance notification of CONNECT INTERNAL desupport
[NOTE:50508.1]
Solution Description
Enterprise Edition Workaround
The workaround is to change the dbstart script to look for the string "Oracle8i Enterprise Edition" instead of "PL/SQL" by making the following
changes:
- Save a copy of the 8.1.6 $ORACLE_HOME/bin/dbstart script
- Edit the script and change the 'awk' lines from: VERSION=`$ORACLE_HOME/bin/svrmgrl command=exit | awk ' /PL\/SQL (Release|Version)/ {substr($3,1,3) ; print substr($3,1,3)}'` to: VERSION=`$ORACLE_HOME/bin/svrmgrl command=exit | awk ' /PL\/SQL (Release|Version)/ { print substr($3,1,3); exit } /Oracle7 Server (Release|Version)/ { print substr($4,1,3); exit } /Oracle8i Enterprise Edition (Release|Version)/ { print substr ($5,1,3); exit } /Oracle8i (Release|Version)/ { print substr($3,1,3); exit }'`
Additionally for platforms which set LD_LIBRARY_PATH in the dbstart
script you should change the following: From: LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ORACLE_HOME}/lib ; export LD_LIBRARY_PATH To: LD_LIBRARY_PATH=${ORACLE_HOME}/lib:${LD_LIBRARY_PATH} ; export LD_LIBRARY_PATH
3. Copy the updated "dbstart" to any location it is expected to reside.
Eg: system startup scripts often run /usr/local/bin/dbstart.
IMPORTANT: Do not overwrite existing scripts without taking a backup
copy first as the script you are overwriting may have been modified. NOTE: This workaround will only work for Oracle8 Enterprise Editions Similar workarounds may be used for other editions.
Explanation
The problem is caused by a change in the Oracle banner which is
output
by Oracle version 8.1.6. The banner no longer includes a PL/SQL line
and so the test in "dbstart" for a PL/SQL version returns a blank
string
which in turn causes the step to startup the instance to be skipped.
References
The problem is reported in [BUG:1154931]
The "oratab" file typically exists in either /etc/oratab or /var/opt/oracle/oratab
[NOTE:50508.1] - Advance notification of CONNECT INTERNAL desupport
Doc ID: Note:50508.1
Subject: ALERT: `CONNECT INTERNAL` Syntax to be DeSupported
Type: ALERT
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 24-DEC-1997
Last Revision Date: 20-DEC-2000
Language: USAENG
20-DEC-2000 This alert has been updated to include details of the
desupport of Server Manager and to give examples of the replacement SQLPLUS commands for connecting.
Desupport of "CONNECT INTERNAL" syntax
- NOTE: The official Server Manager Desupport notice can be seen in [NOTE:74943.1]. SQLPLUS can be used in place of Server Manager from Oracle 8.1.5 onwards.
Versions Affected
Oracle 8.1.7 will be the last release which supports the 'CONNECT INTERNAL'
syntax to connect to Oracle as an administrative user. It will also be the last release to support Server Manager.
Platforms Affected
GENERIC - All platforms will be affected by this change.
Description
"CONNECT INTERNAL" will no longer be supported AFTER Oracle8i Release 3 .
Server Manager will no longer be supported AFTER Oracle8i Release 3 .
As part of planning for future releases users are advised to convert administrative scripts to use SQLPLUS in place of SVRMGRL and to use the SYSDBA or SYSOPER privileges instead of CONNECT INTERNAL. These privileges have been available and fully documented since Oracle 7.1 .
Updating Scripts
From Oracle 7.1 onwards there are a number of ways to connect as an administrative user. These are summarised below. For most scripts it should be sufficient to replace:
CONNECT INTERNAL
with
CONNECT / AS SYSDBA
but it would be sensible to review the alternatives before making
such a
change.
Additionally , scripts which call 'svrmgrl' should be ammended thus:
Old form of command New form of command ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ svrmgrl sqlplus /nolog svrmgrl internal sqlplus "/ as sysdba" (Notice the quotation marks)
Administrative Users
There are two main administrative privileges: SYSOPER and SYSDBA
SYSOPER privilege allows operations such as:
Instance startup, mount & database open ; Instance shutdown, dismount & database close ; Alter database BACKUP, ARCHIVE LOG, and RECOVER. This privilege allows the user to perform basic operational tasks without the ability to look at user data.
SYSDBA privilege includes all SYSOPER privileges plus full system privileges
(with the ADMIN option), plus 'CREATE DATABASE' etc.. This is effectively the same set of privileges available when previously connected INTERNAL.
Password or Operating System Authentication
Password Authentication
Unless a connection to the instance is considered 'secure' then you must use a password to connect with SYSDBA or SYSOPER privilege. Users can be added to a special 'password' file using either the 'ORAPWD' utility, or 'GRANT SYSDBA to USER' command. Such a user can then connect to the instance for administrative purposes using the syntax:
CONNECT username/password AS SYSDBA
or
CONNECT username/password AS SYSOPER
Users with SYSDBA or SYSOPER privilege can be seen in the view V$PWFILE_USERS. Operating System Authentication
If the connection to the instance is local or 'secure' then it is possible
to use the operating system to determine if a user is allowed SYSDBA or
SYSOPER access. In this case no password is required. The syntax to connect
using operating system authentication is:
CONNECT / AS SYSDBA
or
CONNECT / AS SYSOPER Oracle determines if you can connect thus:
On Unix: On UNIX the Oracle executable has two group names compiled into it, one for SYSOPER and one for SYSDBA. These are known as the OSOPER and OSDBA groups. Typically these can be set when the Oracle software is installed and are set in a file called either $ORACLE_HOME/rdbms/lib/config.c or config.s . The default group for OSOPER and OSDBA is generally set to 'dba'. When you issue the command 'CONNECT / AS SYSOPER' Oracle checks if your Unix logon is a member of the 'OSOPER' group and if so allows you to connect. Similarly to connect as SYSDBA your Unix logon should be a member of the Unix 'OSDBA'group.
The OSDBA groups is the same group as has been historically
used to allow CONNECT INTERNAL.
On NT: On NT the OSOPER and OSDBA groups are hard coded names thus:
Group Name Oracle uses this as... ~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ ORA_OPER OSOPER group for all instances ORA_DBA OSDBA group for all instances ORA_sid_OPER OSOPER group for a specific Oracle SID ORA_sid_DBA OSDBA group for a specific Oracle SID When you issue a 'CONNECT / AS SYSDBA' Oracle checks if your NT logon is a member of the 'ORA_sid_DBA' or 'ORA_DBA' group. Note: 1) the 'sid' should be in upper case. 2) ensure "SQLNET.AUTHENTICATION_SERVICES = (NTS)" is set in the SQLNET.ORA file on the server.
For other platforms see the port specific documentation.
References
SYSDBA and SYSOPER Privileges
[NOTE:50507.1]
CONNECT INTERNAL in Oracle7 on UNIX
[NOTE:18089.1]
Password files
<Parameter:REMOTE_LOGIN_PASSWORDFILE>
Official Desupport Notice for CONNECT INTERNAL
[NOTE:116527.1]
Oracle SupportServices
.
[NOTE:74943.1] - Advance notification of Server Manager desupport
.
SEPTEMBER 1999
Oracle Support Services
Product Obsolescence Advisory
Product: Oracle Server Manager line mode
Platform: All platforms
Advisory Announcement:
Oracle Corporation announces the end of error correction for Oracle
Server Manager line mode, effective with the obsolescence of Oracle8i
Release 8.1, terminal release 8.1.7. Please note that Oracle 8.1.7 will
be the last release to include Oracle Server Manager. After Oracle
Release 8.1.7, Oracle Server Manager will no longer be available to
customers.
Advisory Announcement Details:
Extended Assistance Support will be provided after OracleMetals Support
has ended. Extended Assistance Support provides telephone and
electronic support only, consisting of the following:
Answers to customer questions
Known workarounds
Assist customers with migration path information
Extended Assistance Support does not include the following:
Software error correction support
Backporting of fixes
Certification with supported products or newer operating system
releases
Escalation support or, guaranteed response times
Oracle will provide Server Manager (Line Mode) supported customers a free upgrade to SQL*Plus via a restricted-use license. Customers will be able to freely use SQL*Plus to obtain Server Manager functionality. However, customers will not be able to use the extended features of SQL*Plus.
Note: SQL*Plus Release 8.1.5 and above contains all DBA functionality found in Server Manager Line Mode; earlier versions of SQL*Plus do not. For details on the differences between SQL*Plus and Server Manager or details on SQL*Plus specifically, please refer to the following Oracle8i Documentation Release 8.1.5 and above:
Chapter 10: Migrating from Server Manager to SQL*Plus of the Oracle8i
Migration Guide
SQL*Plus User's Guide and Reference
Customer Action:
To request a migration to SQL*Plus, please call 650-551-8900(CA), 719-
635-8900(CO) or 407-240-8900(FL) and route your call to Client
Relations / Customer Service. Non-U.S. customers should contact their
local Oracle Support Center.
This service announcement is addressed to the contact of record within your company. Please ensure that this letter is made available to the appropriate personnel at your site. If you are not the individual within your company to whom this notice should be sent, U.S. customers should contact Client Relations / Customer Service. Non-U.S. customers should contact their local Oracle Support Center.
This document is for informational purposes only, and is intended to outline Oracle's current plans regarding the migration path for customers under technical support. The information in this document is subject to change without notice at Oracle's discretion. Future releases of Oracle Programs that may be part of a migration path are provided, in accordance with Oracle's current transfer policies, only to customers who are current on OracleMetals Technical Support
-- David Fitzjarrell Oracle Certified DBA Sent via Deja.com http://www.deja.com/Received on Fri Jan 05 2001 - 18:39:41 CET