ChangePerm.sh: Fix SP2-0750You may need to set ORACLE_HOME to your Oracle software directory

changePerm.sh is a script that allows users that do not belong to the “dba” group to access and execute files in the ORACLE_HOME directory.

The script is located in the ORACLE_HOME/install directory on Unix and Linux systems (there is no equivalent for Windows). This script ships with Oracle Database versions 9.2.0.8, Oracle 10g and higher database releases.
[edit] When to run this script

Only run this script when absolutely required as it will reduce security.

A good hint that you need to run this script is if errors like this is reported and the environment (ORACLE_HOME) is correctly set:

$ sqlplus
Error 6 initializing SQL*Plus
Message file sp1.msb not found
SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory
Exit 1

Internal workings

The script (borne shell) loops through a hard-coded set of files and directories, extracts the “group” permissions, and set the “other” permissions the same as the group’s permissions. By doing so, “other” users are able to execute these files and change to these directories.
Example output

Sample output when the changePerm.sh script is executed:

$ cd $ORACLE_HOME/install
$ ./changePerm.sh
——————————————————————————-
Disclaimer: The purpose of this script is to relax permissions on some of the
files in the database Oracle Home so that all clients can access them.
Please note that Oracle Corporation recommends using the most restrictive file
permissions as possible for your given implementation. Running this script
should be done only after considering all security ramifications.
——————————————————————————-

-n Do you wish to continue (y/n) [n]:
y
Finished running the script successfully
Please see /tmp/changePerm_err.log for errors and /tmp/changePerm.log for the log of events

Check syntax of rman commands/script?

One can check syntax for RMAN commands without running the RMAN.

Example: Checking syntax of commands on the command line.
$ rman checksyntax

Copyright (c) 1982, 2005, Oracle. All rights reserved.

RMAN> backup database;

The command has no syntax errors

RMAN> exit

Example: Checking syntax of commands on the command script.
$ cat backup.txt
connect target /
connect catalog rmancatalog/rmancatlog@catalog

run {
backup database;
}

$ rman checksyntax @backup.txt

Recovery Manager: Release 10.2.0.1.0 – Production on Sun Nov 30 09:31:51 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

RMAN> connect target *
2> connect catalog *
3>
4> run {
5> backup database;
6> }
7>
The cmdfile has no syntax errors

Recovery Manager complete.

LOG_ARCHIVE_FORMAT format in oracle

This parameter controls the format of the archive log file name. This parameter can’t be changed on the fly therefore requires a restart of the instance. This parameter can be changed with scope=spfile if spfile is used.

If the format defined in the parameter log_archive_format is invalid the database will startup but archiver will fail to archive logs which will cause database to hang and in the alert log the following message would be reported “ORA-00294: invalid archivelog format specifier..” or you will see an error message when you try to archive the current redo log by running “ALTER SYSTEM ARCHIVE LOG CURRENT;”, so if you change this parameter a quick test can be done by running the above SQL to make sure oracle is able to archive the redo log.

Format options available on 9i:

%s – log sequence number
%S – log sequence number, zero filled
%t – thread number, needed when running RAC as each node creates it’s own archivelog
%T thread number, zero filled, needed when running RAC as each node creates it’s own archivelog

Format options available on 10g

%s – log sequence number
%S – log sequence number, zero filled
%t – thread number, needed when running RAC as each node creates it’s own archivelog
%T – thread number, zero filled, needed when running RAC as each node creates it’s own archivelog
%a – activation ID
%d – database ID
%r – resetlogs ID that ensures unique names are constructed for the archived log files across multiple incarnations of the database.

In 10g, %s, %t, %r are required to be present in the parameter, if it doesn’t the database fail to start with the error ORA-19905: log_archive_format must contain %s, %t and %r. Using this format makes it the archive log filename unique for that instance.

Rename/Purge listener logfile

The listener log file can grow over time and archive the listener log file one can’t move the file and create a new file using touch as the listener has a open/active file handle to log file causes the listener to no longer update the log file. So work around this issue one would need to do the following steps to rename the file.

# change directory to location where the listener log file resides
$ cd $ORACLE_HOME/network/log
lsnrctl set log_status off
mv listener.log listener.log.old
lsnrctl set log_status on

To purge the listener log file without restarting the listener
$ cd $ORACLE_HOME/network/log
$ echo “” > listener.log

Redirection on unix

Redirection on unix

Redirecting stdout and stderr
ls > file – redirect output to file
ls 2> filename – redirect error to file named filename
ls 2>&1 file – redirect error to where output is going to file named file
ls 1>&2 file – redirect stdout to stderr to file named file
ls > file 2> err – redirect output to file and error to file named err
exec 2> std.err – Redirect all error messages to file named std.err

Determining your Database DBID – RMAN

Determining your database DBID

In situations requiring the recovery of your SPFILE or control file from autobackup, such as disaster recovery when you have lost all database files, you will need to use your DBID. Your DBID should be recorded along with other basic information about your database, as recommended in “Deciding Between ARCHIVELOG and NOARCHIVELOG Mode”.

If you do not have a record of the DBID of your database, there are two places you can find it without opening your database.

* The DBID is used in forming the filename for the control file autobackup. Locate that file, and then refer to “Configuring the Control File Autobackup Format” to see where the DBID appears in the filename.
* If you have any text files that preserve the output from an RMAN session, the DBID is displayed by the RMAN client when it starts up and connects to your database. Typical output follows:

% rman TARGET /
Recovery Manager: Release 10.2.0.1.0 – Production on Sun Jun 12 02:41:03 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: RDBMS (DBID=774627068)

RMAN>

the DBID will be the same if you upgrade your database from lower version to higher

SGA_MAX_SIZE & SGA_TARGET

SGA_MAX_SIZE sets the overall amount of memory the SGA can consume but is not dynamic.

The SGA_MAX_SIZE parameter is the max allowable size to resize the SGA Memory area parameters. If the SGA_TARGET is set to some value then the Automatic Shared Memory Management (ASMM) is enabled, the SGA_TARGET value can be adjusted up to the SGA_MAX_SIZE parameter, not more than SGA_MAX_SIZE parameter value.

I.e. If SGA_MAX_SIZE=4GB and SGA_TARGET=2GB, later period of time, if you want you can resize your SGA_TARGET parameter to the value of SGA_MAX_SIZE i.e. 4GB, you can’t resize the SGA_TARGET value to more than 4GB.

It is significant that SGA_TARGET includes the entire memory for the SGA, in contrast to earlier releases in which memory for the internal and fixed SGA was added to the sum of the configured SGA memory parameters. Thus, SGA_TARGET gives you precise control over the size of the shared memory region allocated by the database. If SGA_TARGET is set to a value greater than SGA_MAX_SIZE at startup, then the latter is bumped up to accommodate SGA_TARGET

Do not dynamically set or unset the SGA_TARGET parameter. This should be set only at startup.