Wednesday, June 30, 2021

Oracle User Management

 

User is basically used to connect to database. All DB objects like table, index, view etc., can be created under that user. In Oracle, users and schemas are essentially the same thing. You can consider that a user is the account you use to connect to a database, and a schema is the set of objects that belong to that account.

 

1. Create a user:

create user TEST identified by temporary_pass 

PROFILE DEFAULT

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP;

Minimum privilege required to connect to a database is create session

SQL> grant create session to TEST;

 

2. Change password of a user:

SQL> alter user TEST identified by TEST#12345;

 

3. Lock/unlock a user

Lock the user account:

SQL> alter user test account lock;


Unlock the user account:

SQL> alter user test account unlock;

 

4. Make a user password expiry:

When we make a user id expiry, then when the user does login, it will prompt him to set a new password.

SQL> alter user test account expire;

5. Changing default tablespace of a user:

SQL> select username,default_tablespace from dba_users where username='TEST';

USERNAME                DEFAULT_TABLESPACE

----------------------- ------------------------------

TEST                    USERS

SQL> alter user TEST default tablespace DATATS;

SQL> select username,default_tablespace from dba_users where username='TEST';

USERNAME                DEFAULT_TABLESPACE

----------------------- ------------------------------

TEST                    DATATS

6. Changing default TEMP tablespace of a user:

SQL> select username,TEMPORARY_TABLESPACE from dba_users where username='TEST';

USERNAME                TEMPORARY_TABLESPACE

----------------------- ------------------------------

TEST                    TEMP

SQL> alter user TEST temporary tablespace TEMP2;

SQL> select username,TEMPORARY_TABLESPACE from dba_users where username='TEST';

USERNAME                TEMPORARY_TABLESPACE

----------------------- ------------------------------

TEST                    TEMP2

 

PROFILE:

A profile enforces set of password security rules and resource usage limit.

While creating a user if no profile is mentioned, then DEFAULT profile will be assigned.

 

7. DEFAULT PROFILE SETTING:

SQL> select profile,resource_name,RESOURCE_TYPE,limit from dba_profiles where profile='DEFAULT';

PROFILE RESOURCE_NAME RESOURCE LIMIT

-------------- -------------------------------- -------- ------------

DEFAULT COMPOSITE_LIMIT KERNEL UNLIMITED

DEFAULT SESSIONS_PER_USER KERNEL UNLIMITED

DEFAULT CPU_PER_SESSION KERNEL UNLIMITED

DEFAULT CPU_PER_CALL KERNEL UNLIMITED

DEFAULT LOGICAL_READS_PER_SESSION KERNEL UNLIMITED

DEFAULT LOGICAL_READS_PER_CALL KERNEL UNLIMITED

DEFAULT IDLE_TIME KERNEL UNLIMITED

DEFAULT CONNECT_TIME KERNEL UNLIMITED

DEFAULT PRIVATE_SGA KERNEL UNLIMITED

DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10

DEFAULT PASSWORD_LIFE_TIME PASSWORD 180

DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED

DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED

DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL

DEFAULT PASSWORD_LOCK_TIME PASSWORD 1

DEFAULT PASSWORD_GRACE_TIME PASSWORD 7

 

*SESSION_PER_USER – No. of allowed concurrent sessions for a user

*CPU_PER_SESSION – CPU time limit for a session, expressed in hundredth of seconds.

*CPU_PER_CALL – Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds.

*CONNECT_TIME – Specify the total elapsed time limit for a session, expressed in minutes.

*IDLE_TIME – Specify the permitted periods of continuous inactive time during a session, expressed in minutes.

*LOGICAL_READS_PER_SESSION – Specify the permitted number of data blocks read in a session, including blocks read from memory and disk

*LOGICAL_READS_PER_CALL –permitted number of data blocks read for a call to process a SQL statement (a parse, execute, or fetch).

*PRIVATE_SGA – SGA a session can allocate in the shared pool of the system global area (SGA), expressed in bytes.

*FAILED_LOGIN_ATTEMPTS – No. of failed attempts to log in to the user account before the account is locked

*PASSWORD_LIFE_TIME: No. of days the account will be open. after that it will expiry.

*PASSWORD_REUSE_TIME: number of days before which a password cannot be reused

*PASSWORD_REUSE_MAX: number of days before which a password can be reused

*PASSWORD_LOCK_TIME: Number of days the user account remains locked after failed login

*PASSWORD_GRACE_TIME: Number of grace days for user to change password

*PASSWORD_VERIFY_FUNCTION: PL/SQL that can be used for password verification

 

8. Create a new profile:

SQL> CREATE PROFILE "NEW_PROFILE"

LIMIT

COMPOSITE_LIMIT UNLIMITED

SESSIONS_PER_USER UNLIMITED

CPU_PER_SESSION UNLIMITED

CPU_PER_CALL UNLIMITED

LOGICAL_READS_PER_SESSION UNLIMITED

LOGICAL_READS_PER_CALL UNLIMITED

IDLE_TIME 90

CONNECT_TIME UNLIMITED

PRIVATE_SGA UNLIMITED

FAILED_LOGIN_ATTEMPTS 10

PASSWORD_LIFE_TIME 180

PASSWORD_REUSE_TIME UNLIMITED

PASSWORD_REUSE_MAX UNLIMITED

PASSWORD_VERIFY_FUNCTION NULL

PASSWORD_LOCK_TIME UNLIMITED

PASSWORD_GRACE_TIME UNLIMITED;

 

9. Alter a profile:

SQL> ALTER PROFILE NEW_PROFILE LIMIT FAILED_LOGIN_ATTEMPS UNLIMITED;

10. Change profile of an user:

SQL> select username,profile from dba_users where username='TEST';

USERNAME                PROFILE

----------------------- ------------------------------

TEST                    DEFAULT

SQL> ALTER USER TEST PROFILE NEW_PROFILE;

SQL> select username,profile from dba_users where username='TEST';

USERNAME                PROFILE

----------------------- ------------------------------

TEST                    NEW_PROFILE

11. How to make a user non-expiry:

Usually application users we need to set non-expiry. means it will never expire. To set it, we need to either create a profile with PASSWORD_LIFE_TIME UNLIMITED or alter the profile of that user.

SQL> select username,profile,EXPIRY_DATE from dba_users where username='TEST';

USERNAME                PROFILE                 EXPIRY_DATE

----------------------- ----------------------- ---------

TEST                    NEW_PROFILE             10-NOV-18

SQL> ALTER PROFILE NEW_PROFILE LIMIT PASSWORD_LIFE_TIME UNLIMITED;

SQL> select username,profile,EXPIRY_DATE from dba_users where username='TEST';

USERNAME                PROFILE                 EXPIRY_DATE

----------------------- ----------------------- ---------

TEST                    NEW_PROFILE

12. Drop a user:

Dropping a user will drop all the objects it owns.

SQL> drop user TEST cascade;

 

Tuesday, June 29, 2021

Oracle Tablespace Management

Oracle Tablespaces Overview and Management

- Oracle divides a database into one or more logical storage units called tablespaces.

- Each tablespace consists of one or more files called datafiles.

- A datafile physically stores the data objects of the database such as tables and indexes on disk.

- Oracle logically stores data in the tablespaces and physically stores data in datafiles associated with the corresponding tablespaces.

- By using tablespaces, you can perform the following operations:

  • Control the database size allocated for the data.
  • Grant space quotas to the users.
  • Control the availability of data by taking tablespaces online or offline.
  • Perform partial database backup or recovery.

-  If the datafiles of a tablespace become full we can add new datafiles to that tablespace at any point in time.

- By default when we create a new oracle database then some default tablespaces will be created. They are
            System tablespace
            Sysaux tablespace
            Undo tablespace
            Temporary tablespace
            Default permanent tablespace/users tablespace



Tablespaces can be manipulated with the following sql commands,

1. CREATE
2. DROP
3. ALTER

Examples for Create Tablespace:

Permanent tablespace:

SQL> create tablespace test datafile '/u01/app/oradata/test01.dbf' SIZE 100M autoextend on;

Create more than one datafile with a single create tablespace command:

SQL> create tablespace test datafile '/u01/app/oradata/test01.dbf' size 100M autoextend on,
'/u01/app/oradata/test02.dbf' SIZE 100M AUTOEXTEND ON,
'/u01/app/oradata/test03.dbf' SIZE 100M AUTOEXTEND ON logging extent management local;

Temporary Tablespace:

SQL> Create temporary tablespace temp01 tempfile '/u01/app/oradata/TEMP01.DBF' size 2048m;

Undo tablespace:

SQL> create undo tablespace UNDOTBS datafile '/u01/app/oradata/undotbs01.dbf' size 2048M;

Big file tablespace (Introducing in Oracle10g):

SQL> Create bigfile tablespace big_tbs datafile '/u01/app/oradata/big_tbs01.dbf' SIZE 100G;

Extend Size of a tablespace:

SQL> alter database datafile '/u01/app/oradata/test01.dbf' resize 1024M;

Adding datafile:

SQL> alter tablespace test add datafile '/u01/app/oradata/test02.dbf' size 1024M;

Tablespaces have two status

1. ONLINE (DEFAULT STATUS OF A TABLESPACE)
2. OFFLINE

If a tablespace is offline, you cannot access data stored in it. On the other hand, if a tablespace is online, its data is available for reading and writing.

Normally, a tablespace is online so that its data is available to users. However, you can take a tablespace offline to make data inaccessible to users when you update and maintain the applications.

In case of some errors such as hardware failures, Oracle automatically takes an online tablespace offline. Any attempt to access data in offline tablespace will result in an error.


Examples for making tablespace to offline and online:

SQL> alter tablespace test offline;
SQL> alter tablespace test online;


An online tablespace has 2 modes

1. READ WRITE (Default mode of a ts)
2. READ ONLY

The read-only tablespaces allow Oracle to avoid performing backup and recovery of large, static parts of a database. Because Oracle doesn’t update the files of a read-only tablespace, you can store the files on the read-only media.

Examples for making tablespace to Read Write and Read only mode:

SQL> alter tablespace test read only;
SQL> alter tablespace test read write;


Drop tablespaces:

SQL>drop tablespace test including contents and datafiles;

Tablespace related data dictionary views:

1. DBA_TABLESPACES
2. DBA_DATA_FILES
3. V$DATAFILES
4. V$TEMPFILE
5. DBA_SEGMENTS
6. DBA_EXTENTS
7. USER_SEGMENTS
8. USER_EXTENTS
9. SM$TS_FREE
10. SM$TS_USED

 


Oracle Database Architecture

   Introduction to Oracle Database

The purpose of a database is to store and retrieve information. In general, a  server reliably manages a large amount of data in a multiuser environment so that many users can concurrently access the same data. A database server also prevents unauthorized access and provides efficient solutions for failure recovery.

Oracle Database is the first database designed for enterprise grid computing, the most flexible and cost effective way to manage information and applications. With this architecture, each new system can be rapidly provisioned from the pool of components. There is no need for peak workloads, because capacity can be easily added or reallocated from the resource pools as needed.

The database has logical structures and physical structures. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting the access to logical storage structures.

 

Oracle Database Architecture

There are two main components of Oracle database –– instance and database itself. An instance consists of some memory structures and the background processes, whereas a database refers to the disk resources.

 There are two basic memory structures on the Oracle instance.

        - SGA (System Global Area)

        - PGA (Program Global Area)  


  SGA (System Global Area):

The Oracle SGA is the most important memory structure in Oracle. The SGA stores several different components of memory usage that are designed to execute processes to obtain data for user queries as quickly as possible while also maximizing the number of concurrent users that can access the Oracle instance. Main Components in SGA.

        - Shared Pool

        - Buffer Cache

        - Redo Log Buffer

        - Large Pool

        - Java Pool

Shared Pool:

The shared SQL library cache is designed to store parse information for SQL statements executing against the database. Parse information includes the set of database operations that the SQL execution mechanism will perform in order to obtain data requested by the user processes. If another user process run the same query that Oracle has already parsed for another user, the database will recognize the opportunity for reuse and let the user process utilize the parse information already available in the shared pool.

The other mandatory component of the shared pool is the data dictionary cache(row cache). This memory structure is designed to store the data from the Oracle data dictionary in order to improve response time on data dictionary queries.

Buffer cache:

The database buffer cache is the portion of the SGA that holds copies of data blocks read from datafiles. All users concurrently connected to the instance share access to the database buffer cache.

Redo log buffer :

One fact that is important to remember about redo logs and user processes is that every process that makes a change to the database must write an entry to the redo log in order to allow Oracle to recover the change. When the database is set up to archive redo logs, these database changes are kept in order to rebuild database objects in the event of a disk failure. Since every data change process has to write a redo log entry, it makes sense that processes be able to write that change as quickly as possible in order to boost speed and avoid problems.

Large pool :

It is an optional area of memory in the SGA. It is used to relieves the burden place on the shared pool. It is also used for I/O processes. The large pool size can be set by LARGE_POOL_SIZE parameter in init.ora initialization parameter file.

Java pool :           

It is used to services parsing of the Java commands. Its size can be set by JAVA_POOL_SIZE parameter in init.ora initialization parameter file.

Streams Pool :

The streams pool is used exclusively by Oracle Streams. The Streams pool stores buffered queue messages, and it provides memory for Oracle Streams capture processes and apply processes.

 

PGA (Program Global Area) :

Oracle Database allocates a program global area (PGA) for each server process. The PGA is used to process SQL statements and to hold logon and other session information. For the purposes of memory management, the collection of all PGAs is known as the instance PGA. Using an initialization parameter, you set the size of the instance PGA, and the database distributes memory to individual PGAs as needed.

 

Major Oracle Database’s background processes

The following are the major background processes of an Oracle instance:

PMON : (Process Monitor)

The process monitor that regulates all other processes. PMON cleans up abnormally connected database connections and automatically registers a database instance with the listener process. PMON is a process that must be alive in an Oracle database.

SMON: (System Monitor)

The system monitor process that performs system-level clean-up operation. It has two primary responsibilities including automatically instance recovery in the event of a failed instance, e.g., power failure and cleaning up of temporary files.

DBWn:(Database Writers)

Oracle performs every operation in memory instead of the disk because processing in memory is faster and more efficient than on disk. The DBWn process reads data from disk and writes it back to the disk. An Oracle instance has many database writers DBW0, DBW1, DBW2, and so on.

CKPT:(CheckPoint)

Data that is on disk is called block and the data which in memory is called buffer. When a block is written to the buffer and changed, the buffer becomes dirty, and it needs to be written down to the disk. The CKPT process updates the control and data file headers with checkpoint information and signals writing of dirty buffers to disk.

LGWR: (Log Writer)

The Process which is the key to the recoverability architecture. Every change occurs in the database is written out to a file called redo log for recovery purposes. And these changes are written and logged by LGWR process. The LGWR process first writes the changes to memory and then disk as redo logs which then can be used for recovery.

ARCn :(Archiver Process)

 The archiver process that copies the content of redo logs to archive redo log files. The archiver process can have multiple processes such as ARC0, ARC1, and ARC3 and so on.