Re: Create 12c or 18c database in traditional architecture

From: John Mchugh <john.mchugh_at_oracle.com>
Date: Wed, 29 Aug 2018 16:17:46 -0700
Message-Id: <21F3246B-3ABC-4A61-9082-280BDFB1C888_at_oracle.com>



Hi Frank,

took a look at your bug which was logged against App Container. Yea...same issue in generic PDBs where we are trying to do a dbms metadata lookup on shared objects. True for 18.3 too. This is a no-go for the moment in the Multitenant model. And as Mladen points out...you can get it from root as a privileged user. Given the uses cases we are responding to, this makes sense to us where DBaaS/SaaS tenants focus on their content and content meta-data. CDB Admins can look up the dbms metadata.

thx
jpm

> On Aug 29, 2018, at 12:07 PM, Franck Pachot <franck_at_pachot.net> wrote:
> 
> Hi John,
> 
> Thanks a lot. I had SR 3-16538100481 about it, which references bug Bug 22278117 <https://support.oracle.com/epmos/faces/BugDisplay?id=22278117&parent=SrDetailText&sourceId=3-16538100481> that I can’t see but I think it was closed as not a bug because there’s no good mechanism to see LONG cross-container. In my opinion, it is not really a problem per se, we can accept to see only the local container metadata. But we are so used to access many dictionary metadata for years, many tools based on this. The compatibility with non-CDB is a challenge for the new architecture.
> 
> Franck.
> 
> 
> 
> On Wed, Aug 29, 2018 at 7:47 PM John Mchugh <john.mchugh_at_oracle.com <mailto:john.mchugh_at_oracle.com>> wrote:
> Hey, 
> 
> agreed, these are annoyances and we try to capture as much as possible in our s/lrgs. Clearly we missed this.
> This should work when executed in the context of PDB. I didn’t see any bugs logged against this, so  I’ve filed bug 28571259  
> and routed it to the code owner for follow up. 
> 
> As an FYI, both short and large regressions are run in a Multitenant in both single tenant and
> multitenant topologies. We still run a small number of regressions against non-CDBs. 
> 
> thanks,
> jpm
> 
> 

>> On Aug 29, 2018, at 8:51 AM, Mladen Gogala <gogala.mladen_at_gmail.com <mailto:gogala.mladen_at_gmail.com>> wrote:
>>
>> Hi!
>>
>> It doesn't work from PDB, but it does work from CDB. I agree that this is an annoyance.
>>
>>
>> [oracle_at_ora18c ~]$ sql / as sysdba
>>
>> SQLcl: Release 17.3.0 Production on Wed Aug 29 11:47:29 2018
>>
>> Copyright (c) 1982, 2018, Oracle. All rights reserved.
>>
>> Connected to:
>> Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
>> Version 18.3.0.0.0
>>
>>
>> SQL> alter session set container=ORCLPDB;
>>
>> Session altered.
>>
>> SQL> select dbms_metadata.get_ddl('VIEW','DBA_USERS') from dual;
>>
>> Error starting at line : 1 in command -
>> select dbms_metadata.get_ddl('VIEW','DBA_USERS') from dual
>> Error at Command Line : 1 Column : 1
>> Error report -
>> SQL Error: ORA-00904: "DBMS_METADATA"."GET_DDL": invalid identifier
>> 00904. 00000 - "%s: invalid identifier"
>> *Cause:
>> *Action:
>> SQL>
>> Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
>> Version 18.3.0.0.0
>> [oracle_at_ora18c ~]$ sql / as sysdba
>>
>> SQLcl: Release 17.3.0 Production on Wed Aug 29 11:48:07 2018
>>
>> Copyright (c) 1982, 2018, Oracle. All rights reserved.
>>
>> Connected to:
>> Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
>> Version 18.3.0.0.0
>>
>>
>>
>> SQL> select dbms_metadata.get_ddl('VIEW','DBA_USERS') from dual;
>>
>> DBMS_METADATA.GET_DDL('VIEW','DBA_USERS')
>> --------------------------------------------------------------------------------
>>
>> CREATE OR REPLACE FORCE NONEDITIONABLE VIEW "SYS"."DBA_USERS" ("USERNAME", "U
>>
>>
>> SQL>
>>
>>
>>
>> On 08/29/2018 11:27 AM, Franck Pachot wrote:
>>> 
>>> Hi all,
>>> 
>>> In the little annoyances when going to CDB, the major problems I see are related to dictionary views that are partly broken. Things like:
>>> 
>>> Connected to:
>>> Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
>>> Version 18.3.0.0.0
>>> SQL> alter session set container=pdb1;
>>> Session altered.
>>> SQL> select dbms_metadata.get_ddl('VIEW','DBA_USERS') from dual;
>>> ERROR:
>>> ORA-31603: object "DBA_USERS" of type VIEW not found in schema "SYS"
>>> ORA-06512: at "SYS.DBMS_METADATA", line 6681
>>> ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
>>> ORA-06512: at "SYS.DBMS_METADATA", line 6668
>>> ORA-06512: at "SYS.DBMS_METADATA", line 9672
>>> ORA-06512: at line 1
>>> 
>>> Which will probably never been fixed. Probably not a problem in production but I've seen several homemade development frameworks failing on PDB when reading metadata. So it is not only the application and the DBA scripts that have to be tested. The whole tools covering the whole development life-cycle as well.
>>> 
>>> Regards,
>>> Franck.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Aug 29, 2018 at 5:11 PM Mladen Gogala <gogala.mladen_at_gmail.com <mailto:gogala.mladen_at_gmail.com>> wrote:
>>> Hi Neil!
>>> 
>>> Multi-tenant doesn't make any sense because the resources it will save 
>>> are much, much cheaper than the cost of the multi-tenant option. Also, 
>>> the competitors (DB2, SQL Server, SAP Hana) are all allowing creation of 
>>> additional databases for free. I don't see why would I need to pay for 
>>> the same feature with Oracle?
>>> 
>>> Regards
>>> 
>>> 
>>> On 08/29/2018 09:23 AM, Neil Chandler wrote:
>>> > Personally I think multi-tenant a decent feature but it is cost 
>>> > prohibitive for what you get in return.
>>> 
>>> -- 
>>> Mladen Gogala
>>> Database Consultant
>>> Tel: (347) 321-1217
>>> 
>>> --
>>> http://www.freelists.org/webpage/oracle-l <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=eVHM5137MVmvnDIuiRpce1B948AiZdid6KgUiIy45rk&m=d0e4gnr3BG2Oq_XZAZ2QqpIpmJniYwjt9vzHBkUEpqk&s=inmejEd0tCnGrHX_6TuVTI6Q2H-cjvZrj7xX3SpOPJ0&e=>
>>> 
>>> 

>>
>> --
>> Mladen Gogala
>> Database Consultant
>> Tel: (347) 321-1217

>
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Aug 30 2018 - 01:17:46 CEST

Original text of this message