Featured

    Featured Posts

Differences between SYSOPER and SYSDBA Privileges:


SYSOPER
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 can do more than start/stop the database. It has a lot more functionality that sysoper (Operator mode) which is normally used for basic database functions such as start/stop.

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.


Note:
1.SYSDBA and SYSOPER are system privileges and don't misunderstand with DBA.
2.DBA is a role which includes all system privileges excluding sysdba and sysoper.
3.sysdba and sysoper can be granted to user for administrative tasks by sys user.

Renaming/Relocating a Datafile from original location to new location?

We can achieve this task in two ways..ie,
1.Offline method. 2.Online method.
To rename/relocate the datafile from the original location to new location, tablespace should be offline first. otherwise the following error is encountered.
ORA-01511: error in renaming log/data files
ORA-01121: cannot rename database file <string> – file is in use or recoveryORA-01110: data file <string>: ‘datafile.dbf’
Method 1:
  1. Login to SQLPlus.
  2. Connect as SYS DBA with CONNECT / AS SYSDBA command.
  3. Shutdown the database instance with SHUTDOWN command.
  4. Rename or/and move the datafiles at operating system level.
  5. Start Oracle database in mount state with STARTUP MOUNT command.
  6. Modify the name or location of datafiles in Oracle data dictionary using following command syntax:
  7. Open Oracle database instance completely with ALTER DATABASE OPEN command.
$ sqlplus sys/oracle@TNS as sysdba
SQL>shutdown immediate 
$mv /u01/app/oradata/users01.dbf /u02/app/oradata/users01.dbf
$ sqlplus sys/oracle@TNS as sysdba
SQL>startup mount;
SQL> ALTER DATABASE RENAME FILE '/u01/app/oradata/users01.dbf ' TO '/u02/app/oradata/users01.dbf ';
SQL> alter database open;

If the datafiles that need to be changed or moved do not belong to SYSTEM tablespaces, and do not contain active rollback segments or temporary segments, there is another workaround that does not require database instance to be shutdown. Instead, only the particular tablespace that contains the date files is taken offline.
Method 2:
  1. Login to SQLPlus.
  2. Connect as SYS DBA with CONNECT / AS SYSDBA command.
  3. Make offline the affected tablespace with ALTER TABLESPACE <tablespace name> OFFLINE; 
  4.  Modify the name or location of datafiles in Oracle data dictionary using following command syntax:
SQL>ALTER TABLESPACE USERS RENAME DATAFILE '/u01/app/oradata/users01.dbf ' TO '/u02/app/oradata/users01.dbf ';
  1. Bring the tablespace online again with ALTER TABLESPACE <tablespace name> ONLINE;


$ sqlplus sys/oracle@TNS as sysdba
SQL>ALTER TABLESPACE USERS OFFLINE;
SQL>ALTER TABLESPACE USERS RENAME DATAFILE '/u01/app/oradata/users01.dbf ' TO '/u02/app/oradata/users01.dbf ';
SQL>ALTER TABLESPACE USERS ONLINE;

Difference Between PFILEand SPFILE In Oracle 10g/11g.

What Is a Parameter File Actually?
  A parameter file is a file that contains a list of initialization parameters and a value for each parameter. You specify initialization parameters in a parameter file that reflect your particular installation. Oracle supports the following two types of parameter files:
1.Server Parameter Files - It's a Binary version(it is in the form of 0's and 1's, Persistent.
2.Initialization Parameter Files - It's a Text version and Not persistent.
 Server Parameter File (SPFILE):
A server parameter file is a binary file that acts as a repository for initialization parameters. The server parameter file can reside on the machine where the Oracle database server executes. Initialization parameters stored in a server parameter file are persistent, in that any changes made to the parameters while an instance is running can persist across instance shutdown and startup.
Initialization Parameter File(PFILE):
 An initialization parameter file is a text file that contains a list of initialization parameters. The file should be written in the client's default character set. Sample initialization parameter files are provided on the Oracle distribution medium for each operating system. A sample file is sufficient for initial use, but you will probably want to modify the file to tune the database for best performance. Any changes will take effect after you completely shut down and restart the instance.
How the Oracle Instance is initialized by Using these files ?
When the Oracle instance start, first it looks to the $ORACLE_HOME/dbs (UNIX, Linux) or ORACLE_HOME/database (Windows) directory for the following files (in this order): 
      1.  spfile${ORACLE_SID}.ora   -------->           (SPFILE = Server Parameter File)
      2.  spfile.ora                       --------->             (SPFILE)  
      3.  init${ORACLE_SID}.ora     --------->           (PFILE) 
      4.  init.ora                            --------->          (PFILE) 
The first found file is used for the instance initialization. So, Oracle first look for a SPFILE and after that after a PFILE. PFILE is a text file, which can be modified  and SPFILE is a binary file which cannot be modified using a text editor.  
  Uses of SPFILE:
1. No need to restart the database in order to have a parameter changed and the new value stored in the initialization file.
2. Reduce human errors: Parameters are checked before changes are accepted.
3. SPFILE can be backed-up with RMAN (RMAN cannot backup PFILEs).
How can we know Our database using SPFILE or PFILE ?
The following query gives the result:
    SELECT DECODE (value, NULL, 'PFILE', 'SPFILE') "Init File Type"                            FROM sys.v_$parameter WHERE name = 'spfile';
How could I switch from SPFILE to PFILE and vice-versa ?
Switch from SPFILE to PFILE:
     1)  SQL>CREATE PFILE FROM SPFILE;
     2)  Backup and delete SPFILE
     3)  Restart the instance
Switch from PFILE to SPFILE :
     1)  SQL>CREATE SPFILE FROM PFILE;
     2)  Restart the instance (the PFILE will be in the same directory but will not be                     used. SPFILE will be used as per first priority)  .
How can we Change  SPFILE parameter values ?
SQL>ALTER SYSTEM SET timed_statistics = TRUE  COMMENT = 'Changed by Hari on January 1st 2012'  SCOPE = BOTH  SID = '*'
The SCOPE parameter can be set to SPFILE, MEMORY or BOTH:
- MEMORY: Set for the current instance only. This is the default behavior if a PFILE was used at STARTUP.
- SPFILE: update the SPFILE, the parameter will take effect with next database startup
- BOTH: affect the current instance and persist to the SPFILE. This is the default behavior if an SPFILE was used at STARTUP. 
Note :
1.The COMMENT parameter (optional) specifies a user remark.
2.The SID parameter (optional; only used with RAC) indicates the instance for which the parameter applies. (Default is *: all Instances).


Background Process in Oracle 10g .

 At startup time, Oracle creates a number of system background processes for each instance to perform system functions:
  • The System Monitor (SMON) performs instance recovery during startup, cleans up temporary segments that are no longer in use, recovers dead transactions skipped during crash and instance recovery because of file-read or offline errors, and coalesces small chunks of contiguous free space into larger blocks of contiguous space for easier allocation by Oracle.. It carries out a crash recovery process when an insance crashed. In a Real Application Clusters database, the SMON process of one instance can perform instance recovery for other instances that have failed. SMON also cleans up temporary segments that are no longer in use and recovers dead transactions skipped during system failure and instance recovery because of file-read or offline errors. These transactions are eventually recovered by SMON when the tablespace or file is brought back online.
  • The Process Monitor (PMON) performs recovery when a user process fails. PMON cleans up the cache and frees resources that the process was using. PMON also restarts failed dispatcher and shared server processes.
  • The Database Writer (DBWR) writes modified (dirty) data blocks from the database cache to data files on disk using a least recently used algorithm. Whenever possible, DBWR writes dirty buffers to disk using a multi-block write mechanism. DBWR manages the buffer cache so that user processes can always find free buffers. The DBWR process is signaled to write dirty buffers to disk under the following conditions:
    • when the dirty list reaches a threshold length defined by the init.ora parameter DB_BLOCK_WRITE_BATCH;
    • when a free buffer has not been found after n buffers have been scanned (where n is defined by DB_BLOCK_MAX_SCAN_CNT in init.ora);
    • when a timeout occurs (every three seconds);
    • when a checkpoint occurs; and
    • when the Log Writer (LGWR) signals DBWR.
  • The LGWR is triggered during several internal events (commit, checkpoint, and log write timeout), as well as when the redo log buffer is one-third full. This process writes the redo log buffer in memory to the redo log file on disk. During each Checkpoint (CKPT), the LGWR updates file headers if a CKPT process is not configured to perform this function.
  • The optional CKPT process updates the headers of all data files during checkpoint processing. If the init.ora CHECKPOINT_PROCESS parameter is enabled, this process can improve system performance by freeing the LGWR to concentrate on the redo log buffer. The CKPT process does not write data blocks to disk; this is performed by the DBWR.
  • The Recoverer (RECO) is started when distributed transactions are permitted and the init.ora parameter DISTRIBUTED_TRANSACTIONS is greater than zero. The Oracle distributed option uses the RECO process to automatically resolve distributed transaction failures. The recoverer process is used to resolve distributed transactions that are pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to remote databases and automatically complete the commit or rollback of the local portion of any pending distributed transactions.
  • The Archiver (ARC) copies online redo log files, once they become full, to a specified storage device or location. ARC is present only when the database is started in ARCHIVELOG mode and automatic archiving is enabled.
  • Lock (LCKn) processes are used in conjunction with the Parallel Server option. Up to 10 LCK processes (LCK0 through LCK9) are used to control inter-instance locking.
  • Dispatcher (Dnnn) processes, used with the MTS configuration, allow user processes to share a limited number of shared server processes. At least one dispatcher process must be created for each network protocol used to communicate with Oracle. It is used in a shared server environment.
  • Parallel Query server processes (Pnnn) are used with the Parallel Query option in Oracle 7.1 or higher. With this option, a query coordinator (QC) intercepts queries, decides if they should be split into multiple smaller queries, and sends them to the pool of available query servers for processing. Query servers are also used for parallel index creation and data loads. The number of query servers automatically increases or decreases (within the upper and lower limits set by the administrator) to accommodate changing workload levels. 
  • Snapshot (SNPn) processes are used with the Oracle distributed option to automatically refresh table snapshots. These processes “wake-up” periodically when snapshots are scheduled to be automatically refreshed.
  • The Lock Monitor (LMON) Meant for Parallel server setups, Lock Monitor manages global locks and resources. It handles the redistribution of instance locks whenever instances are started or shutdown. Lock Monitor also recovers instance lock information prior to the instance recovery process. Lock Monitor co-ordinates with the Process Monitor to recover dead processes that hold instance locks.
  • The Job Queue Processes (J000) carry out batch processing. All scheduled jobs are executed by these processes. The initialization parameter JOB_QUEUE_PROCESSES specifies the maximum job processes that can be run concurrently. If a job fails with some Oracle error, it is recorded in the alert file and a process trace file is generated. Failure of the Job queue process will not cause the instance to fail.
  • The Shared Server Processes (SNNN) Intended for Shared server setups (MTS). These processes pickup requests from the call request queue, process them and then return the results to a result queue. The number of shared server processes to be created at instance startup can be specified using the initialization parameter SHARED_SERVERS.
  • The Managed recovery process (MRP) applies archived redo log to the standby database.
  • The remote file server process (RFS) on the standby database receives archived redo logs from the primary database.
  • AQ Time Manager (QMNn). A queue monitor process which monitors the message queues. Used by Oracle Streams Advanced Queuing.
  • Jnnn (10g): These are job queue processes which are spawned as needed by CJQ0 to complete scheduled jobs
  • The Automatic Shared Memory Management feature uses a new background process named Memory Manager (MMAN new on 10g). MMAN serves as the SGA Memory Broker and coordinates the sizing of the memory components. The SGA Memory Broker keeps track of the sizes of the components and pending resize operations
  • RVWR (10g) for Flashback database
- Flashbacking a database means going back to a previous database state.
- The Flashback Database feature provides a way to quickly revert an entire Oracle database to the state it was in at a past point in time.
- This is different from traditional point in time recovery.
- A new background process Recovery Writer ( RVWR) introduced which is responsible for writing flashback logs which stores pre-image(s) of data blocks
- One can use Flashback Database to back out changes that:
- Have resulted in logical data corruptions.
- Are a result of user error.
- This feature is not applicable for recovering the database in case of media failure.
- The time required for flashbacking a database to a specific time in past is DIRECTLY PROPORTIONAL to the number of changes made and not on the size of the database.

  • CTWR (10g). This is a new process Change Tracking Writer (CTWR) which works with the new block changed tracking features in 10g for fast RMAN incremental backups.
  • MMNL (10g) The Memory Monitor Light (MMNL) process is a new process in 10g which works with the Automatic Workload Repository new features (AWR) to write out full statistics buffers to disk as needed.
  • MMON (10g) The memory monitor (MMON) process was introduced in 10g and is associated with the Automatic Workload Repository new features used for automatic problem detection and self-tuning. MMON writes out the required statistics for AWR on a scheduled basis.
  • CJQn (10g) This is the Job Queue monitoring process which is initiated with the job_queue_processes parameter. This is not new. More Info DOCID=222190.1

https://marthadba.blogspot.in/

Copyright © MARTHADBA|About Us |Disclaimer | Contact Us |Sitemap |Designed By CodeNirvana