Home » RDBMS Server » Server Administration » dba_tables.container_data (DB 12.1.x)
dba_tables.container_data [message #621701] Sat, 16 August 2014 10:45 Go to next message
John Watson
Messages: 6854
Registered: January 2010
Location: Global Village
Senior Member
This column is the last column in the %_TABLES views. In the CDB I happen to be working on, it is always set to NO:
cdba> alter session set container=cdb$root;

Session altered.

cdba> select container_Data,count(*) from cdb_tables group by container_data;

--- ----------
NO        9271

The docs says this,Quote:
Indicates whether the table contains container-specific data. Possible values:
YES if the table was created with the CONTAINER_DATA clause
NO otherwise
but I can find no explanation of this clause. Any ideas? Perhaps a way of creating shared tables? I've had a look through ?/rdbms/admin, but I can't find any example of it being used.

Thank you for any insight.
Re: dba_tables.container_data [message #621717 is a reply to message #621701] Sat, 16 August 2014 12:10 Go to previous messageGo to next message
Michel Cadot
Messages: 64627
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator

It could be something that Oracle has in mind to implement but does not yet exist.
Just like the edition in 11.1. You have the ORA$BASE edition and many edition views like DBA_EDITIONS but when you try to execute CREATE EDITION you get an error as the command does not exist:
SQB> @v

Version Oracle :

SQB> select * from dba_editions;
EDITION_NAME                   PARENT_EDITION_NAME            USA
------------------------------ ------------------------------ ---
ORA$BASE                                                      YES

1 row selected.

ERROR at line 1:
ORA-00901: invalid CREATE command

Maybe we have to wait for 12.2. Smile

[Updated on: Sat, 16 August 2014 12:11]

Report message to a moderator

Re: dba_tables.container_data [message #621780 is a reply to message #621717] Mon, 18 August 2014 05:09 Go to previous messageGo to next message
John Watson
Messages: 6854
Registered: January 2010
Location: Global Village
Senior Member
Thank you for replying. Perhaps that is all it is. I was hoping that someone might have reverse engineered something amazing.
Re: dba_tables.container_data [message #621787 is a reply to message #621701] Mon, 18 August 2014 06:48 Go to previous message
Lalit Kumar B
Messages: 3122
Registered: May 2013
Location: World Wide on the Web
Senior Member
After looking at your post, I spent 2 hours reading the docs about the CONTAINER_DATA clause. I found very little information, and NO examples at all. About the CONTAINER_DATA clause, I couldn't find it's attributes explained anywhere.

From docs,

These attributes determine the set of containers (which can never exclude the root) whose data will be visible via CONTAINER_DATA objects to the specified common user when the current session is the root.

So, it means, the current session container should be CDB$ROOT if we want the changes for a user to be reflected across entire CDB. Else, if current container is a PDB, we can set the attributes for a common user specific only to local PDB. So all that is explained is about "which container name to specify".

For example, I have a user 'A' in CDB, let's say current container is root CDB$ROOT, the alter user statement required to set the container data attributes for user 'A would look something like this :

alter user 'A' set container_data = ALL for schema.object_name; -- container name is ALL since user is in CDB$ROOT

So, finally this is what I conclude with limited understanding : User 'A' will now be able to access the data belonging to the containers that we have set him to via alter statement.

Did I try doing all this myself? Yes, but I keep getting errors for which I am reading further Sad
Previous Topic: Help about Log file Oracle
Next Topic: what is the procedure to select mysql database data from oracle 11g
Goto Forum:

Current Time: Thu Mar 30 07:51:11 CDT 2017

Total time taken to generate the page: 0.08386 seconds