4 pluggable databases
source | link

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reached in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. After you change the current schema to USER1 you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are part of a tablespace) and one or more (RAC) instances.

Things get more complicated with 12c multitenant option because you can have multiple pluggable databases (PDB) in a single container database (CDB). But it is just another story.

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reached in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. After you change the current schema to USER1 you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are part of a tablespace) and one or more (RAC) instances.

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reached in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. After you change the current schema to USER1 you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are part of a tablespace) and one or more (RAC) instances.

Things get more complicated with 12c multitenant option because you can have multiple pluggable databases (PDB) in a single container database (CDB). But it is just another story.

3 grammar
source | link

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reachreached in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. WhenAfter you change the current schema to USER1, you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are partspart of a tablespace) and one or more (RAC) instances.

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reach in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. When you change the current schema to USER1, you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are parts of a tablespace) and one or more (RAC) instances.

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reached in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. After you change the current schema to USER1 you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are part of a tablespace) and one or more (RAC) instances.

2 adding "database" description
source | link

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reach in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. When you change the current schema to USER1, you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are parts of a tablespace) and one or more (RAC) instances.

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reach in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. When you change the current schema to USER1, you don't need to append the USER1 prefix anymore.

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reach in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. When you change the current schema to USER1, you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are parts of a tablespace) and one or more (RAC) instances.

1
source | link