Alter database commands for beginners

Whenever the database is altered, the control file should be backed up.
alter database datafile
This is the way how the characteristics of datafiles can be changed.
alter database datafile 'DF' end backup
This command can be used for a hot backup
Note:There is no alter database datafile 'DF' begin backup command.
alter database datafile offline drop
This command is not meant to drop a datafile.
It is meant to offline the datafile with the intention of dropping the tablespace.
alter database archivelog
alter database archivelog
alter database archivelog manual
alter database noarchivelog
Alter database archivelog is simply an instruction to oracle not to overwrite an online redo log that has
not yet beenarchived. Either you archive those manually or have arch do it.
See alter system archive log start and log_archive_start.
See also archive vs noarchive log mode.
alter database backup controlfile to ['filename' | trace]
This command comes in two versions. One backs up the control file in a binary format while the other
backs it up in a human readable form. It is required if the database is running in archive log mode and
a structural change was made to the database.
Backing it up in a binary format:
alter database backup controlfile to '/some/arbitrary/path';
alter database backup controlfile to '/some/arbitrary/path' reuse;
Backing it up in a human readable format:
alter database backup controlfile to trace;
alter database backup controlfile to trace as '/some/arbitrary/path';
alter database backup controlfile to trace as '/some/arbitrary/path' reuse;
If the human readable form is chosen, the file can be made usable if the comments at the beginning are
removed and replaced with aconnect / as sysdba. If the init.ora file is not at its default location, it has to
be appended with a pfile=.... in the line containing a startup.
alter database flashback on | off
alter database flashback on;
alter database flashback off;
alter database [no] force logging
If a database is in force logging mode, all changes, except those in temporary tablespaces, will be
logged, independently from any nologging specification.
It is also possible to put arbitrary tablespaces into force logging mode: alter tablespace force logging.
A force logging might take a while to complete because it waits for all unlogged direct I/O operations to
finish.
alter database open
.. yet to be finished ..
alter database open resetlogs
Online redo logs are re-created . The log sequence is reset to 1.
If the databaseis running in archive log mode, the archived redo logs should then be deleted. Otherwise,
chances are, that Oracle will eventually try to create an archived redo log whose filename already exists.
alter database open read only
Standby database
The following alter database commands are used for a standby database environment.
alter database ACTIVATE [phisical|locigal] standby database [skip [standby logfile]]
Changes a database to an active database. This is a preprationlal step for the database to become
a primary database. The database must be mounted.
physical and logical specify what kind of database is going to be activated.
alter database SET STANDBY DATABASE TO MAXIMIZE [protection| availablity | performance]
alter database SET STANDBY DATABASE TO MAXIMIZE protection;
alter database SET STANDBY DATABASE TO MAXIMIZE availablity;
alter database SET STANDBY DATABASE TO MAXIMIZE performance;
alter database REGISTER [or replace] [physical | logical] logfile [ redo_log_file_spec [, ...]]
alter database MOUNT STANDBY database
alter database CREATE STANDBY CONTROLFILE
alter database create standby controlfile as '/some/path/to/a/file';
See creating physical standby databases: create control file
commit switchover clause
Yet to be do
alter database START LOGICAL STANDBY APPLY [ new primary dblink | initial [scn_value]]
alter database [STOP | ABORT] logical standby apply




Backup database to a tape drive using DB13
26 October, 2006 ut 6:43 um Flled under Buckup Tugged Buckup, db13, db2, tupe
In thls scenurlo, we wlll buckup the Dutubuse (DB2) to u tupe drlve und then perform urchlve once buckup ls completed.
1. Enter T-Code DB13 lnto the commund fleld.
2. Choose ut whut dute und whut tlme to perform the buckup. Cllck the ADD button.

3. You wlll see the ubove screen.
4. Flll ln the detulls of the buckup to be performed.
Actlon: Full Dutubuse Buckup to Devlce
Buckup Mode: Onllne
Devlce/ Dlrectory: flle:////tupe0
5. Cllck Add
6. Now enter the buckup tupe lnto the tupe drlve.
In thls cuse, full buckup |ob hus been schedule und wlll be perform ut 2:00AM. Once completed, you wlll huve to perform urchlve lnuctlve Log Flles to Tupe.
To do so, pleuse follow:-
*Pleuse tuke note thut euch urchlve commund ls dlfferent. Slnce I um uslng DB2, Ill use the IBM D2 commund llne utlllty

1. E|ect Insert the correct tupe curtrldge for the duy lnto the tupe drlve.
2. Go to Sturt > All Progrums > IBM DB2 > Commund Llne Tools > Commund Wlndow

3.You wlll see the ubove commund wlndow
4. Enter db2tupemgr DB PRD DOUBLE STORE on \\.\TAPE0 FORCE
5. It would tuke u whlle untll urchlve buckup log ls complete.
6. Once completed, you cun e|ect the tupe uslng db2tupemgr EJECT TAPE\\.\TAPE0 on the commund wlndow.
You huve succesfully perform buckup und urchlve log to u tupe.



Oracle RMAN Restore : Restoring Lost Database Files from Backup
This section discusses how to restore the different types of database file backed up by RMAN. Once you have an overall plan
for restoring the lost parts of your database, look here for details on how to execute the individual tasks in your plan.
This section contains the following topics:
y Restoring the Control File from Backup
y Restoring the Server Parameter File (SPFILE) from Backup
y Restoring and Recovering Datafiles and Tablespaces
y Restoring Archived Redo Logs from Backup


RESTORING THE CONTROL FILE FROM BACKUP
Loss or corruption of all copies of your control file requires restore of the control file from backup. The RESTORE
CONTROLFILE command is used to restore the control file.
Note:
After restoring the control files of your database from backup, you must perform complete media recovery of the database as described
in "Performing Media Recovery of a Restored Database, Tablespace or Datafile", and then open your database with the RESETLOGS
option. The only exception is the case described in "Restore of the Control File to a New Location", where you restore your control file to a
location not listed in the CONTROL_FILES initialization parameter. In that case, you create a copy of your control file in the specified
location without touching your running database.
RMAN can restore the control file to its default location (determined by rules described in the following section) or to one or more different
locations of your choice, using the RESTORE CONTROLFILE... TOdestination option.

6.4.1.1 Default Destination for Restore of the Control File
When restoring the control file, the default destination is all of the locations defined in the CONTROL_FILES initialization parameter. If
you do not set the CONTROL_FILES initialization parameter, the database uses the same rules to determine the destination for the
restored control file as it uses when creating a control file if theCONTROL_FILES parameter is not set. These rules are described
inOracle Database SQL Reference in the description of the CREATE CONTROLFILE statement.

Restore of the Control File from Control File Autobackup
If you are not using a recovery catalog, you must restore your control file from an autobackup. If you want to restore the control file from
autobackup, the database must be in a NOMOUNT state. You must first set the DBID for your database, and then use the RESTORE
CONTROLFILE FROM AUTOBACKUP command:
RMAN> SET DBID 320066378;
RMAN> RUN {
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE CONTROLFILE FROM AUTOBACKUP;
}

RMAN uses the autobackup format and DBID to determine where to hunt for the control file autobackup. If one is found, RMAN restores the
control file from that backup to all of the control file locations listed in the CONTROL_FILES initialization parameter.
For information on how to determine the correct value forautobackup_format, see the description of CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT in the entry for CONFIGURE inOracle Database Backup and Recovery Reference
See "Determining your DBID" for details on how to determine your DBID.

Restore of the Control File When Using a Flash Recovery Area
The commands used for restoring your control file are the same, whether or not you are using a flash recovery area. However, if you are
using a flash recovery area, RMAN updates a control file restored from backup, by performing an implicit crosscheck of all disk-based
backups and image copies listed in the control file, and cataloging any backups in the flash recovery area that are not recorded in the
restored control file. As a result the restored control file has a complete and accurate record of all backups in your flash recovery area and
any other backups that were known to the control file at the time of the backup. This improves the usefulness of the restored control file in the
restoration of the rest of your database.
Tape backups are not automatically crosschecked after the restore of a control file. If you are using tape backups, then after restoring the
control file and mounting the database you must crosscheck the backups on tape, as shown in this example:
RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;

6.4.1.4 Restoring a Control File When Using a Recovery Catalog
Restoring a lost control file from autobackup is easier when using a recovery catalog than when using only the control file to store the RMAN
repository. The recovery catalog contains a complete record of your backups, including backups of the control file. Therefore, you do not
have to specify your DBID or control file autobackup format.
To restore the control file, connect RMAN to the target database and the recovery catalog, and bring the database to NOMOUNT state. Then
issue the RESTORE CONTROLFILE command with no parameters, as in this example:
% rman TARGET rman/rman CATALOG catdb/catdb
RMAN> RESTORE CONTROLFILE;

The restored control file is written to all locations listed in theCONTROL_FILES initialization parameter.
For more details on restrictions on using RESTORE CONTROLFILE in different situations, see the discussion of RESTORE
CONTROLFILE inOracle Database Backup and Recovery Reference.

Restore of the Control File From a Known Location
You can restore the control file from a known control file copy using this form of the command:
RMAN> RESTORE CONTROLFILE from 'filename';

The control file copy found at the location specified by filename will be written to all locations listed in
the CONTROL_FILES initialization parameter.


Restore of the Control File to a New Location
One way to restore the control file to one or more new locations is to change the CONTROL_FILES initialization parameter, and then
use theRESTORE CONTROLFILE command with no arguments to restore the control file to the default locations. For example, if you
are restoring your control file after a disk failure made some but not allCONTROL_FILES locations unusable, you can
change CONTROL_FILESto replace references to the failed disk with pathnames pointing to another disk, and then run RESTORE
CONTROLFILE with no arguments.
You can also restore the control file to any location you choose other than the CONTROL_FILES locations, by using the
form RESTORE CONTROLFILE TO 'filename' [FROM AUTOBACKUP]:
RESTORE CONTROLFILE TO '/tmp/my_controlfile';

You can perform this operation with the database in NOMOUNT, MOUNT or OPEN states, because you are not overwriting any of the
control files currently in use. Any existing file named 'filename' is overwritten. After restoring the control file to a new location, you
can then update the CONTROL_FILES initialization parameter to include the new location.
See Also:
Oracle Database Backup and Recovery Reference for RESTORE CONTROLFILE syntax.

Limitations When Using a Backup Control File
After you restore your database using a backup control file, you mustrun RECOVER DATABASE and perform an OPEN
RESETLOGS on the database.
For more details on restrictions on using RESTORE CONTROLFILE in different scenarios (such as when using a recovery catalog, or
restoring from a specific backup), see the discussion of RESTORE CONTROLFILE in Oracle Database Backup and Recovery
Reference.


RESTORING THE SERVER PARAMETER FILE (SPFILE) FROM BACKUP
If you lose your server parameter file (SPFILE), RMAN can restore it to its default location or to a location of your choice.
Unlike the loss of the control file, the loss of your SPFILE does not cause your instance to immediately stop. Your instance may continue
operating, although you will have to shut it down and restart it after restoring the SPFILE.
Note the following when restoring the SPFILE:
y If the instance is already started with the server parameter file, then you cannot overwrite the existing server parameter file.
y When the instance is started with a client-side initialization parameter file, RMAN restores the SPFILE to the default SPFILE
location if the TO clause is not used. The default location is platform-specific (for example,?/dbs/spfile.ora on Linux).
y Restoring the SPFILE is one situation in which a recovery catalog can simplify your recovery procedure, because you can avoid
the step of having to record and remember your DBID. This procedure assumes that you are not using a recovery catalog.
RMAN can also create a client-side initialization parameter file based on a backup of an SPFILE.
To restore the server parameter file:
1. If the database is up at the time of the loss of the SPFILE, connect to the target database. For example, run:
2. % rman TARGET /
3.
If the database is not up when the SPFILE is lost, and you are not using a recovery catalog, then you must set the DBID of the
target database. See "Determining your DBID" for details on determining your DBID.
4. Shut down the instance and restart it without mounting. When the SPFILE is not available, RMAN starts the instance
with a dummy parameter file. For example:
5. RMAN> STARTUP FORCE NOMOUNT;
6.
7. Restore the server parameter file. If restoring to the default location, then run:
8. RMAN> RESTORE SPFILE FROM AUTOBACKUP;
9.
If restoring to a nondefault location, then you could run commands as in the following example:
RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora' FROM AUTOBACKUP;

10. Restart the instance with the restored file. If restarting with a server parameter file in a nondefault location, then create
a new client-side initialization parameter file with the single lineSPFILE=new_location, where new_location is the path
name of the restored server parameter file. Then, restart the instance with the client-side initialization parameter file.
For example, create a file /tmp/init.ora which contains the single line:
11. SPFILE=/tmp/spfileTEMP.ora
12.
Then use this RMAN command, to restart the instance based on the restored SPFILE:
RMAN> STARTUP FORCE PFILE=/tmp/init.ora; # startup with
/tmp/spfileTEMP.ora


Restore of the SPFILE from the Control File Autobackup
If you have configured control file autobackups, the SPFILE is backed up with the control file whenever an autobackup is taken.
If you want to restore the SPFILE from the autobackup, you must first set the DBID for your database, and then use the RESTORE
SPFILE FROM AUTOBACKUP command. The procedure is similar to restoring the control file from autobackup. You must first set
the DBID for your database, and then use the RESTORE CONTROLFILE FROM AUTOBACKUP command:
RMAN> SET DBID 320066378;
RMAN> RUN {
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE SPFILE FROM AUTOBACKUP;
}

RMAN uses the autobackup format and DBID to hunt for control file autobackups, and if a control file autobackup is found, restores the
SPFILE from that backup to its default location.
For information on how to determine the correct value forautobackup_format, see the description of CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT in the entry for CONFIGURE inOracle Database Backup and Recovery Reference
See "Determining your DBID" for details on how to determine your DBID.

Creating a Client-Side Initialization Parameter File (PFILE) with RMAN
You can also restore the server parameter file as a client-side initialization parameter file with the TO PFILE 'filename' clause.
The filename you specify should be on a file system accessible from the host where the RMAN client is running. This file need not be
accessible directly from the host running the instance. This command creates a PFILE called /tmp/initTEMP.ora on the system
running the RMAN client:
RMAN> RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';

To restart the instance using the client-side PFILE, use the following command, again running RMAN on the same client machine:
RMAN> STARTUP FORCE PFILE='/tmp/initTEMP.ora';


RESTORING AND RECOVERING DATAFILES AND TABLESPACES
Restoring a tablespace to its original location and performing media recovery on it is described in "Restore and Complete Recovery of
Individual Tablespaces or Datafiles: Scenario". However, you may need to restore a datafile to a location other than its original location if, for
example, the disk containing the original location of the datafiles has failed.

Restoring Datafiles from Backup to a New Location
The important step in restoring datafiles from backup to a new location is to update the control file to reflect the new locations of the datafiles.
The following example shows the use of the RMAN SET NEWNAME command to specify the new names, and the SWITCHcommand
to update the control file to start referring to the datafiles by their new names.
As with restoring datafiles from backup to their original locations, you should take the affected tablespaces offline at the start of restoring
datafiles from backup to a new location.
Then, create a RUN block to encompass your RESTORE and RECOVERcommands. For each file to be moved to a new location, use
the SETNEWNAME command to specify the new location for that file.
Then, still within the RUN block, run the RESTORE TABLESPACE orRESTORE DATAFILE as normal. RMAN restores each
datafile to the location specified with SET NEWNAME, rather than its original location.
After the RESTORE command but before the RECOVER command in your RUN block, use a SWITCH command to update the control
file with the new filenames of the datafiles. The SWITCH command is equivalent to the SQL
statement ALTER DATABASE RENAME FILE. SWITCHDATAFILE ALL updates the control file to reflect the new names for
all datafiles for which a SET NEWNAME has been issued in the RUN block.
This example restores the datafiles in tablespaces users and tools to a new location, then performs recovery. Assume that the old
datafiles were stored in directory /olddisk and the new ones will be stored in/newdisk.
RUN
{
SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
SQL 'ALTER TABLESPACE tools OFFLINE IMMEDIATE';
# specify the new location for each datafile
SET NEWNAME FOR DATAFILE '/olddisk/users01.dbf' TO
'/newdisk/users01.dbf';
SET NEWNAME FOR DATAFILE '/olddisk/tools01.dbf' TO
'/newdisk/tools01.dbf';
# to restore to an ASM disk group named dgroup, use:
# SET NEWNAME FOR DATAFILE '/olddisk/trgt/tools01.dbf'
# TO '+dgroup';
RESTORE TABLESPACE users, tools;
SWITCH DATAFILE ALL; # update control file with new filenames
RECOVER TABLESPACE users, tools;
}

If recovery is successful, then bring the tablespaces online:
SQL 'ALTER TABLESPACE users ONLINE';
SQL 'ALTER TABLESPACE tools ONLINE';
See Also:
Oracle Database Backup and Recovery Reference for SWITCH syntax


Performing Media Recovery of a Restored Database, Tablespace or Datafile
Media recovery reapplies all changes from the archived and online redo logs and available incremental backups to datafiles restored from
backup.
The simplest way to perform media reccovery is to use the RECOVER DATABASE command, with no arguments:
RMAN> RECOVER DATABASE;

You can also perform media recovery of individual tablespaces or datafiles, or skip certain tablespaces while recovering the rest of the
database, as shown in the following examples:
RMAN> RECOVER DATABASE SKIP TABLESPACE users;

RMAN> RECOVER TABLESPACE users, tools;

RMAN> RECOVER DATAFILE '/newdisk/users01.dbf','/newdisk/tools01.dbf';

RMAN> RECOVER DATAFILE 4;

RMAN will restore from backup any archived redo logs required during the recovery operation. If backups are stored on a media manager,
note that channels must be configured in advance or a RUN block with ALLOCATE CHANNEL commands must be used to enable
access to backups stored there.
One very useful option in managing disk space associated with these restored files is the DELETE ARCHIVELOG option, which
causes the deletion of restored archived redo logs from disk once they are no longer needed for the RECOVER operation:
RMAN> RECOVER TABLESPACE users, tools DELETE ARCHIVELOG;

Note that when RMAN restores archived redo log files to the flash recovery area in order to perform a RECOVER operation, the restored
logs are automatically deleted after they are applied to the datafiles, even if you do not use the DELETE ARCHIVELOG option.
See Oracle Database Backup and Recovery Reference for more details on options for the RECOVER command.

Restore and Recover of a Single Datafile to a New Location:Example
This procedure restores a single datafile to a new location and perform media recovery on it. This lets you restore and recover if the old
location is inaccessible because of a problem such as a media failure.
RUN {
SET NEWNAME FOR DATAFILE 3 to 'new_location';
RESTORE DATAFILE 3;
SWITCH DATAFILE 3;
RECOVER DATAFILE 3;
}

If you want to store a datafile to a new Oracle Managed Files location, you can use this form of the command:
RUN {
SET NEWNAME FOR DATAFILE 3 to NEW;
RESTORE DATAFILE 3;
SWITCH DATAFILE 3;
RECOVER DATAFILE 3;
}

Oracle will store the restored file in an OMF location, generating a filename for it.

RESTORING ARCHIVED REDO LOGS FROM BACKUP
RMAN will restore archived redo log files from backup automatically as needed to perform recovery.
However, you can also restore archived redo logs manually if you wish, in order to save the time needed to restoroe these files later during
the RECOVER command, or if you want to store the restored archived redo log files in some new location.
By default, RMAN restores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT and
the LOG_ARCHIVE_DEST_1parameters of the target database. These parameters are combined in a platform-specific fashion to
form the name of the restored archived log.

Restoring Archived Redo Logs to a New Location
You can override the default location for restored archived redo logs with the SET ARCHIVELOG DESTINATION command. This
command manually stages archived logs to different locations while a database restore is occurring. During recovery, RMAN knows where to
find the newly restored archived logs; it does not require them to be in the location specified in the initialization parameter file.
To restore archived redo logs to a new location:
1. After connecting to the target database, make sure the database is mounted or open.
2. Perform the following operations within a RUN block, as shown in the following example script:
1. Specify the new location for the restored archived redo logs
using SET ARCHIVELOG DESTINATION.
2. Restore the archived redo logs.
This example restores all backup archived logs to a new location:
RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE ARCHIVELOG ALL;
# restore and recover datafiles as needed
.
.
.
}

Restoring Archived Redo Logs to Multiple Locations
You can specify restore destinations for archived logs multiple times in one RUN block, in order to distribute restored logs among several
destinations. (You cannot, however specify multiple destinations simultaneously to produce multiple copies of the same log during the restore
operation.) You can use this feature to manage disk space used to contain the restored logs.
This example restores 300 archived redo logs from backup, distributing them across the directories /fs1/tmp, /fs2/tmp,
and/fs3/tmp:
RUN
{
# Set a new location for logs 1 through 100.
SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100;
# Set a new location for logs 101 through 200.
SET ARCHIVELOG DESTINATION TO '/fs2/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
# Set a new location for logs 201 through 300.
SET ARCHIVELOG DESTINATION TO '/fs3/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
# restore and recover datafiles as needed
.
.
.
}

When you issue a RECOVER command, RMAN finds the needed restored archived logs automatically across the destinations to which
they were restored, and applies them to the datafiles.

ALTER TABLESPACE
Purpose
Use the ALTER TABLESPACE statement to alter an existing tablespace or one or more of its
datafiles or tempfiles.
You cannot use this statement to convert a dictionary-managed tablespace to a locally
managed tablespace. For that purpose, use theDBMS_SPACE_ADMIN package, which is
documented in PL/SQL Packages and Types Reference.
See Also:
Oracle Database Administrator's Guide and CREATE TABLESPACE for information on creating
a tablespace
Prerequisites
To alter the SYSAUX tablespace, you must have the SYSDBA system privilege.
If you have ALTER TABLESPACE system privilege, then you can perform
anyALTER TABLESPACE operation. If you have MANAGE TABLESPACE system privilege, then
you can only perform the following operations:
y Take the tablespace online or offline
y Begin or end a backup
y Make the tablespace read only or read write
Before you can make a tablespace read only, the following conditions must be met:
y The tablespace must be online.
y The tablespace must not contain any active rollback segments. For this reason,
the SYSTEM tablespace can never be made read only, because it contains
the SYSTEM rollback segment. Additionally, because the rollback segments of a read-only
tablespace are not accessible, Oracle recommends that you drop the rollback segments
before you make a tablespace read only.
y The tablespace must not be involved in an open backup, because the end of a backup updates
the header file of all datafiles in the tablespace.
Performing this function in restricted mode may help you meet these restrictions, because
only users with RESTRICTED SESSION system privilege can be logged on.
Syntax
alter_tablespace::=

Description of the illustration alter_tablespace.gif
(table_compression ::=--part
of ALTER TABLE, storage_clause::=,size_clause::=, datafile_tempfile_clauses ::=, tablespac
e_logging_clauses::=, tablespace_group_clause::=, tablespace_state_clauses::=,autoexten
d_clause ::=, flashback_mode_clause ::=,tablespace_retention_clause::=)
datafile_tempfile_clauses ::=

Description of the illustration datafile_tempfile_clauses.gif
(file_specification::=).
tablespace_logging_clauses ::=

Description of the illustration tablespace_logging_clauses.gif
(logging_clause::=)
tablespace_group_clause::=

Description of the illustration tablespace_group_clause.gif

tablespace_state_clauses::=

Description of the illustration tablespace_state_clauses.gif

autoextend_clause ::=

Description of the illustration autoextend_clause.gif
(size_clause::=)
maxsize_clause::=

Description of the illustration maxsize_clause.gif
(size_clause::=)
flashback_mode_clause ::=

Description of the illustration flashback_mode_clause.gif

tablespace_retention_clause::=

Description of the illustration tablespace_retention_clause.gif

Semantics
tablespace
Specify the name of the tablespace to be altered.
Restrictions on Altering Tablespaces Altering tablespaces is subject to the following
restrictions:
y If tablespace is an undo tablespace, then the only other clauses you can specify in this
statement are ADD DATAFILE, RENAME DATAFILE,RENAME TO (renaming the
tablespace), DATAFILE ... ONLINE,DATAFILE ... OFFLINE, BEGIN BACKUP,
and END BACKUP.
y You cannot make the SYSTEM tablespace read only or temporary and you cannot take it
offline.
y For locally managed temporary tablespaces, the only clause you can specify in this statement
is the ADD clause.
See Also:
Oracle Database Administrator's Guide for information on automatic undo management and
undo tablespaces
DEFAULT storage_clause
DEFAULT storage_clause lets you specify the new default storage parameters for objects
subsequently created in the tablespace. For a dictionary-managed temporary table, Oracle
Database considers only the NEXT parameter of thestorage_clause.
Please refer to the storage_clause for more information.
Restriction on Default Tablespace Storage You cannot specify this clause for a locally
managed tablespace.
MINIMUM EXTENT
This clause is valid only for permanent dictionary-managed tablespaces.
TheMINIMUM EXTENT clause lets you control free space fragmentation in the tablespace by
ensuring that every used or free extent in a tablespace is at least as large as, and is a
multiple of, the value specified in the size_clause.
Restriction on MINIMUM EXTENT You cannot specify this clause for a locally managed
tablespace or for a dictionary-managed temporary tablespace.
See Also:
size_clause for information about that clause, Oracle Database Administrator's Guide for
more information about using MINIMUM EXTENT to control space fragmentation
RESIZE Clause
This clause is valid only for bigfile tablespaces. It lets you increase or decrease the size of
the single datafile to an absolute size. Use K, M, G, or Tto specify the size in kilobytes,
megabytes, gigabytes, or terabytes, respectively.
To change the size of a newly added datafile or tempfile in smallfile tablespaces, use
the ALTER DATABASE ... autoextend_clause (seedatabase_file_clauses ).
See Also:
BIGFILE | SMALLFILE for information on bigfile tablespaces
COALESCE
For each datafile in the tablespace, this clause combines all contiguous free extents into
larger contiguous extents.
RENAME Clause
Use this clause to rename tablespace. This clause is valid only if tablespaceand all its
datafiles are online and the COMPATIBLE parameter is set to 10.0.0 or greater. You can
rename both permanent and temporary tablespaces.
If tablespace is read only, then Oracle Database does not update the datafile headers to
reflect the new name. The alert log will indicate that the datafile headers have not been
updated.
Note:
If you re-create the control file, and if the datafiles that Oracle Database uses for this
purpose are restored backups whose headers reflect the old tablespace name, then the re-
created control file will also reflect the old tablespace name. However, after the database is
fully recovered, the control file will reflect the new name.
If tablespace has been designated as the undo tablespace for any instance in a Real
Application Clusters environment, and if a server parameter file was used to start up the
database, then Oracle Database changes the value of the UNDO_TABLESPACE parameter for
that instance in the server parameter file (SPFILE) to reflect the new tablespace name. If a
single-instance database is using a parameter file (pfile) instead of an spfile, then the
database puts a message in the alert log advising the database administrator to change the
value manually in the pfile.
Restriction on Renaming Tablespaces You cannot rename
the SYSTEM orSYSAUX tablespaces.
BACKUP Clauses
Use these clauses to move all datafiles in a tablespace into or out of online (sometimes
called hot) backup mode.
See Also:
y Oracle Database Administrator's Guide for information on restarting the database without
media recovery
y ALTER DATABASE "BACKUP Clauses" for information on moving all datafiles in the database
into and out of online backup mode
y ALTER DATABASE alter_datafile_clause for information on taking individual datafiles out of
online backup mode
BEGIN BACKUP
Specify BEGIN BACKUP to indicate that an open backup is to be performed on the datafiles
that make up this tablespace. This clause does not prevent users from accessing the
tablespace. You must use this clause before beginning an open backup.
Restrictions on Beginning Tablespace Backup Beginning tablespace backup is subject to the
following restrictions:
y You cannot specify this clause for a read-only tablespace or for a temporary locally managed
tablespace.
y While the backup is in progress, you cannot take the tablespace offline normally, shut down
the instance, or begin another backup of the tablespace.
See Also:
"Backing Up Tablespaces: Examples"
END BACKUP
Specify END BACKUP to indicate that an online backup of the tablespace is complete. Use
this clause as soon as possible after completing an online backup. Otherwise, if an instance
failure or SHUTDOWN ABORT occurs, then Oracle Database assumes that media recovery
(possibly requiring archived redo log) is necessary at the next instance startup.
Restriction on Ending Tablespace Backup You cannot use this clause on a read-only
tablespace.
datafile_tempfile_clauses
The tablespace file clauses let you add or modify a datafile or tempfile.
ADD Clause
Specify ADD to add to the tablespace a datafile or tempfile specified byfile_specification.
Use the datafile_tempfile_spec form of file_specification(see file_specification) to list regular
datafiles and tempfiles in an operating system file system or to list Automatic Storage
Management disk group files.
For locally managed temporary tablespaces, this is the only clause you can specify at any
time.
If you omit file_specification, then Oracle Database creates an Oracle-managed file of 100M
with AUTOEXTEND enabled.
You can add a datafile or tempfile to a locally managed tablespace that is online or to a
dictionary managed tablespace that is online or offline. Ensure the file is not in use by
another database.
Restriction on Adding Datafiles and Tempfiles You cannot specify this clause for a bigfile
(single-file) tablespace, as such a tablespace has only one datafile or tempfile.
Note:
On some operating systems, Oracle does not allocate space for a tempfile until the tempfile
blocks are actually accessed. This delay in space allocation results in faster creation and
resizing of tempfiles, but it requires that sufficient disk space is available when the tempfiles
are later used. To avoid potential problems, before you create or resize a tempfile, ensure
that the available disk space exceeds the size of the new tempfile or the increased size of a
resized tempfile. The excess space should allow for anticipated increases in disk space use
by unrelated operations as well. Then proceed with the creation or resizing operation.
See Also:
file_specification, "Adding and Dropping Datafiles and Tempfiles: Examples", and "Adding an
Oracle-managed Datafile: Example"
DROP Clause
Specify DROP to drop from the tablespace an empty datafile or tempfile specified
by filename or file_number. This clause causes the datafile or tempfile to be removed from
the data dictionary and deleted from the operating system. The database must be open at
the time this clause is specified.
The ALTER TABLESPACE ... DROP TEMPFILE statement is equivalent to specifying
the ALTER DATABASE TEMPFILE ... DROP INCLUDING DATAFILES.
Restrictions on Dropping Files To drop a datafile or tempfile, the datafile or tempfile:
y Must be empty.
y Cannot be the first file that was created in the tablespace. In such cases, drop the tablespace
instead.
y Cannot be in a read-only tablespace.
See Also:
y ALTER DATABASE alter_tempfile_clause for additional information on dropping tempfiles
y Oracle Database Administrator's Guide for information on datafile numbers and for guidelines
on managing datafiles
y "Adding and Dropping Datafiles and Tempfiles: Examples"
RENAME DATAFILE Clause
Specify RENAME DATAFILE to rename one or more of the tablespace datafiles. The database
must be open, and you must take the tablespace offline before renaming it.
Each filename must fully specify a datafile using the conventions for filenames on your
operating system.
This clause merely associates the tablespace with the new file rather than the old one. This
clause does not actually change the name of the operating system file. You must change the
name of the file through your operating system.
See Also:
"Moving and Renaming Tablespaces: Example"
ONLINE | OFFLINE Clauses
Use these clauses to take all datafiles or tempfiles in the tablespace offline or put them
online. These clauses have no effect on the ONLINE or OFFLINEstatus of the tablespace
itself.
The database must be mounted. If tablespace is SYSTEM, or an undo tablespace, or the
default temporary tablespace, then the database must not be open.
tablespace_logging_clauses
Use these clauses to set or change the logging characteristics of the tablespace.
logging_clause
Specify LOGGING if you want logging of all tables, indexes, and partitions within the
tablespace. The tablespace-level logging attribute can be overridden by logging
specifications at the table, index, and partition levels.
When an existing tablespace logging attribute is changed by
an ALTERTABLESPACE statement, all tables, indexes, and partitions created after the
statement will have the new default logging attribute (which you can still subsequently
override). The logging attribute of existing objects is not changed.
If the tablespace is in FORCE LOGGING mode, then you can specifyNOLOGGING in this
statement to set the default logging mode of the tablespace to NOLOGGING, but this will
not take the tablespace out of FORCELOGGING mode.
[NO] FORCE LOGGING
Use this clause to put the tablespace in force logging mode or take it out of force logging
mode. The database must be open and in READ WRITE mode. Neither of these settings
changes the default LOGGING or NOLOGGING mode of the tablespace.
Restriction on Force Logging Mode You cannot specify FORCE LOGGING for an undo or a
temporary tablespace.
See Also:
Oracle Database Administrator's Guide for information on when to
use FORCELOGGING mode and "Changing Tablespace Logging Attributes: Example"
tablespace_group_clause
This clause is valid only for locally managed temporary tablespaces. Use this clause to
add tablespace to or remove it from the tablespace_group_nametablespace group.
y Specify a group name to indicate that tablespace is a member of this tablespace group.
If tablespace_group_name does not already exist, then Oracle Database implicitly creates it
when you alter tablespace to be a member of it.
y Specify an empty string (' ') to remove tablespace from
thetablespace_group_name tablespace group.
Restriction on Tablespace Groups You cannot specify a tablespace group for a permanent
tablespace or for a dictionary-managed temporary tablespace.
See Also:
Oracle Database Administrator's Guide for more information on tablespace groups
and "Assigning a Tablespace Group: Example"
tablespace_state_clauses
Use these clauses to set or change the state of the tablespace.
ONLINE | OFFLINE
Specify ONLINE to bring the tablespace online. Specify OFFLINE to take the tablespace
offline and prevent further access to its segments. When you take a tablespace offline, all of
its datafiles are also offline.
Suggestion:
Before taking a tablespace offline for a long time, consider changing the tablespace
allocation of any users who have been assigned the tablespace as either a default or
temporary tablespace. While the tablespace is offline, such users cannot allocate space for
objects or sort areas in the tablespace. SeeALTER USER for more information on allocating
tablespace quota to users.
Restriction on Taking Tablespaces Offline You cannot take a temporary tablespace offline.
OFFLINE NORMAL Specify NORMAL to flush all blocks in all datafiles in the tablespace out of
the system global area (SGA). You need not perform media recovery on this tablespace
before bringing it back online. This is the default.
OFFLINE TEMPORARY If you specify TEMPORARY, then Oracle Database performs a
checkpoint for all online datafiles in the tablespace but does not ensure that all files can be
written. Files that are offline when you issue this statement may require media recovery
before you bring the tablespace back online.
OFFLINE IMMEDIATE If you specify IMMEDIATE, then Oracle Database does not ensure that
tablespace files are available and does not perform a checkpoint. You must perform media
recovery on the tablespace before bringing it back online.
Note:
The FOR RECOVER setting for ALTER TABLESPACE ... OFFLINE has been deprecated. The
syntax is supported for backward compatibility. However, Oracle recommends that you use
the transportable tablespaces feature for tablespace recovery.
See Also:
Oracle Database Backup and Recovery Advanced User's Guide for information on using
transportable tablespaces to perform media recovery
READ ONLY | READ WRITE
Specify READ ONLY to place the tablespace in transition read-only mode. In this state,
existing transactions can complete (commit or roll back), but no further DML operations are
allowed to the tablespace except for rollback of existing transactions that previously
modified blocks in the tablespace. You cannot make the SYSAUX tablespace READ ONLY.
When a tablespace is read only, you can copy its files to read-only media. You must then
rename the datafiles in the control file to point to the new location by using the SQL
statement ALTER DATABASE ... RENAME.
See Also:
y Oracle Database Concepts for more information on read-only tablespaces
y ALTER DATABASE
Specify READ WRITE to indicate that write operations are allowed on a previously read-only
tablespace.
PERMANENT | TEMPORARY
Specify PERMANENT to indicate that the tablespace is to be converted from a temporary to
a permanent tablespace. A permanent tablespace is one in which permanent database
objects can be stored. This is the default when a tablespace is created.
Specify TEMPORARY to indicate that the tablespace is to be converted from a permanent to
a temporary tablespace. A temporary tablespace is one in which no permanent database
objects can be stored. Objects in a temporary tablespace persist only for the duration of the
session.
Restrictions on Temporary Tablespaces Temporary tablespaces are subject to the following
restrictions:
y You cannot specify TEMPORARY for the SYSAUX tablespace.
y If tablespace was not created with a standard block size, then you cannot change it from
permanent to temporary.
y You cannot specify TEMPORARY for a tablespace in FORCE LOGGINGmode.
autoextend_clause
This clause is valid only for bigfile (single-file) tablespaces. Use this clause to enable or
disable autoextension of the single datafile in the tablespace. To enable or disable
autoextension of a newly added datafile or tempfile in smallfile tablespaces, use
the autoextend_clause of the database_file_clausesin the ALTER DATABASE statement.
See Also:
y Oracle Database Administrator's Guide for information about bigfile (single-file) tablespaces
y file_specification for more information about the autoextend_clause
flashback_mode_clause
Use this clause to specify whether this tablespace should participate in any
subsequent FLASHBACK DATABASE operation.
y For you to turn FLASHBACK mode on, the database must be mounted, either open or closed
y For you to turn FLASHBACK mode off, the database must be mounted and closed.
This clause is not valid for temporary tablespaces.
Please refer to CREATE TABLESPACE for more complete information on this clause.
See Also:
Oracle Database Backup and Recovery Advanced User's Guide for more information about
Flashback Database
tablespace_retention_clause
This clause has the same semantics
in CREATE TABLESPACE and ALTERTABLESPACE statements. Please refer
to tablespace_retention_clause in the documentation on CREATE TABLESPACE.
Examples
Backing Up Tablespaces: Examples The following statement signals to the database that a
backup is about to begin:
ALTER TABLESPACE tbs_01
BEGIN BACKUP;

The following statement signals to the database that the backup is finished:
ALTER TABLESPACE tbs_01
END BACKUP;
Moving and Renaming Tablespaces: Example This example moves and renames a datafile
associated with the tbs_02 tablespace, created in "Enabling Autoextend for a Tablespace:
Example", from diskb:tbs_f5.dat todiska:tbs_f5.dat:
1. Take the tablespace offline using an ALTER TABLESPACE statement with the OFFLINE clause:
2. ALTER TABLESPACE tbs_02 OFFLINE NORMAL;
3.
4. Copy the file from diskb:tbs_f5.dat to diska:tbs_f5.dat using your operating system
commands.
5. Rename the datafile using an ALTER TABLESPACE statement with
theRENAME DATAFILE clause:
6. ALTER TABLESPACE tbs_02
7. RENAME DATAFILE 'diskb:tbs_f5.dat'
8. TO 'diska:tbs_f5.dat';
9.
10. Bring the tablespace back online using an ALTER TABLESPACEstatement with
the ONLINE clause:
11. ALTER TABLESPACE tbs_02 ONLINE;
Adding and Dropping Datafiles and Tempfiles: Examples The following statement adds a
datafile to the tablespace. When more space is needed, new 10-kilobytes extents will be
added up to a maximum of 100 kilobytes:
ALTER TABLESPACE tbs_03
ADD DATAFILE 'tbs_f04.dbf'
SIZE 100K
AUTOEXTEND ON
NEXT 10K
MAXSIZE 100K;

The following statement drops the empty datafile:
ALTER TABLESPACE tbs_03
DROP DATAFILE 'tbs_f04.dbf';

The following statements add a tempfile to the temporary tablespace created in "Creating a
Temporary Tablespace: Example" and then drops the tempfile:
ALTER TABLESPACE temp_demo ADD TEMPFILE 'temp05.dbf' SIZE 5 AUTOEXTEND ON;

ALTER TABLESPACE temp_demo DROP TEMPFILE 'temp05.dbf';
Adding an Oracle-managed Datafile: Example The following example adds an Oracle-
managed datafile to the omf_ts1 tablespace (see "Creating Oracle-managed Files:
Examples" for the creation of this tablespace). The new datafile is 100M and is
autoextensible with unlimited maximum size:
ALTER TABLESPACE omf_ts1 ADD DATAFILE;
Changing Tablespace Logging Attributes: Example The following example changes the
default logging attribute of a tablespace to NOLOGGING:
ALTER TABLESPACE tbs_03 NOLOGGING;

Altering a tablespace logging attribute has no affect on the logging attributes of the existing
schema objects within the tablespace. The tablespace-level logging attribute can be
overridden by logging specifications at the table, index, and partition levels.
Changing Undo Data Retention: Examples The following statement changes the undo data
retention for tablespace undots1 to normal undo data behavior:
ALTER TABLESPACE undots1
RETENTION NOGUARANTEE;

The following statement changes the undo data retention for tablespaceundots1 to behavior
that preserves unexpired undo data:
ALTER TABLESPACE undots1
RETENTION GUARANTEE;


GRMG configuration for TREX system
1.Log on to the TREX host as root
2. Go to the directory . : /usr/sap/TPZ/TRX10
Set the environment variables required by TREX by executing the following scripts.
. TREXSettings.sh


3. Go to the directory /exe/CCMS, in which the script for installing the TREX monitoring functions is
located

4.Execute the following command to configure monitoring of availability (heartbeat/GRMG):
python ccms_config.py --grmg



Created GRMG upload file at location :
/usr/sap/TPZ/TRX10/hostname/trace/grmg/GRMG_config.TPZ_10.hostname.xml

Uploading XML Customizing File by Transaction GRMG
1. Start transaction GRMGin the SAP system.
2. Choose Upload/Download.
There are two ways to upload the TREX scenario:
Choose Upload/Download p Upload Scenario.


Choose the XML customizing file for the corresponding TREX instance and chooseOpen.

The window GRMG customizing file uploaded successfully appears.


Choose Upload/Download p Poll agents for new scenarios.

This upload of the TREX scenario will only work if the SAPCCMSR agent is running and has been
registered previously.
In the list GRMG Scenarios for Availability Monitoring, choose the corresponding TREX scenario.
Choose Start/Stop p Start Scenarios.
The window GRMG scenarios have started appears.




Posted by MY BLOG at 10:10 PM 1 comments
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Google Buzz
THURSDAY, APRIL 8, 2010
Oracle Bundle Patch
How to Apply Oracle Bundle Patch

Download the dump from SAP service market place to your system.
1.PRE INSTALLATION INSTRUCTIONS
Copy the dumps of patch at below mentioned path.
Drive/oracle/"SID"/"oracle version"/OPatch

Stop SAP & DB along with all services of SAP & DB.
Back up the current database that is installed, the %ORACLE_HOME% directory and Oracle inventory under c:\Program
files\oracle directory. (This will help if there are problems applying the patch, and to restore the Inventory in case of an
issue with the patch.)
Now apply bundle patch.
OPatch>opatch apply patch no
Installation may be interrupted coz. of error in overwriting an existing .dll file giving following error file already in use.
In case of above error dont rename the file and RETRY(It doesnt work) instead cancel the installation then and there rename
the .dll file and start patch application again.
3. POST INSTALLATION INSTRUCTIONS
Start all services of DB & DB
Run script catcpu.sql
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @%ORACLE_HOME%\Bundle\Patch17\catcpu.sql
SQL> QUIT
If above script reports any error then
Inspect the logfile %ORACLE_HOME%\Bundle\Patch17\Apply__.log for any errors.
If catcpu.sql reports any Invalid Objects, compile the invalid objects as follows.
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @%ORACLE_HOME%\rdbms\admin\utlprp.sql 0
Above script will compile the invalid objects.
To check for any invalid objects still there or not, execute the following statement:
SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS = 'INVALID';
Recompiling Views in the Database
To recompile the views for each database instance running out of the ORACLE_HOME being patched , follow these steps:
Run the pre-check script, which reports the maximum number of views and objects that may be recompiled:
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @%ORACLE_HOME%\Bundle\view_recompile\ recompile_precheck_jan2009cpu.sql
SQL> QUIT
Run the view recompilation script. Note that this script is run with the database in upgrade mode, which restricts
connections as SYSDBA.
sqlplus /nolog
SQL> SHUTDOWN
SQL> CONNECT / AS SYSDBA
SQL> STARTUP UPGRADE
SQL>@%ORACLE_HOME%\Bundle\view_recompile\
view_recompile_jan2008cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP;
Check the log file for any errors. The log file is in the current directory and is named: vcomp__.log
If any invalid objects were reported, run the utlrp.sql script as follows:
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @%ORACLE_HOME%\rdbms\admin\utlrp.sql
If still any invalid objects are there then recompile those manually.
SQL> alter schemaname. compile;
Verify that the view recompilation has been performed for the database, by executing the following statement:
SELECT * FROM registry$history where ID = '6452863';
TO VIEW ALL PATCHES APPLIED ISSUE BELOW COMMAND:-
\ORACLE\"SID"\"oracle version"\OPATCH>OPATCH LSINVENTORY
SAP Test system refresh activity
SAP Test system refresh activity.

Follow the below steps for SAP test system refresh activity from Production server backup.
1. Take the relevant screenshot of system
STMS, SCC4, SM59, SAP standard jobs, DB13, SLICENSE, CCMS settings, SPAD
2. Import the SPAD settings
3. Take the offline backup of production system
4. Take the backup of backSID.log,*.aft and initSID.ora of production and test server
5. Lock users in Test system
6. Take offline backup of test system
7. Open client in test server : SCC4
8. Export the client for profile SAP_USER in test server. Keep test system as target server
SCC8
9. Take the trace of control file on both the Test and production server
10. Stop the SAP instance and sap services
11. Note down the Schema users existing presently in the system.
SQL> select user name from dba_users;
12. Shutdown the database
13. Copy last offline backup log file(*.aft) from production system to test server
14. edit the *.aft log file as per test server
change SID from prdoduction to test server SID, check ORA-HOME directory
15. Now restore the backup
brrestore c m full b XXX.aft
16. Connect to oracle as sqlplus /nolog, connect /as sysdba and type startup Nomount.
17. Edit the controlfile of Prod. Change all production SID to test SID and NORESETLOGS TO RESETLOGS.
17. Use the edited controlfile of Prod to recreate the control file of Test
SQL> @Cntrl.sql
SQL>shutdown immediate;
18. SQL> Alter database open RESETLOGS.
19. Create new OPS$ADM using the below command.
I:\scripts>sqlplus /nolog @ORADBUSER.sql SAPSID NT DOMAIN SID (IF SIDADM is local user then give the host name in the place of
Domain Name)
20. After this run the script sapdba_role to set proper right for OPS$ user IDs.
>sqlplus /nolog @sapdba_role.sql
21. Check whether SAPSR3P (schema owner) account has been locked or not:
select username,account_status from dba_users where username=SAPPCE;
22. If it is locked use this command to unlock it:
alter user SAPPCE account unlock;
23. Start the SAP application.
POST Processing Steps:
24. Update the license
Logon to SAP with DDIC-client 000; update the license key through the transaction SLICENSE.
25. check the consistency
Go to transaction SICK for checking the consistency of the system.
26. check the local host entry
Go to transaction SE37 and execute BPT_LOCAL_HOSTNAME_CHECK to check for the hostname entry.
27. Change the STMS configuration and perform post installation activity
Now go to transaction SE06 to perform post installation activities
28. Reconfiguring STMS
29. Login into DCE client 000 with DDIC , goto transaction STMS.
30. Schedule the standard jobs
Go to transaction SM36 and click on the button Standard jobs to schedule the standard jobs defined for the system.
31. Import the user master of test server
Goto the STMS and import the user master request
32. Close the client
33. Changing the client description.
34. Import profiles of active Server using RZ10.
35. Delete incorrect instances defined in RZ04, create correct instances and assign Operation modes for the same
36. Change the logical system name
37. Take an OFFLINE backup of the Test system and release the system to the users.


The entire procedure for DRS switchover
PRODUCTION TO DRS SWITCHOVER

1. Take Offline backup of the PRD Database.

2. In SM02, Put message on the PRD system.

3. On PRD,

cmd>SVRMGR30
Connect Internal;
Alter system switch logfile;
Do switch log file 3-4 times.

4. In DRS, apply up to the last Archive Log created in PRD.

5. On PRD, Stop R/3, Shutdown Database And Stop SAP & Oracle Services.

6. On PRD, Backup Mirrlog A, Mirrlog B, Origlog A, Origlog B & Control file of PRD.

7. Shutdown DRS Database & Stop Oracle Services.

8. On DRS, Backup Mirrlog A, Mirrlog B, Origlog A, Origlog B & Control file of DRS.

9. Copy the redo log files & control files from PRD (production DB System) to DRS (DRS DB System). Copy the control file to all the
locations on DRS (OriglogA, Saparch & Sapdata1 sub-folders).

10. Start the Oracle Services on DRS.

11. In DRS
Start SVRMGR30
Connect Internal;
Startup Mount;
Recover Database; (Ensure the message Media Recovery Complete appears).
Alter databases Open; (This opens in NORESETLOGS mode).
Exit;
12. Start SAPOSCOL, SAP_00 services on DRS.

13. Start SAP R/3 application on DRS.

14. Logon to the DRS System through SAP Logon Pad.

15. Check the System Status & transactions like SM51, ST22, and SM21 Etc.


DRS TO PRODUCTION SWITCHOVER

16. On DRS, Stop R/3, Shutdown Database and Stop SAP & Oracle Services.

17. Copy the redo log files & control files from DRS (DRS DB System) to PRD (production DB System). Copy the control file to all the
locations on PRD (OriglogA, Saparch & Sapdata1 sub-folders).

18. Start the Oracle services on the DRS.

19. Start the Oracle Services on PRD.

20. In PRD
Start SVRMGR30
Connect Internal;
Startup Mount;
Recover Database; (Ensure the message Media Recovery Complete appears).
Alter databases Open; (This opens in NORESETLOGS mode).
Exit;
21. Start SAPOSCOL, SAP_00 services on PRD.

22. Start SAP R/3 application on PRD.

23. Logon to the PRD System through SAP Logon Pad.

24. Check the System Status & transactions like SM51, ST22, and SM21 Etc.
Note: - DRS: DRS database server
PRD: Production database server

Posted by MY BLOG at 6:51 AM 2 comments
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Google Buzz
FRIDAY, APRIL 10, 2009
Explain the client create, delete and copy?
y We can create a client using the transaction SCC4. Mention the client name with the
appropriate selection.
Note that SAP delivers the software with standard clients 000 and 001. You may not work in
client 000, but may use client 001. However, SAPrecommends that you begin SAP System
implementation by creating a new client as a copy of client 000.

y To Copy a client
o A local client copy copies between clients within the sameSAP System.
o A remote client copy allows you to copy between clients in different SAP Systems.You
can use a remote client copy to, for example, transport client-dependent as well client-independent
Customizing data between SAP Systems.
o A remote client copy proceeds in the same way as a local copy, but sends the data
through a remote function call (RFC) connection to the target client.
o A remote client copy is easy to use, and does not require file system space on
operating system level.
o The limitations of a remote client copy are as follows:
A remote client copy does not create a file at operating system level, so there is
no "hard copy" of the client to be copied. Therefore, the same, identical client
copy cannot be duplicated at a later date.
y To delete a client from within SAP System:
o Log on to the client to be deleted.
o Use the menu option use Transaction code SCC5 or from theSAP System initial screen
choose Tools _ Administration _Administration _ Client admin _ Special functions _ Delete client.
o Start the deletion of the client, preferably using background processing.
o When you delete a client entry from table T000 with client maintenance
(Transaction SCC4), you can no longer log on to the client or update it using change requests. The
deletion process, however, does not eliminate the data belong to the client. This means the client-
dependent data remains in yourSAP System, occupying space in the database. Therefore, to eliminate
an SAP client entirely, that is, to delete both the client and the client-dependent data, use the client
delete functionality (Transaction SCC5).
o Deleting a client entry with client maintenance (TransactionSCC4) allows you to
temporarily lock the client. The deletion procedure preserves the data for the client but prevents users
from logging on to the client or accessing the data belonging to the client. To restore the client and
allow logon, recreate the client entry using client maintenance.
o The amount of time required for the deletion of a client can be reduced by performing
the deletion using parallel processes.
Posted by MY BLOG at 10:50 PM 3 comments
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Google Buzz
TUESDAY, APRIL 7, 2009
SAP Basis critical object : S_BTCH_JOB
Definition


You use this object to assign users authorizations for all operations except scheduling. For example, you could assign users authorization
to delete their own jobs.

This object is used to check all critical administration operations for background processing (Tools -> Administration -> Jobs -> Job overview.

Users do not need an authorization for this object to schedule background jobs; an authorization is normally not required for end users.

Exception: If background jobs are to be automatically released after scheduling, your users should have the authorization for value RELE
so that the scheduled jobs are automatically released.

An authorization for this object means users have authorization for their own jobs in their current client. To assign a user
administration authorization for all users and all clients, use authorization Background Processing: Background Administrator.

Defined fields

Operations on one job consists of the following fields:

o Functions: Operations the user is allowed to perform. Possible values are:

- DELE: Delete background jobs

- LIST: Display spool requests created by jobs

- PLAN: Copy or repeat jobs

- PROT: Display job processing logs

- RELE: Release jobs (automatic release after scheduling possible)

- SHOW: Display job queue

- Job group: Names of permitted job groups. Reserved: Set to *.

Example

With this authorization, users can release and delete their own background jobs in job administration. The users' jobs are also automatically
released after scheduling.

Field Value Operations on a job DELE RELE Job group *
Posted by MY BLOG at 10:47 PM 1 comments
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Google Buzz
SAP Basis critical object : S_USER_PRO
S_USER_PRO

Definition

Authorization object, which is checked during authorization maintenance.

The check is made in the following profile maintenance transactions
(Tools -> Administration -> User maintenance).

o SU02 (Maintain profiles)

o SU01 (Assign profile to user)

o SU10 (Assign profile to all users or remove assignment to all users)

Defined fields

The object is defined with the following fields:

o Authorization profile: In this field, you must enter the
authorization profiles that an authorization administrator may
maintain or that a user administrator may assign to his users.

o Activity: In this field, you can limit what the administrator is
allowed to do with the profile.
Possible values:

- 01: Create

- 02: Change

- 03: Display

- 06: Delete

- 07: Activate

- 08: Display change documents

- 22: Assign profile to users / remove assignment

- 24: Archive

Example
Field Values
Profile name *
Activity 01 - 06

This authorization allows the authorization administrator to create,
maintain, delete and display profiles at will. However, he may not
activate profiles or display change documents.