Create 12c or 18c database in traditional architecture

["Yong Huang" (Redacted sender "yong321" for DMARC)]

When creating a 12c or 18c database without the multitenancy license, I can (1) create the database with one CDB and only one PDB, or (2) create the database in the traditional or non-CDB architecture. The advantage of (2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and slightly easier management. But the disadvantage is that Oracle does not recommend it and that "(t)he non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c."

Short of a formal survey, I'd like to know which option you all have chosen. Thank you!

Yong Huang

[Testa, Joseph S]

Definitely the single CDB/PDB concept, that way people get used to it and it will still be supported in later versions.

Joe


-------------------------------
Quit doing what is easy and do what is right.

[Joe_Testa_Color_LinkedIn-2]

Joseph Testa
Database Services Security

From: oracle-l-***@freelists.org [mailto:oracle-l-***@freelists.org] On Behalf Of Yong Huang
Sent: Tuesday, August 28, 2018 12:00 PM
To: Oracle-l Digest Users <oracle-***@freelists.org>
Subject: [EXTERNAL] Create 12c or 18c database in traditional architecture

Nationwide Information Security Warning: This is an external email. Do not click on links or open attachments unless you trust the sender.
________________________________

When creating a 12c or 18c database without the multitenancy license, I can (1) create the database with one CDB and only one PDB, or (2) create the database in the traditional or non-CDB architecture. The advantage of (2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and slightly easier management. But the disadvantage is that Oracle does not recommend it and that "(t)he non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c."

Short of a formal survey, I'd like to know which option you all have chosen. Thank you!

Yong Huang

[Will Beldman]

There are other advantages to using single CDBs without a multitenancy license
beyond just protection from deprecation. Here is a good article:
https://oracle-base.com/articles/12c/multitenant-pluggable-databases-what-they-will-break-12cr1

Post by "Yong Huang" (Redacted sender "yong321" for DMARC)
When creating a 12c or 18c database without the multitenancy license, I can
(1) create the database with one CDB and only one PDB, or (2) create the
database in the traditional or non-CDB architecture. The advantage of (2)
is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and
slightly easier management. But the disadvantage is that Oracle does not
recommend it and that "(t)he non-CDB architecture was deprecated in Oracle
Database 12c. It can be desupported and unavailable in a release after
Oracle Database 19c."
Short of a formal survey, I'd like to know which option you all have chosen. Thank you!
Yong Huang

[Will Beldman]

That should say single *PDBs*

Post by Will Beldman
There are other advantages to using single CDBs without a multitenancy
license ...

[Tim Hall]

Hi.

I always do lone-PDB unless there is a reason not to, where the
possible reasons are:

- The vendor of a 3rd party product doesn't support the multitenant
architecture. We have one of these.
- Testing of the product proves something to be an issue. We have one
application that has loads of shell scripts that would need
modification, so we've delayed the move to the multitenant
architecture for that DB.

So my assumption is it will be a PDB...

Buggy? I hear a lot of people with the "buggy" excuse, and I'm sure
some have situations, but I've been using PDBs in production from the
release of 12.1.0.2 onward and they've been fine. Mileage will vary of
course.

Overhead? Of course there is additional code-path there, but I would
doubt most users would see a difference.

Easier Management? When I first started looking at PDBs I hated them
and thought it was pointless. As soon as committed to learning them I
got used to them and now I prefer them to old style instances. In a
day to day usage they are no different, but there are some really neat
features that are useful even for lone-PDB. This is especially true in
12.2 onward.

I have a feeling I will be in the minority in this thread. :)

Cheers

Tim...

Post by "Yong Huang" (Redacted sender "yong321" for DMARC)
When creating a 12c or 18c database without the multitenancy license, I can (1) create the database with one CDB and only one PDB, or (2) create the database in the traditional or non-CDB architecture. The advantage of (2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and slightly easier management. But the disadvantage is that Oracle does not recommend it and that "(t)he non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c."
Short of a formal survey, I'd like to know which option you all have chosen. Thank you!
Yong Huang

--
http://www.freelists.org/webpage/oracle-l

["" (Redacted sender "Jay.Miller" for DMARC)]

I argued for the single PDB database model so we could all get familiar with it but was outvoted so we went old school for our 12c databases.


Jay Miller
Sr. Oracle DBA
201.369.8355

From: oracle-l-***@freelists.org [mailto:oracle-l-***@freelists.org] On Behalf Of Yong Huang
Sent: Tuesday, August 28, 2018 12:00 PM
To: Oracle-l Digest Users
Subject: Create 12c or 18c database in traditional architecture

When creating a 12c or 18c database without the multitenancy license, I can (1) create the database with one CDB and only one PDB, or (2) create the database in the traditional or non-CDB architecture. The advantage of (2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and slightly easier management. But the disadvantage is that Oracle does not recommend it and that "(t)he non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c."

Short of a formal survey, I'd like to know which option you all have chosen. Thank you!

Yong Huang

[Mladen Gogala]

I would choose flat database, without a PDB. If you don't need pluggable
databases, then having them is just a nuisance. I know that Oracle
claims that the flat architecture will be desupported, but that hasn't
happened yet. Too many customers with flat databases, I guess. That is
approximately the same question whether you need an AC when moving to
Alaska: probably not. Likelihood that you will have days with 80+ F  is
pretty low in Alaska.

For the record:

I've only been there as a tourist in July, for a week, in the Denali
Natl. Park. I needed long sleeves for both the temperatures and
quarter-pounder mosquitoes. There also some larger animals there that
you would be wise to give a wide berth.


On 08/28/2018 12:00 PM, Yong Huang (Redacted sender yong321 for DMARC)

Post by "Yong Huang" (Redacted sender "yong321" for DMARC)
When creating a 12c or 18c database without the multitenancy license,
I can (1) create the database with one CDB and only one PDB, or (2)
create the database in the traditional or non-CDB architecture. The
advantage of (2) is possibly less buggy, less overhead (no mgmtdb on
RAC for instance), and slightly easier management. But the
disadvantage is that Oracle does not recommend it and that "(t)he
non-CDB architecture was deprecated in Oracle Database 12c. It can be
desupported and unavailable in a release after Oracle Database 19c."
Short of a formal survey, I'd like to know which option you all have chosen. Thank you!
Yong Huang

[Stefan Knecht]

Post by Mladen Gogala
I would choose flat database, without a PDB.

Me too, yes.

Also, when exactly was it that LONG was deprecated? 10 years ago? 15 years?
Yet today it's still all over the place in the dictionary.


//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/

[Mark W. Farnham]

Tim listed a lot of good reasons for single PDB/CDB and gave a really good “except-if” list.



I will add two more reasons pro container, and one is relevant to your mention of long:



Ever try to get a “long” bug fixed or get something about “long” enhanced?



And the code path for PDB/CDB will be more exercised, especially by support.







From: oracle-l-***@freelists.org [mailto:oracle-l-***@freelists.org] On Behalf Of Stefan Knecht
Sent: Tuesday, August 28, 2018 10:34 PM
To: oracle-l-freelists
Subject: Re: Create 12c or 18c database in traditional architecture







On Wed, Aug 29, 2018 at 8:50 AM, Mladen Gogala <***@gmail.com> wrote:

I would choose flat database, without a PDB.

Me too, yes.



Also, when exactly was it that LONG was deprecated? 10 years ago? 15 years? Yet today it's still all over the place in the dictionary.





//

zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!

Visit us at <http://zztat.net/> zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/

[Tim Hall]

Mark: I'll add that to my list. :)

To follow on from Mark's point, do you remember the days when stuff
like LMTs and ASSM got introduced? Soon after we started getting
features that were only available if you were using these features.
The minimum work possible will be done on the original codepath from
now on. Anything new will be coded against multitentant, and only
"back ported" to the old architecture if absolutely necessary. There
are of course features (like sharding) that were initiated before GA
of multitentant, which take time to catch up, but new stuff is
multitenant-first.

We should also consider that Oracle Cloud is multitenant-only. There
are plenty of big companies doing lift-and-shift to Oracle Cloud
because of the licensing savings they are being offered to do it. They
are moving to multitenant. That all adds to the pressure on people to
learn multitenant.

Regarding Mladen's point, I'm not sure we've had a "true test" of
non-CDB yet. Oracle have committed to non-CDB for the lifetime of the
12.2 release, so theoretically they could have desupported it in 18c,
but if we consider that 18c and 19c are 12.2.0.2 and 12.2.0.3
respectively, it was unlikely they will really attempt to do this
until release 20, which will be the next major release. Of course,
something can be desupported without removing any code path. 18c is
the terminal release of streams, but it remains to be seen if the code
is actually removed in 19c, or just desupported.

Cheers

Tim...
--
http://www.freelists.org/webpage/oracle-l

[Hemant K Chitale]

If you creating a *new* database for a new application you should prefer
Single Tenant PDB.

However, if you are going to use existing administration code, backup
scripts, monitoring scripts etc that run on the database server and use
ORACLE_SID instead of TWO_TASK / TNS, you'd have to modify them -- and that
means they will diverge from the "standard" scripts being used in other
environments.

Similarly, if you have an application that runs on the same server and uses
ORACLE_HOME and ORACLE_SID instead of TWO_TASK / TNS, it would need to
change.

The question would be if you (i.e. the DBA team) are willing to make those
changes to the admin/backup/monitoring scripts and application
configuration and maintain those changes going forward ?


Hemant K Chitale

Post by "Yong Huang" (Redacted sender "yong321" for DMARC)
When creating a 12c or 18c database without the multitenancy license, I
can (1) create the database with one CDB and only one PDB, or (2) create
the database in the traditional or non-CDB architecture. The advantage of
(2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance),
and slightly easier management. But the disadvantage is that Oracle does
not recommend it and that "(t)he non-CDB architecture was deprecated in
Oracle Database 12c. It can be desupported and unavailable in a release
after Oracle Database 19c."
Short of a formal survey, I'd like to know which option you all have chosen. Thank you!
Yong Huang

[Stefan Koehler]

This post might be inappropriate. Click to display it.

[n***@gmail.com]

Hi Yong

We've gone with the traditional architecture so far, the primary reason for
this is that administration scripts and utilities that use ORACLE_SID
and/or TWO_TASK will all require rewriting to ensure they continue to work.
Frankly, we have an incomplete handle on all the available scripts on our
several hundred Oracle servers and almost no view of the ad-hoc etc scripts
that development teams may have placed on our DB servers. Certifying and
communicating the change is also a not insignificant effort for a pretty
small Engineering team. That said our aim is definitely to migrate to the
PDB architecture the 12.2 "family" of releases timescale. We absolutely do
not want to be in a position where we *have* to move faster than we
actually can! Similarly, we've not looked yet at FlexASM but we will do in
a potential feature release.

I don't see single PDB being buggier than the traditional release (I can
see that there will be bugs around the new features of multi-tenant) and
its not true that there's no MGMTDB in a traditional architecture (and from
12.1.0.2 it will be a single instance pdb ! ).

Post by "Yong Huang" (Redacted sender "yong321" for DMARC)
When creating a 12c or 18c database without the multitenancy license, I
can (1) create the database with one CDB and only one PDB, or (2) create
the database in the traditional or non-CDB architecture. The advantage of
(2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance),
and slightly easier management. But the disadvantage is that Oracle does
not recommend it and that "(t)he non-CDB architecture was deprecated in
Oracle Database 12c. It can be desupported and unavailable in a release
after Oracle Database 19c."
Short of a formal survey, I'd like to know which option you all have chosen. Thank you!
Yong Huang

[Neil Chandler]

Personally I think multi-tenant a decent feature but it is cost prohibitive for what you get in return.

There's not enough compelling functional reasons to migrate to the single-PDB model... except for 2 items:

1. What are Oracle using in the Cloud? PDB's. It's only a small percentage of the Oracle installed base at present but that will grow and become the norm.
2. What do Oracles regression tests run against? I don't know the answer to this but I suspect that they mostly run against PDB's now. It's like the old Block Size argument - which block size should you use (answer: 8k only - unless you have a proven case to change size). Oracle regression tests run against 8k and 16k block sizes. There are few (if any) regressions against 32k block sizes in a normal regression run, although that's changing apparently.

I'd imagine its the same with PDB's (and I'm now going to try to find out, unless someone on here knows?) If all of the regressions run against the multi-tenant code path, you should be using the single-PDB model as it'll have fewer bugs.

I see about a 20% adoption rate at my clients of single PDB at the moment, and nobody rushing to embrace it except Tim 😎

Neil Chandler
Database Guy.
________________________________
From: oracle-l-***@freelists.org <oracle-l-***@freelists.org> on behalf of ***@gmail.com <***@gmail.com>
Sent: 29 August 2018 12:21
Cc: ORACLE-L
Subject: Re: Create 12c or 18c database in traditional architecture

Hi Yong

We've gone with the traditional architecture so far, the primary reason for this is that administration scripts and utilities that use ORACLE_SID and/or TWO_TASK will all require rewriting to ensure they continue to work. Frankly, we have an incomplete handle on all the available scripts on our several hundred Oracle servers and almost no view of the ad-hoc etc scripts that development teams may have placed on our DB servers. Certifying and communicating the change is also a not insignificant effort for a pretty small Engineering team. That said our aim is definitely to migrate to the PDB architecture the 12.2 "family" of releases timescale. We absolutely do not want to be in a position where we *have* to move faster than we actually can! Similarly, we've not looked yet at FlexASM but we will do in a potential feature release.

I don't see single PDB being buggier than the traditional release (I can see that there will be bugs around the new features of multi-tenant) and its not true that there's no MGMTDB in a traditional architecture (and from 12.1.0.2 it will be a single instance pdb ! ).

On Tue, Aug 28, 2018 at 5:02 PM Yong Huang <dmarc-***@freelists.org<mailto:dmarc-***@freelists.org>> wrote:
When creating a 12c or 18c database without the multitenancy license, I can (1) create the database with one CDB and only one PDB, or (2) create the database in the traditional or non-CDB architecture. The advantage of (2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and slightly easier management. But the disadvantage is that Oracle does not recommend it and that "(t)he non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c."

Short of a formal survey, I'd like to know which option you all have chosen. Thank you!

Yong Huang

[Tim Hall]

I don't think it's just regression tests that matter. It's the fact that
all the developers are working with it constantly during the development
process, so it's getting a lot of hours over the development process that
non-CDB isn't now.

Regarding the regressions, I remember hearing someone say Oracle are keen
to get rid of the non-CDB stuff as they currently have to do regression
testing on both architectures, so getting rid of non-CDB would halve the
amount of testing necessary. Not sure how accurate that was/is, but it
sounds reasonable. :)

Cheers

Tim...

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.
There's not enough compelling functional reasons to migrate to the
1. What are Oracle using in the Cloud? PDB's. It's only a small
percentage of the Oracle installed base at present but that will grow and
become the norm.
2. What do Oracles regression tests run against? I don't know the
answer to this but I suspect that they mostly run against PDB's now. It's
8k only - unless you have a proven case to change size). Oracle regression
tests run against 8k and 16k block sizes. There are few (if any)
regressions against 32k block sizes in a normal regression run, although
that's changing apparently.
I'd imagine its the same with PDB's (and I'm now going to try to find
out, unless someone on here knows?) If all of the regressions run against
the multi-tenant code path, you should be using the single-PDB model as
it'll have fewer bugs.
I see about a 20% adoption rate at my clients of single PDB at the moment,
and nobody rushing to embrace it except Tim 😎
Neil Chandler
Database Guy.
------------------------------
*Sent:* 29 August 2018 12:21
*Cc:* ORACLE-L
*Subject:* Re: Create 12c or 18c database in traditional architecture
Hi Yong
We've gone with the traditional architecture so far, the primary reason
for this is that administration scripts and utilities that use ORACLE_SID
and/or TWO_TASK will all require rewriting to ensure they continue to work.
Frankly, we have an incomplete handle on all the available scripts on our
several hundred Oracle servers and almost no view of the ad-hoc etc scripts
that development teams may have placed on our DB servers. Certifying and
communicating the change is also a not insignificant effort for a pretty
small Engineering team. That said our aim is definitely to migrate to the
PDB architecture the 12.2 "family" of releases timescale. We absolutely do
not want to be in a position where we *have* to move faster than we
actually can! Similarly, we've not looked yet at FlexASM but we will do in
a potential feature release.
I don't see single PDB being buggier than the traditional release (I can
see that there will be bugs around the new features of multi-tenant) and
its not true that there's no MGMTDB in a traditional architecture (and from
12.1.0.2 it will be a single instance pdb ! ).
When creating a 12c or 18c database without the multitenancy license, I
can (1) create the database with one CDB and only one PDB, or (2) create
the database in the traditional or non-CDB architecture. The advantage of
(2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance),
and slightly easier management. But the disadvantage is that Oracle does
not recommend it and that "(t)he non-CDB architecture was deprecated in
Oracle Database 12c. It can be desupported and unavailable in a release
after Oracle Database 19c."
Short of a formal survey, I'd like to know which option you all have chosen. Thank you!
Yong Huang
--
Niall Litchfield
Oracle DBA
http://www.orawin.info

[Mladen Gogala]

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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

[Franck Pachot]

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.

Post by Mladen Gogala
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
http://www.freelists.org/webpage/oracle-l

[Mladen Gogala]

Hi!

It doesn't work from PDB, but it does work from CDB. I agree that this
is an annoyance.


[***@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
[***@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>

Post by Franck Pachot
Hi all,
In the little annoyances when going to CDB, the major problems I see
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;
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.
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
http://www.freelists.org/webpage/oracle-l

[John Mchugh]

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

Hi!
It doesn't work from PDB, but it does work from CDB. I agree that this is an annoyance.
SQLcl: Release 17.3.0 Production on Wed Aug 29 11:47:29 2018
Copyright (c) 1982, 2018, Oracle. All rights reserved.
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"
SQL>
Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0
SQLcl: Release 17.3.0 Production on Wed Aug 29 11:48:07 2018
Copyright (c) 1982, 2018, Oracle. All rights reserved.
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>

Post by Franck Pachot
Hi all,
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;
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.
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
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: [phone]

[Franck Pachot]

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.

Post by John Mchugh
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
Hi!
It doesn't work from PDB, but it does work from CDB. I agree that this is an annoyance.
SQLcl: Release 17.3.0 Production on Wed Aug 29 11:47:29 2018
Copyright (c) 1982, 2018, Oracle. All rights reserved.
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"
SQL>
Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0
SQLcl: Release 17.3.0 Production on Wed Aug 29 11:48:07 2018
Copyright (c) 1982, 2018, Oracle. All rights reserved.
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>
Hi all,
In the little annoyances when going to CDB, the major problems I see are
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;
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.

Post by Mladen Gogala
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
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: [phone]

[John Mchugh]

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

Post by Franck Pachot
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.
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

Hi!
It doesn't work from PDB, but it does work from CDB. I agree that this is an annoyance.
SQLcl: Release 17.3.0 Production on Wed Aug 29 11:47:29 2018
Copyright (c) 1982, 2018, Oracle. All rights reserved.
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"
SQL>
Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0
SQLcl: Release 17.3.0 Production on Wed Aug 29 11:48:07 2018
Copyright (c) 1982, 2018, Oracle. All rights reserved.
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>

Post by Franck Pachot
Hi all,
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;
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.
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
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: [phone]

[Juan Miranda]

Totally agree.

More cost and more complex administration; just what we need.






-----Mensaje original-----
De: oracle-l-***@freelists.org [mailto:oracle-l-***@freelists.org] En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Para: oracle-***@freelists.org
Asunto: Re: Create 12c or 18c database in traditional architecture

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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]

[Jeff Chirco]

I'ved asked this question over the last couple year to various consultants
and I think on here once. It seemed like the majority of response I got
where that people where still doing the non-CDB traditional install in
Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or
12.2. They do now
2. I wanted to go to 12c quicker than taking the time to learn multitenancy
3. Plus we are migrating from Windows to Linux and 11.2.0.4 to 12.2.01 at
the same time so wanted to limit the amount of things changing and learning
at once.
4. We have 4 databases running on this one server and I just though it was
silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.

I really feel that Multitenancy should be included at no cost. If they
want to de-support traditional install and force us this route it should be
included. Like someone said MSSQL already has this. Or drop the price.
$17,500 per cpu is crazy. If they want use to use it and promote it, it
needs to be included or cheap enough that it is a no-brainier.

Jeff

Post by Juan Miranda
Totally agree.
More cost and more complex administration; just what we need.
-----Mensaje original-----
En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Asunto: Re: Create 12c or 18c database in traditional architecture
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
http://www.freelists.org/webpage/oracle-l

[MacGregor, Ian A.]

I personally was hesitant to move to a new version of the database and to switch to a new architecture at the same time. We have stayed with the non-cdb architecture.


I remember a panel discussion when multi tenancy was first introduced which responded to the question of why MSSQL had "the same thing for free". with you really cannot compare the two, imitating the MSSQL approach to multitenancy was inferior.


How do they differ?


Ian A. MacGregor
SLAC National Accelerator Laboratory



________________________________
From: oracle-l-***@freelists.org <oracle-l-***@freelists.org> on behalf of Jeff Chirco <***@gmail.com>
Sent: Thursday, August 30, 2018 9:41 AM
To: oracle-l-freelist
Subject: Re: Create 12c or 18c database in traditional architecture

I'ved asked this question over the last couple year to various consultants and I think on here once. It seemed like the majority of response I got where that people where still doing the non-CDB traditional install in Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or 12.2. They do now
2. I wanted to go to 12c quicker than taking the time to learn multitenancy
3. Plus we are migrating from Windows to Linux and 11.2.0.4 to 12.2.01 at the same time so wanted to limit the amount of things changing and learning at once.
4. We have 4 databases running on this one server and I just though it was silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.

I really feel that Multitenancy should be included at no cost. If they want to de-support traditional install and force us this route it should be included. Like someone said MSSQL already has this. Or drop the price. $17,500 per cpu is crazy. If they want use to use it and promote it, it needs to be included or cheap enough that it is a no-brainier.

Jeff


On Wed, Aug 29, 2018 at 11:25 PM Juan Miranda <***@hotmail.com<mailto:***@hotmail.com>> wrote:

Totally agree.

More cost and more complex administration; just what we need.






-----Mensaje original-----
De: oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org> [mailto:oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org>] En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Para: oracle-***@freelists.org<mailto:oracle-***@freelists.org>
Asunto: Re: Create 12c or 18c database in traditional architecture

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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]

--
http://www.freelists.org/webpage/oracle-l

[Jeff Chirco]

I am not expert at either but yeah I believe Oracle's PDB's provide a ton
of more features and options than MSSQL. I think they really only similar
in the fact that MSSQL has the System Databases (master, model, msdb,
tempdb) which can be considered similar to the CDB concept. And another
comparison is that you can take a backup from SQL and restore it to another
server database. Even from 2012 to 2016, super simple. Just like plugable
databases.

Post by MacGregor, Ian A.
I personally was hesitant to move to a new version of the database and to
switch to a new architecture at the same time. We have stayed with the
non-cdb architecture.
I remember a panel discussion when multi tenancy was first introduced
which responded to the question of why MSSQL had "the same thing for
free". with you really cannot compare the two, imitating the MSSQL
approach to multitenancy was inferior.
How do they differ?
Ian A. MacGregor
SLAC National Accelerator Laboratory
------------------------------
*Sent:* Thursday, August 30, 2018 9:41 AM
*To:* oracle-l-freelist
*Subject:* Re: Create 12c or 18c database in traditional architecture
I'ved asked this question over the last couple year to various consultants
and I think on here once. It seemed like the majority of response I got
where that people where still doing the non-CDB traditional install in
Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or
12.2. They do now
2. I wanted to go to 12c quicker than taking the time to learn multitenancy
3. Plus we are migrating from Windows to Linux and 11.2.0.4 to 12.2.01 at
the same time so wanted to limit the amount of things changing and learning
at once.
4. We have 4 databases running on this one server and I just though it was
silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.
I really feel that Multitenancy should be included at no cost. If they
want to de-support traditional install and force us this route it should be
included. Like someone said MSSQL already has this. Or drop the price.
$17,500 per cpu is crazy. If they want use to use it and promote it, it
needs to be included or cheap enough that it is a no-brainier.
Jeff
Totally agree.
More cost and more complex administration; just what we need.
-----Mensaje original-----
En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Asunto: Re: Create 12c or 18c database in traditional architecture
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
http://www.freelists.org/webpage/oracle-l

[Mladen Gogala]

Hi Jeff,

What options do Oracle pluggable databases provide that MSSQL does not?

Regards

Post by Jeff Chirco
I am not expert at either but yeah I believe Oracle's PDB's provide a
ton of more features and options than MSSQL.  I think they really only
similar in the fact that MSSQL has the System Databases (master,
model, msdb, tempdb) which can be considered similar to the CDB
concept.  And another comparison is that you can take a backup from
SQL and restore it to another server database.  Even from 2012 to
2016, super simple. Just like plugable databases.

[Mladen Gogala]

Hi Ian,

MSSQL has an isolated "master database" which contains system wide
information like file locations, user permissions, backups etc. It also
has a "template" database MSDB. When the new database is created, the
content of MSDB is copied into the new database. There is also a special
database which is used for sorting and hashing. Yes, the name is TempDB,
or "temporary database" which performs the role of the TEMP tablespace.
By the way, Oracle 18c now allows creating private temporary tables.

Oracle, on the other hand, has a container database, which contains the
central data dictionary and all the tenant databases. Logical separation
is much cleaner with the Microsoft.  As for the claim of Microsoft way
being inferior, I cannot say anything until I hear arguments for such a
claim. Saying that MS approach is inferior to Oracle approach is like
calling CNN "fake news" without any arguments. Who would do something
like that?

Oracle enterprise manager is far inferior to SQL Server data studio, at
least in my opinion. DB2 has another approach, where databases are
completely separate and there is no common data dictionary. From the
practical point of view, all 3 allow me to create a new database. Only
Oracle charges me for that privilege. Oracle justification of the
multi-tenant architecture is that it saves resources. Well, the
resources saved by the multi-tenant architecture are much, much cheaper
than the license for the multi-tenant option.

I remember a panel discussion when  multi tenancy  was first
introduced   which  responded to the question of why MSSQL had "the
same thing for free". with  you really cannot compare the two,
imitating  the MSSQL  approach to multitenancy was  inferior.
How do they differ?

[Givens, Steven]

I agree with your comment on pricing Jeff. I’m dating myself here, but I view this as similar to how Oracle used to charge for the procedural option. It wasn’t long before PL/SQL was bundled into the database offering.

That should happen with multi-tenant as well if Oracle’s direction is to try and force us to use it. As you may have guessed by my age comment, I have way too many scripts that would need modification to use PDBs.

With that said, I’m all for technology enhancements and new functionality. That is what has kept me in this industry this long. I just don’t see the benefit in investing a lot of time in moving to a technology my company wouldn’t purchase anyway.

Steve Givens
Sr Systems Engineer
First National Bank of Omaha


________________________________

From: Jeff Chirco <***@gmail.com>
Date: August 30, 2018 at 11:42:44 AM CDT
To: oracle-l-freelist <oracle-***@freelists.org>
Subject: [External] Re: Create 12c or 18c database in traditional architecture

I'ved asked this question over the last couple year to various consultants and I think on here once. It seemed like the majority of response I got where that people where still doing the non-CDB traditional install in Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or 12.2. They do now
2. I wanted to go to 12c quicker than taking the time to learn multitenancy
3. Plus we are migrating from Windows to Linux and 11.2.0.4<https://urldefense.proofpoint.com/v2/url?u=http-3A__11.2.0.4&d=DwQFaQ&c=LkAXfnqL6_MvrMPL5JzdE3Ild0DUTpmjbCJvMv5_TcQ&r=p64P693r52tzs7tJCmFvOg&m=h-tXL_0zepeBDg4pmabjEFurxmUpJWIGilMNWn3sugE&s=SgynsvS5qgjgv6Y-YG4Tm5r1xZRVTFlxTND4UR7aWrc&e=> to 12.2.01 at the same time so wanted to limit the amount of things changing and learning at once.
4. We have 4 databases running on this one server and I just though it was silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.

I really feel that Multitenancy should be included at no cost. If they want to de-support traditional install and force us this route it should be included. Like someone said MSSQL already has this. Or drop the price. $17,500 per cpu is crazy. If they want use to use it and promote it, it needs to be included or cheap enough that it is a no-brainier.

Jeff


On Wed, Aug 29, 2018 at 11:25 PM Juan Miranda <***@hotmail.com<mailto:***@hotmail.com>> wrote:

Totally agree.

More cost and more complex administration; just what we need.






-----Mensaje original-----
De: oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org> [mailto:oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org>] En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Para: oracle-***@freelists.org<mailto:oracle-***@freelists.org>
Asunto: Re: Create 12c or 18c database in traditional architecture

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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]

--
http://www.freelists.org/webpage/oracle-l[freelists.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl&d=DwMFaQ&c=LkAXfnqL6_MvrMPL5JzdE3Ild0DUTpmjbCJvMv5_TcQ&r=p64P693r52tzs7tJCmFvOg&m=h-tXL_0zepeBDg4pmabjEFurxmUpJWIGilMNWn3sugE&s=ZA53bCQFffavOnz5uuFWsViWO46BiAIrZXOWkIrd3lk&e=>


--
http://www.freelists.org/webpage/oracle-l

[Mladen Gogala]

That did not happen with partitioning option which was, if my memory
serves me right, introduced in Oracle 8i.

Post by Givens, Steven
That should happen with multi-tenant as well if Oracle’s direction is to try and force us to use it. As you may have guessed by my age comment, I have way too many scripts that would need modification to use PDBs.

[Tim Hall]

Not getting into the better/worse debate, but there is a lot of
functionality associated with the multitenant architecture that I
don't believe is present with MySQL and SQL Server, although I'm not
the best DBA for MySQL and SQL Server, so I'm happy to be corrected.
Off the top of my head:

- Hot clones (local and remote).
- Relocate (near zero-downtime).
- Refreshable PDBs.
- Proxy PDBs.
- Metadata-only clones.
- Running commands/queries across all databases.
- Application containers for holding shared applications used by all
other databases. Can be centralised using proxies.
- A bunch of resource management at the PDB level.

I'm not saying you want or care about this, but hot clones are great
and so much easier than RMAN duplicates. All but the last three in
this list are really useful in lone-PDB also, so you don't have to pay
cash to get some of the benefits.

I agree that this should be included in the existing licenses, or at
the least an EE feature, rather than an extra paid for option. Several
people including myself have suggested that even a small number for
free, like 5 for free and pay for more, would make it lots more
attractive. Despite this, I still find it very useful a lone-PDB, but
a lot will depend on what you do.

This is not directed at any individual, but I hope people have spent
some significant time learning this before they make judgements. As
I've mentioned numerous times, I hated it and thought it was stupid
when I first started looking at it. I really didn't get the point of
lone-PDB either. After investing time learning it and using it in real
scenarios I really like it, and when I start working on non-CDB
instances it irritates me. :) Other opinions are valid. :)

Cheers

Tim...
--
http://www.freelists.org/webpage/oracle-l

[MacGregor, Ian A.]

Thank you, there has been a case where Oracle made a paid for option free. Before Oracle 6 there was the Transaction Processing Option which at extra cost provided the row level locking and non-blocking of readers which is now standard. If you already had TPO you received the Procedural Option at no cost.


One might compare the mult-tenant option with the TPO if Oracle is going to support one architecture


UFI-ally



Ian A. MacGregor
SLAC National Accelerator Laboratory
Computing Division
To offer the best IT service at the lab and be the IT provider of choice.
________________________________
From: oracle-l-***@freelists.org <oracle-l-***@freelists.org> on behalf of Tim Hall <***@oracle-base.com>
Sent: Friday, August 31, 2018 3:48:44 AM
To: Oracle-L Freelists
Subject: Re: Create 12c or 18c database in traditional architecture

Not getting into the better/worse debate, but there is a lot of
functionality associated with the multitenant architecture that I
don't believe is present with MySQL and SQL Server, although I'm not
the best DBA for MySQL and SQL Server, so I'm happy to be corrected.
Off the top of my head:

- Hot clones (local and remote).
- Relocate (near zero-downtime).
- Refreshable PDBs.
- Proxy PDBs.
- Metadata-only clones.
- Running commands/queries across all databases.
- Application containers for holding shared applications used by all
other databases. Can be centralised using proxies.
- A bunch of resource management at the PDB level.

I'm not saying you want or care about this, but hot clones are great
and so much easier than RMAN duplicates. All but the last three in
this list are really useful in lone-PDB also, so you don't have to pay
cash to get some of the benefits.

I agree that this should be included in the existing licenses, or at
the least an EE feature, rather than an extra paid for option. Several
people including myself have suggested that even a small number for
free, like 5 for free and pay for more, would make it lots more
attractive. Despite this, I still find it very useful a lone-PDB, but
a lot will depend on what you do.

This is not directed at any individual, but I hope people have spent
some significant time learning this before they make judgements. As
I've mentioned numerous times, I hated it and thought it was stupid
when I first started looking at it. I really didn't get the point of
lone-PDB either. After investing time learning it and using it in real
scenarios I really like it, and when I start working on non-CDB
instances it irritates me. :) Other opinions are valid. :)

Cheers

Tim...
--
http://www.freelists.org/webpage/oracle-l

[Kellyn Pot'Vin-Gorman]

There are a few SQL Server features for the user database architecture that
can compare with multi-tenant features.
-DBCC_Clone database will create, meta data only, read only, (2014,2016)
and read/write databases, (2017).
-At the lower cost of SQL Server, you can easily add Redgate SQL Clone and
or SQL Provision for advanced automation, as Microsoft has a tendency to
leave advanced features to their partners.
-Multiple container technologies- docker, AKS, Kubernetes, etc. are
available for all tiers of the stack.
-Data Factory in Azure can function with onprem or cloud implementations
with kafka, Hadoop or older ETL tools to process data in just about any
fashion needed to one or more sources.

I'm not as up to date on MySQL, so someone else will have to answer that
one... :)



[image: Kellyn Pot'Vin on about.me]

*Kellyn Pot'Vin-Gorman*
DBAKevlar Blog <http://dbakevlar.com>
President Denver SQL Server User Group <http://denversql.org/>
about.me/dbakevlar

Post by MacGregor, Ian A.
Thank you, there has been a case where Oracle made a paid for option
free. Before Oracle 6 there was the Transaction Processing Option which
at extra cost provided the row level locking and non-blocking of
readers which is now standard. If you already had TPO you received the
Procedural Option at no cost.
One might compare the mult-tenant option with the TPO if Oracle is going
to support one architecture
UFI-ally
Ian A. MacGregor
SLAC National Accelerator Laboratory
Computing Division
To offer the best IT service at the lab and be the IT provider of choice.
------------------------------
*Sent:* Friday, August 31, 2018 3:48:44 AM
*To:* Oracle-L Freelists
*Subject:* Re: Create 12c or 18c database in traditional architecture
Not getting into the better/worse debate, but there is a lot of
functionality associated with the multitenant architecture that I
don't believe is present with MySQL and SQL Server, although I'm not
the best DBA for MySQL and SQL Server, so I'm happy to be corrected.
- Hot clones (local and remote).
- Relocate (near zero-downtime).
- Refreshable PDBs.
- Proxy PDBs.
- Metadata-only clones.
- Running commands/queries across all databases.
- Application containers for holding shared applications used by all
other databases. Can be centralised using proxies.
- A bunch of resource management at the PDB level.
I'm not saying you want or care about this, but hot clones are great
and so much easier than RMAN duplicates. All but the last three in
this list are really useful in lone-PDB also, so you don't have to pay
cash to get some of the benefits.
I agree that this should be included in the existing licenses, or at
the least an EE feature, rather than an extra paid for option. Several
people including myself have suggested that even a small number for
free, like 5 for free and pay for more, would make it lots more
attractive. Despite this, I still find it very useful a lone-PDB, but
a lot will depend on what you do.
This is not directed at any individual, but I hope people have spent
some significant time learning this before they make judgements. As
I've mentioned numerous times, I hated it and thought it was stupid
when I first started looking at it. I really didn't get the point of
lone-PDB either. After investing time learning it and using it in real
scenarios I really like it, and when I start working on non-CDB
instances it irritates me. :) Other opinions are valid. :)
Cheers
Tim...
--
http://www.freelists.org/webpage/oracle-l

["" (Redacted sender "Jay.Miller" for DMARC)]

Or remember how nested tables (whoever thought that was a good idea?) were a separate license as well? Gartner was all over it -" Oracle is finally moving in an object oriented direction. These features will save the database!" Or words to that effect.


Jay Miller
Sr. Oracle DBA
201.369.8355

-----Original Message-----
From: oracle-l-***@freelists.org [mailto:oracle-l-***@freelists.org] On Behalf Of Givens, Steven
Sent: Thursday, August 30, 2018 2:04 PM
To: ***@gmail.com; oracle-l-freelist
Subject: Re: Re: Create 12c or 18c database in traditional architecture

I agree with your comment on pricing Jeff. I'm dating myself here, but I view this as similar to how Oracle used to charge for the procedural option. It wasn't long before PL/SQL was bundled into the database offering.

That should happen with multi-tenant as well if Oracle's direction is to try and force us to use it. As you may have guessed by my age comment, I have way too many scripts that would need modification to use PDBs.

With that said, I'm all for technology enhancements and new functionality. That is what has kept me in this industry this long. I just don't see the benefit in investing a lot of time in moving to a technology my company wouldn't purchase anyway.

Steve Givens
Sr Systems Engineer
First National Bank of Omaha


________________________________

From: Jeff Chirco <***@gmail.com>
Date: August 30, 2018 at 11:42:44 AM CDT
To: oracle-l-freelist <oracle-***@freelists.org>
Subject: [External] Re: Create 12c or 18c database in traditional architecture

I'ved asked this question over the last couple year to various consultants and I think on here once. It seemed like the majority of response I got where that people where still doing the non-CDB traditional install in Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or 12.2. They do now
2. I wanted to go to 12c quicker than taking the time to learn multitenancy
3. Plus we are migrating from Windows to Linux and 11.2.0.4<https://urldefense.proofpoint.com/v2/url?u=http-3A__11.2.0.4&d=DwQFaQ&c=LkAXfnqL6_MvrMPL5JzdE3Ild0DUTpmjbCJvMv5_TcQ&r=p64P693r52tzs7tJCmFvOg&m=h-tXL_0zepeBDg4pmabjEFurxmUpJWIGilMNWn3sugE&s=SgynsvS5qgjgv6Y-YG4Tm5r1xZRVTFlxTND4UR7aWrc&e=> to 12.2.01 at the same time so wanted to limit the amount of things changing and learning at once.
4. We have 4 databases running on this one server and I just though it was silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.

I really feel that Multitenancy should be included at no cost. If they want to de-support traditional install and force us this route it should be included. Like someone said MSSQL already has this. Or drop the price. $17,500 per cpu is crazy. If they want use to use it and promote it, it needs to be included or cheap enough that it is a no-brainier.

Jeff


On Wed, Aug 29, 2018 at 11:25 PM Juan Miranda <***@hotmail.com<mailto:***@hotmail.com>> wrote:

Totally agree.

More cost and more complex administration; just what we need.






-----Mensaje original-----
De: oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org> [mailto:oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org>] En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Para: oracle-***@freelists.org<mailto:oracle-***@freelists.org>
Asunto: Re: Create 12c or 18c database in traditional architecture

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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]

--
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl-5Bfreelists.org-5D&d=DwIF-g&c=nulvIAQnC0yOOjC0e0NVa8TOcyq9jNhjZ156R-JJU10&r=aiKV3Uv2Wo7GqYQcis9TSvB1MZslPOnintrOY1rjG58&m=GFIhk0g9jdRZX1bPt1jQTee54n2NfKd0GbiJirrjM5I&s=mAcTTWEXQaU8zD9Y7BlfRWxQAaW9QEVG48JFp2kUpk0&e=<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl&d=DwMFaQ&c=LkAXfnqL6_MvrMPL5JzdE3Ild0DUTpmjbCJvMv5_TcQ&r=p64P693r52tzs7tJCmFvOg&m=h-tXL_0zepeBDg4pmabjEFurxmUpJWIGilMNWn3sugE&s=ZA53bCQFffavOnz5uuFWsViWO46BiAIrZXOWkIrd3lk&e=>


--
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl&d=DwIF-g&c=nulvIAQnC0yOOjC0e0NVa8TOcyq9jNhjZ156R-JJU10&r=aiKV3Uv2Wo7GqYQcis9TSvB1MZslPOnintrOY1rjG58&m=GFIhk0g9jdRZX1bPt1jQTee54n2NfKd0GbiJirrjM5I&s=31QcxvFi5UxIBpufxdm1ZpKXnTl0z4tWaza0K6onSoI&e=


--
http://www.freelists.org/webpage/oracle-l

[Mladen Gogala]

There is also a much newer example of the "Total Recall" option in 11G
which was quietly included into 12c. It is sort of a neat thing, but the
database archiving is usually done to a DW type database through some
kind of ETL, rather than keeping it in the same database. It looks like
the feature will get included into the next release only if nobody wants
to buy it. Partitioning is available since Oracle 8i and is still a
separate option.

Regards

Post by "" (Redacted sender "Jay.Miller" for DMARC)
Or remember how nested tables (whoever thought that was a good idea?) were a separate license as well? Gartner was all over it -" Oracle is finally moving in an object oriented direction. These features will save the database!" Or words to that effect.
Jay Miller
Sr. Oracle DBA
201.369.8355

[Tim Hall]

Total Recall is actually a pretty good feature, and can do more than
you will get from offloading stuff to a DW. Not only can you do all
the undo-based flashback operations for extended periods of time with
it, but you can also see the application context values that were
present when that data was modified. It can be a good replacement for
the custom application auditing (history tables) people often put in
place in their applications.

Bjoern Rost does a talk where he uses this feature for change data
capture in conjunction with Kafka. It's pretty cool.

The mistake was making it use advanced compression, which made the
advanced compression option mandatory. Making that optional made it
available to the rest of us. I would be interested to know if someone
thought this feature alone would push advanced compression licenses,
which I'm sure it didn't, or if it was just a bad choice that got
changed later...

Cheers

Tim...
--
http://www.freelists.org/webpage/oracle-l

[John Mchugh]

Hi Jeff, all,

some brief comments inline with full disclosure and bias, I work for Oracle and in the MT dev. org. as product management.

Post by MacGregor, Ian A.
I'ved asked this question over the last couple year to various consultants and I think on here once. It seemed like the majority of response I got where that people where still doing the non-CDB traditional install in Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or 12.2. They do now

This was supported as of day 1. See this <https://www.netapp.com/us/media/tr-4266.pdf> jointly published whitepaper.

Post by MacGregor, Ian A.
2. I wanted to go to 12c quicker than taking the time to learn multitenancy

Fair enough.

Post by MacGregor, Ian A.
3. Plus we are migrating from Windows to Linux and 11.2.0.4 to 12.2.01 at the same time so wanted to limit the amount of things changing and learning at once.

Completely understandable.

Post by MacGregor, Ian A.
4. We have 4 databases running on this one server and I just though it was silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.

Did you do any quantitative analysis on compute cost and conservation, comparing the 2 deployment models - 4 stacked v. 4 PDBs in 1 CDB? It would have been very likely that you could run these same 4 DB envs. on smaller compute using MT. The question then becomes is it cost effective. Capex aside, you would also want to evaluate whether there are benefits to be gained from managing
the container as a single entity or continue to manage as 4 distinct DB envs., and to evaluate whether you might gain from online DB agility such as online compute resize or online DB relocation
as examples. Nearly all of our current MT customers have moved beyond the simple consolidation use case to explore DBaaS offerings and what MT might bring to those envs.

There are caveats to all software....you might hit bugs or functional limitations, but we are committed to identify, prioritize and fix them.

Post by MacGregor, Ian A.
I really feel that Multitenancy should be included at no cost. If they want to de-support traditional install and force us this route it should be included. Like someone said MSSQL already has this. Or drop the price. $17,500 per cpu is crazy. If they want use to use it and promote it, it needs to be included or cheap enough that it is a no-brainier.

Way...way above my pay grade...

apologies if this sounds like I am proselytizing...

thx
jpm

Post by MacGregor, Ian A.
Jeff
Totally agree.
More cost and more complex administration; just what we need.
-----Mensaje original-----
Enviado el: miércoles, 29 de agosto de 2018 17:11
Asunto: Re: Create 12c or 18c database in traditional architecture
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
http://www.freelists.org/webpage/oracle-l <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=eVHM5137MVmvnDIuiRpce1B948AiZdid6KgUiIy45rk&m=JNlV1FSC-orRhijbUURGbPlgYEX-Z-b7geK-q45Jb0E&s=CnF0vOahQFkw4RJPIBIOz2MF9AbtmKlFbV9Vh-262Uo&e=>

[Jeff Chirco]

Hi John thanks for your comments. Regarding NetApp - I was on Windows and
I don't think it was supported on that platform. If it was then I was told
or read wrong back then.
I never did any tests with 4 traditional vs 4 PDBs and 1 CDB or 4 on 4.
That would be a good test and I am sure I might be surprised. I should
test that. We have a small footprint and maybe it could help with our CPU
utilization. And having only to patch the one database is really
convenient but then again its just the 4 on this server. But then again
saving time anywhere is beneficial.

Jeff

Post by John Mchugh
Hi Jeff, all,
some brief comments inline with full disclosure and bias, I work for
Oracle and in the MT dev. org. as product management.
I'ved asked this question over the last couple year to various consultants
and I think on here once. It seemed like the majority of response I got
where that people where still doing the non-CDB traditional install in
Production. I went with traditional install for a few reasons
1. In the beginning of testing NetApp storage snaps didn't support PDBs or
12.2. They do now
This was supported as of day 1. See this
<https://www.netapp.com/us/media/tr-4266.pdf> jointly published
whitepaper.
2. I wanted to go to 12c quicker than taking the time to learn multitenancy
Fair enough.
3. Plus we are migrating from Windows to Linux and 11.2.0.4 to 12.2.01 at
the same time so wanted to limit the amount of things changing and learning
at once.
Completely understandable.
4. We have 4 databases running on this one server and I just though it was
silly to have 4 CDBs with 1 PDB each. Maybe this isn't, I don't know.
Did you do any quantitative analysis on compute cost and conservation,
comparing the 2 deployment models - 4 stacked v. 4 PDBs in 1 CDB? It would
have been very likely that you could run these same 4 DB envs. on smaller
compute using MT. The question then becomes is it cost effective. Capex
aside, you would also want to evaluate whether there are benefits to be
gained from managing
the container as a single entity or continue to manage as 4 distinct DB
envs., and to evaluate whether you might gain from online DB agility such
as online compute resize or online DB relocation
as examples. Nearly all of our current MT customers have moved beyond the
simple consolidation use case to explore DBaaS offerings and what MT might
bring to those envs.
There are caveats to all software....you might hit bugs or functional
limitations, but we are committed to identify, prioritize and fix them.
I really feel that Multitenancy should be included at no cost. If they
want to de-support traditional install and force us this route it should be
included. Like someone said MSSQL already has this. Or drop the price.
$17,500 per cpu is crazy. If they want use to use it and promote it, it
needs to be included or cheap enough that it is a no-brainier.
Way...way above my pay grade...
apologies if this sounds like I am proselytizing...
thx
jpm
Jeff

Post by Juan Miranda
Totally agree.
More cost and more complex administration; just what we need.
-----Mensaje original-----
En nombre de Mladen Gogala
Enviado el: miércoles, 29 de agosto de 2018 17:11
Asunto: Re: Create 12c or 18c database in traditional architecture
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

Post by Neil Chandler
Personally I think multi-tenant a decent feature but it is cost
prohibitive for what you get in return.

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
http://www.freelists.org/webpage/oracle-l
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_webpage_oracle-2Dl&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=eVHM5137MVmvnDIuiRpce1B948AiZdid6KgUiIy45rk&m=JNlV1FSC-orRhijbUURGbPlgYEX-Z-b7geK-q45Jb0E&s=CnF0vOahQFkw4RJPIBIOz2MF9AbtmKlFbV9Vh-262Uo&e=>

[Stefan Knecht]

And having only to patch the one database is really convenient but then
again its just the 4 on this server.

... or it might make it more difficult - getting downtime for 4 different
applications at the same time isn't the same business impact as doing the 4
individually at 4 different times - which you can't do if they're all stuck
in the same container.

[John Mchugh]

And having only to patch the one database is really convenient but then again its just the 4 on this server.
... or it might make it more difficult - getting downtime for 4 different applications at the same time isn't the same business impact as doing the 4 individually at 4 different times - which you can't do if they're all stuck in the same container.

Fair point. We try to mitigate this scenario through online relocation operations but they too may come with some caveats. That said, with the experience in our own database cloud services, we are investing considerable engineering effort to optimize these operation to be much faster at scale.

thx
jpm

[Sweetser, Joe]

Regarding #1 below (and in my experience).

While Oracle is using PDB’s by default in their cloud, I am able to create non-PDB/traditional databases with the dbcli create-database command in our OCI (nee Bare Metal) environment. Something like this:


dbcli create-database -n testdb -cl OLTP -s odb4 -v 12.1.0.2 -no-c -u testdb -hm <your-strong-password-here>

The “-no-c” parameter means no container.

https://docs.cloud.oracle.com/iaas/Content/Database/References/dbacli.htm

I do not know of a way to create a non-CDB database through the cloud console. Not that I really looked. Old fart + command line = ME.

-joe


From: oracle-l-***@freelists.org <oracle-l-***@freelists.org> On Behalf Of Neil Chandler
Sent: Wednesday, August 29, 2018 7:24 AM
To: ***@gmail.com
Cc: ORACLE-L <oracle-***@freelists.org>
Subject: Re: Create 12c or 18c database in traditional architecture

Personally I think multi-tenant a decent feature but it is cost prohibitive for what you get in return.
There's not enough compelling functional reasons to migrate to the single-PDB model... except for 2 items:

1. What are Oracle using in the Cloud? PDB's. It's only a small percentage of the Oracle installed base at present but that will grow and become the norm.
2. What do Oracles regression tests run against? I don't know the answer to this but I suspect that they mostly run against PDB's now. It's like the old Block Size argument - which block size should you use (answer: 8k only - unless you have a proven case to change size). Oracle regression tests run against 8k and 16k block sizes. There are few (if any) regressions against 32k block sizes in a normal regression run, although that's changing apparently.

I'd imagine its the same with PDB's (and I'm now going to try to find out, unless someone on here knows?) If all of the regressions run against the multi-tenant code path, you should be using the single-PDB model as it'll have fewer bugs.
I see about a 20% adoption rate at my clients of single PDB at the moment, and nobody rushing to embrace it except Tim 😎

Neil Chandler
Database Guy.
________________________________
From: oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org> <oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org>> on behalf of ***@gmail.com<mailto:***@gmail.com> <***@gmail.com<mailto:***@gmail.com>>
Sent: 29 August 2018 12:21
Cc: ORACLE-L
Subject: Re: Create 12c or 18c database in traditional architecture

Hi Yong

We've gone with the traditional architecture so far, the primary reason for this is that administration scripts and utilities that use ORACLE_SID and/or TWO_TASK will all require rewriting to ensure they continue to work. Frankly, we have an incomplete handle on all the available scripts on our several hundred Oracle servers and almost no view of the ad-hoc etc scripts that development teams may have placed on our DB servers. Certifying and communicating the change is also a not insignificant effort for a pretty small Engineering team. That said our aim is definitely to migrate to the PDB architecture the 12.2 "family" of releases timescale. We absolutely do not want to be in a position where we *have* to move faster than we actually can! Similarly, we've not looked yet at FlexASM but we will do in a potential feature release.

I don't see single PDB being buggier than the traditional release (I can see that there will be bugs around the new features of multi-tenant) and its not true that there's no MGMTDB in a traditional architecture (and from 12.1.0.2 it will be a single instance pdb ! ).

On Tue, Aug 28, 2018 at 5:02 PM Yong Huang <dmarc-***@freelists.org<mailto:dmarc-***@freelists.org>> wrote:
When creating a 12c or 18c database without the multitenancy license, I can (1) create the database with one CDB and only one PDB, or (2) create the database in the traditional or non-CDB architecture. The advantage of (2) is possibly less buggy, less overhead (no mgmtdb on RAC for instance), and slightly easier management. But the disadvantage is that Oracle does not recommend it and that "(t)he non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c."

Short of a formal survey, I'd like to know which option you all have chosen. Thank you!

Yong Huang

["Yong Huang" (Redacted sender "yong321" for DMARC)]

Thanks to all who responded to my question.
Stefan Koehler and Neil: The statistics ("60% non-CDB and 40% single-/multitenant-architecture on newer releases", "about a 20% adoption rate at my clients of single PDB") are quite interesting. Thanks.
Niall: Thanks for correcting me (MGMTDB in a traditional architecture).
John and Franck: The error running "select dbms_metadata.get_ddl('VIEW','DBA_USERS') from dual" in PDB is Bug 18668121, I think.
Hemant and others: We've been running 12c for a while, except for 2 or 3 databases in non-CDB, all in lone-PDB. Modifying scripts didn't take us long. The DBA team now feel comfortable with the new architecture. One production RAC database (lone-PDB) has had several issues, the most serious one being that starting up one instance hangs the whole cluster. The previous SR suggested cleaning up socket files, which we did with full cluster downtime. The new SR called for an IPC-related patch, which needs a cluster shutdown again. There's no clear indication pointing to the CDB/PDB architecture as the culprit (as does the bug Stefan shows). But it prompted me to ask the question here about the community's impression of the new technology. For shops that will never budget for multitenancy like us, we're forced to embrace the architecture. If Oracle says it's the future, then it is.
Yong