Very informative! Again, very impressed. This helped me so much. I was trying to create a new connection and a new user directly from a CDB and was frustrated why it kept telling me that my username or password was incorrect. Now I know! Oracle should summarize your two videos on 18c and throw it into a readme for newbies like myself.
you prolly dont care at all but does someone know of a way to get back into an Instagram account..? I somehow forgot the password. I love any assistance you can offer me
Thank you for explanation. We are using 11g and going for 19c. in 11g we have 3 databases, and all databases have different Sys and System Passwords for security reasons. But If we migrate 11g DB to 19c as PDB, SYS and SYSTEM password will be Changed to CDB. Right?
Thanks for the comment! A common user (e.g., SYS, SYSTEM) is defined in the root or CDB and is known to every container or PDB. Every common user can connect to and perform operations within any container, CDB or PDB. Here is some rather detailed information to answer your question. The process of consolidating data from multiple databases into one database on one computer is known as database consolidation. Oracle Multitenant allows consolidation of data and code without altering existing schemas or applications. Oracle Multitenant is supported by an architecture that allows a container database (CDB) to hold many pluggable databases (PDB). By consolidating databases as PDBs, administrators can manage many database as one. Tasks like backup and disaster recovery are performed at the CDB level. From the perspective of a client connecting via Oracle Net, the PDB is the database. From the point of view of the operating system, the CDB is the database. A single CDB can contain many PDBs, where each is, ultimately, its own set of self-contained data files. Each PDB defines a private namespace for all the phenomena, like users, roles, public synonyms, and so on. In releases of Oracle Database prior to 12c, we had a "non-CDB" database where each name must be unique within the whole database. Thus, each PDB in a particular CDB can have a user called Scott. It follows that the result of granting privileges and roles to such users is reflected within a PDB. Every CDB exactly one root container. The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages. A common user is a database user known in every container. PDBs isolate data and operations so that from the perspective of a user or application, each PDB appears as if it were a traditional non-CDB. A common user is a database user that has the same identity in the root and in every existing and future PDB. Every common user can connect to and perform operations within the root, and within any PDB in which it has privileges. Every common user is either Oracle-supplied or user-created. Examples of Oracle-supplied common users are SYS and SYSTEM. The operations that a common user can perform depend on the privileges granted to the common user. Some administrative tasks, such as creating a PDB or unplugging a PDB, must be performed by a common user. A local user is a user that exists in exactly one PDB. All Oracle-supplied administrative user accounts are common users and can navigate across the CDB. Common users can have different privileges in different PDBs. For example, the common user SYSTEM can switch between PDBs and use privileges granted to SYSTEM in the current PDB. In a multitenant environment, a local user is a database user that exists only in a PDB. Local users can have administrative privileges, but these privileges apply only in the PDB in which that user account was created.
I like your teaching approach. Thank you... We are moving from Oracle 12.1.0.2 to version 19c. But we did NOT utilize container data bases when we migrated from V11 to V12. I did not, and still don't see the advantages for our small applications, of the multitenant architecture. But I was told we need to move to Container data bases, or we will be out of support with 20c. I need to study this more I know, but the question that I have after watching this video is: Can I think of the PDB as our data base schema? For instance, in V11 (and V12 the way we implemented it) I would access a table like this: CITY.USER_TABLE. Is CITY a PDB now?
From the perspective of an application, a PDB behaves the same as a non-CDB as seen from a client connecting with Oracle Net. This was demonstrated in the video (Installing Oracle 18c Express Edition) by working with the PDB named XEPDB1. A tnsnames entry is defined and the process of connecting from a client such as SQL Developer or SQLPLUS is the same as would have done for a non-CDB. An application is unaware of whether it has connected to a non-CDB or a PDB. The schema for an application, e.g., tables and PL/SQL objects, is defined in a PDB in the same way you would do this with a non-CDB in earlier releases. Thus, assuming that CITY owns the tables, there would be no difference in the way you refer to the tables. The PDB itself is not really a schema, but can be used to separate data for different application systems.
Thank you - very good explanation
Glad you liked it
Thank you so much for the clear explanation!
Happy to hear that you found it helpful. Thanks for the comment.
Very useful and explained well Sir..
Thank you. I am glad you found it useful.
Absolutely incredible explanation. Cant say how much I liked your explanation !
Great to hear! Thank you!
Very well explained, thanks a lot
You are welcome
Very Informative Session sir !!!!!
Thanks.
Very informative! Again, very impressed. This helped me so much. I was trying to create a new connection and a new user directly from a CDB and was frustrated why it kept telling me that my username or password was incorrect. Now I know!
Oracle should summarize your two videos on 18c and throw it into a readme for newbies like myself.
you prolly dont care at all but does someone know of a way to get back into an Instagram account..?
I somehow forgot the password. I love any assistance you can offer me
Really Helpful .. Thanks
Glad it was helpful!
Very good content!
Glad you think so!
thank you professor.
You are quite welcome.
Good session sir
Thanks and welcome
Very nicely done and informative!!!
Thanks.
Perfect and thank you for nice post.
Thanks for listening
Thank you for explanation. We are using 11g and going for 19c. in 11g we have 3 databases, and all databases have different Sys and System Passwords for security reasons. But If we migrate 11g DB to 19c as PDB, SYS and SYSTEM password will be Changed to CDB. Right?
Thanks for the comment!
A common user (e.g., SYS, SYSTEM) is defined in the root or CDB and is known to every container or PDB. Every common user can connect to and perform operations within any container, CDB or PDB.
Here is some rather detailed information to answer your question.
The process of consolidating data from multiple databases into one database on one computer is known as database consolidation. Oracle Multitenant allows consolidation of data and code without altering existing schemas or applications. Oracle Multitenant is supported by an architecture that allows a container database (CDB) to hold many pluggable databases (PDB). By consolidating databases as PDBs, administrators can manage many database as one. Tasks like backup and disaster recovery are performed at the CDB level.
From the perspective of a client connecting via Oracle Net, the PDB is the database. From the point of view of the operating system, the CDB is the database.
A single CDB can contain many PDBs, where each is, ultimately, its own set of self-contained data files. Each PDB defines a private namespace for all the phenomena, like users, roles, public synonyms, and so on. In releases of Oracle Database prior to 12c, we had a "non-CDB" database where each name must be unique within the whole database. Thus, each PDB in a particular CDB can have a user called Scott.
It follows that the result of granting privileges and roles to such users is reflected within a PDB.
Every CDB exactly one root container. The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages. A common user is a database user known in every container.
PDBs isolate data and operations so that from the perspective of a user or application, each PDB appears as if it were a traditional non-CDB.
A common user is a database user that has the same identity in the root and in every existing and future PDB. Every common user can connect to and perform operations within the root, and within any PDB in which it has privileges. Every common user is either Oracle-supplied or user-created. Examples of Oracle-supplied common users are SYS and SYSTEM.
The operations that a common user can perform depend on the privileges granted to the common user. Some administrative tasks, such as creating a PDB or unplugging a PDB, must be performed by a common user. A local user is a user that exists in exactly one PDB.
All Oracle-supplied administrative user accounts are common users and can navigate across the CDB. Common users can have different privileges in different PDBs. For example, the common user SYSTEM can switch between PDBs and use privileges granted to SYSTEM in the current PDB.
In a multitenant environment, a local user is a database user that exists only in a PDB. Local users can have administrative privileges, but these privileges apply only in the PDB in which that user account was created.
I like your teaching approach. Thank you... We are moving from Oracle 12.1.0.2 to version 19c. But we did NOT utilize container data bases when we migrated from V11 to V12. I did not, and still don't see the advantages for our small applications, of the multitenant architecture. But I was told we need to move to Container data bases, or we will be out of support with 20c. I need to study this more I know, but the question that I have after watching this video is: Can I think of the PDB as our data base schema? For instance, in V11 (and V12 the way we implemented it) I would access a table like this: CITY.USER_TABLE. Is CITY a PDB now?
From the perspective of an application, a PDB behaves the same as a non-CDB as seen from a client connecting with Oracle Net. This was demonstrated in the video (Installing Oracle 18c Express Edition) by working with the PDB named XEPDB1. A tnsnames entry is defined and the process of connecting from a client such as SQL Developer or SQLPLUS is the same as would have done for a non-CDB. An application is unaware of whether it has connected to a non-CDB or a PDB.
The schema for an application, e.g., tables and PL/SQL objects, is defined in a PDB in the same way you would do this with a non-CDB in earlier releases. Thus, assuming that CITY owns the tables, there would be no difference in the way you refer to the tables. The PDB itself is not really a schema, but can be used to separate data for different application systems.
Thank you so much !!!
You're welcome!