RMAN

RMAN:

RMAN (Recovery Manager) is a backup and recovery manager supplied for Oracle databases (from version 8) created by the Oracle Corporation. It provides database backup, restore, and recovery capabilities addressing high availability and disaster recovery concerns. Oracle Corporation recommends RMAN as its preferred method for backup.

 -RMAN keeps rman backup records in current control file, if the database not using catalog.

-Default location for the RMAN backups is Flash Recovery Area.

Files That RMAN Can Back Up

RMAN's BACKUP command supports backing up the following types of files:

·       datafiles, control files, and the server parameter file (SPFILE)

·       Archived redo logs

Prerequisites

Database should be in archivelog mode and database should be up and running since RMAN backups are online backup.

 

Image Copies and Backup Sets

RMAN backups can be stored in one of two formats as image copies or as backup sets.

 

Image Copies

An image copy is a bit-for-bit duplicate of a database file, identical to a copy made with an operating system command. (RMAN-created image copies are, however, recorded in the RMAN repository, unlike file copies created using operating system-level commands.)

Image copy backups can only be created on disk. RMAN can create image copies of datafiles and datafile copies, control files and control file copies, archived redo logs, and backup pieces. RMAN creates image copies when the AS COPY option is used with the BACKUP command.

Ex: taking full backup copy

$rman target /

RMAN> backup as copy database;

Backup Sets

RMAN can also store backup information a logical structure called a backupset. A backup set contains the data from one or more datafiles, archived redo logs, or control files or SPFILE. You can also back up existing backup sets into another backup set.

A backup set consists of one or more files in an RMAN-specific format, known as backuppieces. By default, a backup set consists of one backup piece. For example, you can backup ten datafiles into a single backup set consisting of a single backup piece.

Ex: Taking full backup as follow

$rman target /

RMAN> backup database;

RMAN Full and Incremental Backups

RMAN backups of datafiles can be either full datafile backups, or incremental backups.

A full backup of a datafile is a backup that includes every used data block in the file. If a full datafile backup is created as an image copy, the entire file contents are reproduced exactly.

RMAN incremental backups back up only datafile blocks that have changed since a specified previous backup. You can make incremental backups of databases, individual tablespaces or datafiles.

The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup.

Level 0 and Level 1 Incremental Backups

Incremental backups can be either level 0 or level 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data, backing the datafile up into a backup set just as a full backup would. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.

A level 1 incremental backup can be either of the following types:

·       A differential backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0. If there is not recent level 0 or 1 backup, RMAN takes level 0 backup.

EX: taking incremental backup (Level 1).

RMAN> backup incremental level 1 database;

·       A cumulative backup, which backs up all blocks changed after the most recent incremental backup at level 0, if there is no recent level 0 backup RMAN takes Level 0 backup.

EX:

             RMAN> backup incremental level 1 cumulative database;

·       Incremental backups are differential by default.

Starting and Exiting RMAN

The RMAN executable is automatically installed with the database and is typically located in the same directory as the other database executables. For example, the RMAN client on Linux is located in $ORACLE_HOME/bin. 

You have the following basic options for starting RMAN:

• Start the RMAN executable at the operating system command line connecting target database with OS authentication option, as in the following example:

$rman target /

• Connecting to target database as user

     [oracle@localhost ~]$ rman target sys@orcl

Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 26                  03:50:22 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

target database Password:

connected to target database: ORCL (DBID=1341150024)

RMAN>

 To quit RMAN and terminate the program, enter EXIT or QUIT at the RMAN prompt:

     RMAN> EXIT

Specifying the Location of RMAN Output

By default, RMAN writes command output to standard output. To redirect output to a log file, enter the LOG parameter on the command line when starting RMAN, as in the following example:

$ rman target / LOG /tmp/rman.log

In this case, RMAN displays command input but does not display the RMAN output. The easiest way to send RMAN output both to a log file and to standard output is to use the Linux tee command or its equivalent. For example, the following technique enables both input and output to be visible in the RMAN command-line interface:

$ rman target / | tee rman.log

Viewing and change your CONFIGURE command settings:

Run SHOW ALL as shown bellow. The output includes both parameters that you have changed and those that are set to the default. The configuration is displayed as the series of RMAN commands required to re-create the configuration. You can save the output in a text file and use this command file to re-create the configuration on the same or a different database.

SHOW ALL Command:

RMAN>SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV= (OB_DEVICE=tape1)';

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default

Adding disk to VM for linux and creating file system for storing files

Follow the screen shot to add a disk to VM.

Login as root user and follow the process.


[root@localhost ~]# fdisk -l

Disk /dev/sda: 21.4 GB, 21474836480 bytes

255 heads, 63 sectors/track, 2610 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *           1          38      305203+  83  Linux

/dev/sda2              39        2353    18595237+  83  Linux

/dev/sda3            2354        2610     2064352+  82  Linux swap / Solaris

Disk /dev/sdb: 21.4 GB, 21474836480 bytes

255 heads, 63 sectors/track, 2610 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

/dev/sdb1               1        2610    20964793+  83  Linux

Disk /dev/sdc: 21.4 GB, 21474836480 bytes

255 heads, 63 sectors/track, 2610 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdc doesn't contain a valid partition table

/dev/sdc is added and we need to partition it first

/dev/sdc is added, if we add disk to a Virtual machine it must be partitioned, so that OS can detect the disk

[root@localhost dev]# fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 2610.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-2610, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-2610, default 2610):
Using default value 2610

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

[root@localhost ~]#  fdisk -l

Disk /dev/sda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          38      305203+  83  Linux
/dev/sda2              39        2353    18595237+  83  Linux
/dev/sda3            2354        2610     2064352+  82  Linux swap / Solaris

Disk /dev/sdb: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        2610    20964793+  83  Linux

Disk /dev/sdc: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1        2610    20964793+  83  Linux

Create a Linux file system on the partition so that the operating system can use it to store files and data. By using mkfs.btrfs utility

[root@localhost ~]# mkfs. (press tab)

mkfs.btrfs   mkfs.cramfs  mkfs.ext2    mkfs.ext3    mkfs.ext4    mkfs.fat     mkfs.gfs2    mkfs.minix   mkfs.msdos   mkfs.vfat    mkfs.xfs

[root@localhost ~]# mkfs.btrfs /dev/sdb

sdb   sdb1

[root@localhost ~]# fdisk -l

Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x000b2714

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *        2048     2050047     1024000   83  Linux

/dev/sda2         2050048    41943039    19946496   8e  Linux LVM

/dev/sda3        41943040    62914559    10485760   8e  Linux LVM

Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x1339d503

   Device Boot      Start         End      Blocks   Id  System

/dev/sdb1            2048    41943039    20970496   83  Linux

Disk /dev/mapper/ol-swap: 3145 MB, 3145728000 bytes, 6144000 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/ol-root: 25.9 GB, 25866272768 bytes, 50520064 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@localhost ~]# mkfs.btrfs /dev/sdb1

WARNING! - Btrfs v3.12 IS EXPERIMENTAL

WARNING! - see http://btrfs.wiki.kernel.org before using

Turning ON incompat feature 'extref': increased hardlink limit per file to 65536

fs created label (null) on /dev/sdb1

        nodesize 16384 leafsize 16384 sectorsize 4096 size 20.00GiB

Btrfs v3.12

We need to mount it so that it is accessible to the RHEL system and its users. In order to do this we need to create a mount point. A mount point is simply a directory into which the file system will be mounted

[root@localhost ~]#  mkdir /datavol
[root@localhost ~]# mount /dev/sdc
[root@localhost ~]# mount /dev/sdc1 /datavol
[root@localhost ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              18G   11G  5.5G  67% /
/dev/sda1             289M   16M  258M   6% /boot
tmpfs                1006M     0 1006M   0% /dev/shm
/dev/sdb1              20G  3.7G   16G  20% /data
/dev/sdc1              20G  173M   19G   1% /datavol

[root@localhost ~]# mount
/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sdb1 on /data type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /proc/fs/vmblock/mountPoint type vmblock (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sdc1 on /datavol type ext3 (rw)

Configuring RHEL to automatically mount on boot

Open the fstab file and enter the details of the mounted disk

My original file is like as follows

[root@localhost ~]# sudo vi /etc/fstab

LABEL=/           /            ext3    defaults        1 1

LABEL=/boot       /boot        ext3    defaults        1 2

tmpfs             /dev/shm     tmpfs   defaults        0 0

devpts            /dev/pts     devpts  gid=5,mode=620  0 0

sysfs             /sys         sysfs   defaults        0 0

proc              /proc        proc    defaults        0 0

LABEL=SWAP-sda3    swap        swap    defaults        0 0


We need to add disk to the end of the file as following

LABEL=/              /          ext3    defaults        1 1

LABEL=/boot          /boot      ext3    defaults        1 2

tmpfs                /dev/shm   tmpfs   defaults        0 0

devpts               /dev/pts   devpts  gid=5,mode=620  0 0

sysfs                /sys       sysfs   defaults        0 0

proc                 /proc      proc    defaults        0 0

LABEL=SWAP-sda3       swap      swap    defaults        0 0

LABEL=/dev/sdc1      /data      ext3    defaults        0 2

Container Database creation in 12c with DBCA

Oracle Database 12c - All about Multitenant Architecture

Oracle Database 12c - All about Multitenant Architecture

For the past several years, we have witnessed significant contributions to Oracle Database. Every version has brought us some ground breaking technology and a leap forward innovation, that is a lot impressive and inspirational. As we already knew, Oracle has announced next major release candidate of Database, 12c at Oracle open world'2012, which is now available for download with all necessary product documentation. It has been completely redesigned from the ground and introduced fundamentally a major architectural change to Oracle Database which is called Multitenant Architecture. Throughout this post, I broadly elaborate it, and discuss its "what, why, and how", also includes its basic command line instructions.

What is Multitenant Architecture?

It is quite simple, Multiple tenants share same resources on a mutual benefit for different purposes at a very broad level. The same applies to Oracle Database where Multiple Databases share a single instance of resources aiming for different purposes on the same Server. This Oracle Database which is built on Multitenant foundation is called Container Database(CDB), and each container(tenant) residing inside is called Pluggable Database(PDB, Container). 

Why is Multitenant Architecture?

Technology has vastly improved as customers can afford servers with hundreds of CPUs and huge chunk of Physical Memory where the Hardware resources can be distributed and managed dynamically. If applications get hold of this, that would be a huge benefit for Enterprises. That is what exactly Oracle has brought to the table, and this is only a beginning. 

Benefits

One of the main reasons for Multitenant Architecture to be in place is "Database Consolidation". Until so far, we have databases deployed across multiple Small Physical machines on various platforms. It could be waste of resources having a database on each machine dedicatedly rather keeping them all on a single powerful machine. By consolidating all Databases onto a Single powerful chip and a Single Oracle Instance, we achieve following benefits

• Cost reduction in terms of Product licensing and Hardware procurement as we require less number of processors and less memory compare to a Non-CDB environment
• Easier Database maintenance, Pluggable Databases can easily be moved or copied locally or remotely across Physical machines in the network, Upgrading Operating System, Upgrading or Patching Database itself is a lot easier and "often" a one shot process, that greatly improves the availability 
• Performance tuning becomes a lot easier as all PDBs in a CDB environment share same Hardware/Platform/Network resources like CPUs/Memory/OS/Bandwidth etc.. For example, It is quite easy to tune one single piece of SGA/PGA on one single instance rather tuning each SGA on each physical machine

What more?

• It is completely transparent to Application, there is no specific configuration required to connect to a Database in Multitenant Architecture over a network. It works the same way as it works with Non CDBs. Every Container or PDB has its own Service name to allow connections from Clients like JDBC/ODBC/XA/SQPLUS etc...
• A Multitenant Container Database is created using either DBCA or "CREATE DATABASE" Command
• A Multitenant Container Database or shortly a CDB, can be created with an empty container, no Pluggable Databases or shortly PDB(s) associated with it, [or] with one or more containers(More than one PDB)
• Memory configurable is sum of memory required for all PDBs, is distributed on demand across all PDBs
• A CDB can contain 253 PDBs including the SEED Container
• Starting up and Shutting down a CDB is no different than a Non-CDB except we need to manually mount and dismount associated PDBs
• The Architecture basically consists following containers
• Root container - It is the core of the CDB, contains all Oracle supplied metadata like packages, core dictionary objects, and common users. It is denoted as CDB$ROOT
• SEED Container (SEED PDB) - This is a template database distributed for new PDBs, whenever we create a new PDB, Oracle copies mandatory datafiles (common datafiles) for creation of PDB from this SEED Database. This is by default in READ-ONLY mode, can't be altered or modified. This is denoted as PDB$SEED
• User defined PDB Container (PDB) - This is the Pluggable Database created for Application purpose, contains only Consumer Data or USER Data
• CDB has common user environment. A User exists in the ROOT Container can login to any PDB with the privileges given. A CDB also has local users exclusive to PDBs. A Common user and role name must start with C## or c## and consists only of ASCII characters.
• If a common user is required to login to a container, "c##" must be supplied as suffix. For example, If a common user "PDBADMIN" has privilege to acces a container PDB, We need to use it as "C##PDBADMIN" in order to login successfully to container PDB
• "CONTAINER=ALL" clause can be used on root container while performing different tasks such as "ALTER SYSTEM", "ALTER DATABASE", "ALTER USER" etc.. This clause sets the specific action or configuration to all available PDBs, as well as future PDBs
• Control files, REDO Logs, and UNDO files are owned by ROOT Container as these Database files are Instance specific. Every PDB has its own set of SYSTEM/SYSAUX/TEMP tablespaces, and also includes the Sample User data such as SCOTT, HR etc..
• ENABLE_PLUGGABE_DATABASE initialization parameter specifies If a particular Database is CDB or Non-CDB
• By default Oracle instance mounts the Pluggable Database, so it has to be manually opened into READ/WRITE Mode. In case of Cluster, it has to be opened in each instance

Basic Monitoring Command Line Instructions

To find If a Database is CDB or Non-CDB

SQL> SELECT NAME, CDB, CON_ID FROM V$DATABASE;

NAME  CDB  CON_ID

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

CONDB  YES       0

[OR]

SQL> SHOW PARAMETER enable_pluggable_database

NAME             TYPE           VALUE

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

enable_pluggable_database     boolean TRUE

To find the Current Database that we are logged in,

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

CDB$ROOT

To find the information about Pluggable Databases,

COL PDB_NAME FOR A30

SELECT PDB_ID,PDB_NAME,STATUS,CON_ID FROM CDB_PDBS;

  PDB_ID PDB_NAME  STATUS    CON_ID

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

3 PDB           NORMAL 1

2 PDB$SEED  NORMAL 1

4 SALESPDB   NORMAL 1

To login to a Container or a specific PDB

There are two ways we can login into a Container or PDB

1. SQLPLUS/CONNECT - This requires a TNS entry to login to a specific PDB locally or remotely

oracle@ora12c ~]$ sqlplus sys/123@PDB as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Sat Jun 29 12:35:02 2013

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

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

PDB

2. ALTER SESSION

SQL> ALTER SESSION SET CONTAINER=SALESPDB;

Session altered.

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

SALESPDB

To switch between Containers using ALTER SESSION,

1. To switch to SEED Container,

SQL> ALTER SESSION SET CONTAINER=PDB$SEED;

Session altered.

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

PDB$SEED

2. To switch to ROOT Container,

SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;

Session altered.

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

CDB$ROOT

To mount or dismount and find the status of a PDB,

SQL> ALTER PLUGGABLE DATABASE PDB OPEN;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE PDB CLOSE IMMEDIATE;

Pluggable database altered.

[OR]

SQL> SHUT IMMEDIATE

Pluggable Database closed.

For multiple PDBs,
SQL> ALTER PLUGGABLE DATABASE PDB,PDB1,SALESPDB OPEN;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE PDB,PDB1,SALESPDB CLOSE;
Pluggable database altered.

SQL> SELECT NAME,OPEN_MODE,TOTAL_SIZE/1024/1024/1024 FROM V$PDBS;

NAME       OPEN_MODE  TOTAL_SIZE/1024/1024/1024
------------------------------ ---------- -------------------------
PDB$SEED       READ ONLY .263671875
PDB       READ WRITE .424804688
SALESPDB       MOUNTED  0

To modify any PDB Characteristics,

"ALTER PLUGGABLE DATABASE" is the command replaces "ALTE DATABASE" command in a CDB Environment. For example If the goal is to change the default tablespace of a PDB,

1. Tablespace must be created within the PDB

2. Use the below command to change it,

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

PDB

SQL> CREATE TABLESPACE TS_PDB DATAFILE '/dbs/CONDB/PDB/ts_pdb_01.dbf' SIZE 10M;

Tablespace created.

SQL> ALTER PLUGGABLE DATABASE PDB DEFAULT TABLESPACE TS_PDB;

Pluggable database altered.

To set an initialization Parameter,
A Parameter can be set exclusive to a PDB, or for all current and future PDBs using "ALTER SYSTEM" command.
On the root container:
SQL> ALTER SYSTEM SET RESOURCE_LIMIT=TRUE CONTAINER=ALL;
System altered.

On a specific container or PDB:
SQL> ALTER SYSTEM SET RESOURCE_LIMIT=TRUE;
System altered.

To create a user in the ROOT Container and accessing other PDBs,

A CDB has common user environment. A User exists in the ROOT Container can login to any PDB with the privileges given and by default it is mapped to all available PDBs and future PDBs. A CDB also has local users exclusive to PDBs.

• A Common user and role name must start with C## or c## and consists only of ASCII characters.
• To login to a specific PDB, A Common user must have CREATE SESSION Privilege on the PDB.

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

CDB$ROOT

SQL> CREATE USER C##PDB IDENTIFIED BY PDB;

User created.

SQL> GRANT CREATE SESSION TO C##PDB;

Grant succeeded.

SQL> GRANT CREATE SESSION TO C##PDB CONTAINER=ALL; (ALL Specifies all Containers or PDBs)

Grant succeeded.

SQL> CONNECT C##PDB@PDB

Enter password: 

Connected.

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')

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

PDB

SQL> SHOW USER

USER is "C##PDB"

Hope it helps.