Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id 02AAC196013B for ; Fri, 6 Jun 2014 14:51:26 +0200 (CEST) Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTP for ; Fri, 6 Jun 2014 14:51:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DA75F2C34B; Fri, 6 Jun 2014 08:51:24 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf55OIjcq5rz; Fri, 6 Jun 2014 08:51:24 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BF7D42BCB0; Fri, 6 Jun 2014 08:50:43 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 06 Jun 2014 08:50:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 893802BC6B for ; Fri, 6 Jun 2014 08:50:02 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB+hdWdzqMd0 for ; Fri, 6 Jun 2014 08:50:02 -0400 (EDT) Received: from troll.tpk.net (mail.tpk.net [216.107.198.11]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E769128655 for ; Fri, 6 Jun 2014 08:49:34 -0400 (EDT) Received: from mwf4500 (c-50-133-134-194.hsd1.ma.comcast.net [50.133.134.194]) by troll.tpk.net (8.14.2/8.12.11) with ESMTP id s56CnUK1026929; Fri, 6 Jun 2014 08:49:31 -0400 From: "Mark W. Farnham" To: , Cc: , "'John Hallas'" , References: <53798766.9060907@gmail.com> <53e07c9a-b006-4da6-931c-4e859544cf65@default> <537A760D.3060700@gmail.com> <4796f4aa-c3f4-4502-8b82-ee7b405218bb@default> <537AD6B2.6010105@oracle.com> <537B6276.1080504@gmail.com> <537B823A.6020108@oracle.com> <537B8437.4090402@gmail.com> <537BF6E9.9040508@gmail.com> <5390D874.1090503@gmail.com> In-Reply-To: Subject: RE: DB12c in Production? Date: Fri, 6 Jun 2014 08:49:28 -0400 Message-ID: <114d01cf8185$c202ca70$46085f50$@rsiz.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_114E_01CF8164.3AF12A70" Content-Language: en-us X-archive-position: 54868 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: mwf@rsiz.com Precedence: normal Reply-To: mwf@rsiz.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l ------=_NextPart_000_114E_01CF8164.3AF12A70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A single PDB in a multi-tenant architecture does not invoke the = multi-tenant upcharge in any license documentation I have seen. IF it = did, I think all of Niall=E2=80=99s concerns would be valid. =20 Multiple container databases (each with one PDB) on a single machine (or = RAC cluster) would emulate the existing architecture with no upcharge = for being =E2=80=9Ccontainerized.=E2=80=9D No fee would be invoked for moving a PDB from one container to another = (as long as the total tenant count of any container is 0 or 1.) That = feature supports unplug =E2=80=93 plug upgrades (although there are = technical considerations about flashback history and point-in-time = recovery to the past that should be carefully considered.) =20 I believe Hans is correct. =20 The terminology IS strained, because they started calling it = =E2=80=9Cmulti-tenant=E2=80=9D to promote that feature AS IF every = containerized database deployment will in fact have greater than 1 PDB = resident. =20 The huge growth in process count of background jobs (which facilitates = not time slicing each other for waits) makes deploying multiple = databases expensive in machine resource footprint. =20 Figuring out the license cost matrix (can I use a smaller enough chip = count due to process reduction so that license is less by enough to pay = for the upcharge for multi-tenant at resident count over 1) to net = benefit seems difficult to forecast. =20 The logical obstacles to database consolidation remain, for example = patch cycles and support certification. The multitenant architecture = DOES help with that by creating the possibility of a small number of = =E2=80=9Ccontainers=E2=80=9D each at a different release level, with the = PDBs smoothly moving forward by the unplug =E2=80=93 plug upgrade = operation without forcing consolidation on databases that should not be = consolidated. So if you have 10 databases that would be awkward to = consolidate, maybe having only, say, 3 containers up and running would = be sufficient and reduce the background process count to 30 percent of = what it would have been. How many chips will that save? I don=E2=80=99t = know. It seems like a one-off calculation for each implementation. =20 Unless your salesman=E2=80=99s name is Ed Rearick, you probably have to = figure out your own best net benefit. (Ed sold computers for Sequent, = and he believed getting the best value matrix to his customers = ultimately paid off for his customers, his company, and himself in the = long run. Plus he slept like a baby. Oh how I wish we could clone him to = be deployed as an Oracle saleman!) =20 mwf =20 From: oracle-l-bounce@freelists.org = [mailto:oracle-l-bounce@freelists.org] On Behalf Of Jeremy Schneider Sent: Friday, June 06, 2014 8:04 AM To: niall.litchfield@gmail.com Cc: fuzzy.graybeard@gmail.com; John Hallas; oracle-l@freelists.org Subject: Re: DB12c in Production? =20 Is the extra cost option for using PDBs at all or is it for having more = than one PDB? =20 -Jeremy -- http://about.me/jeremy_schneider Sent from my iPhone On Jun 6, 2014, at 6:20 AM, Niall Litchfield = wrote: On Thu, Jun 5, 2014 at 9:52 PM, Hans Forbrich = wrote: Three things come to mind 1) The non-multi-tenant architecture is known as the 'Pre-12c' = architecture. In other words, in the future, we will have no choice. =20 I agree that the wording and marketing tends to point in that direction. = However I consider it unlikely that the old architecture will disappear = any time soon for one major reason. Multi-tenant has been introduced as = an extra cost option, and its an option I think a reasonable number of = customers, but by no means all will pay for. A future decision for = Oracle to drop support for the option would have to do one or more of = the below (or some other smart alternative).=20 =20 * make multi-tenant part of the base license killing a revenue stream.=20 * make existing customers who don't see value in multi-tenant pay for it = (reducing a revenue stream).=20 * make it cost neutral or advantageous to move to multi-tenant (perhaps = by playing with overall discount rates for those who purchase it) =20 * allow multi-tenant for SE customers I suspect that any of the above will be difficult and have unexpected = side effects.=20 =20 --=20 Niall Litchfield Oracle DBA http://www.orawin.info=20 ------=_NextPart_000_114E_01CF8164.3AF12A70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A single PDB in a multi-tenant architecture does not invoke the = multi-tenant upcharge in any license documentation I have seen. IF it = did, I think all of Niall=E2=80=99s concerns would be = valid.

 

Multiple container databases (each with one PDB) on a single machine = (or RAC cluster) would emulate the existing architecture with no = upcharge for being = =E2=80=9Ccontainerized.=E2=80=9D

No fee would be invoked for moving a PDB from one container to = another (as long as the total tenant count of any container is 0 or 1.) = That feature supports unplug =E2=80=93 plug upgrades (although there are = technical considerations about flashback history and point-in-time = recovery to the past that should be carefully = considered.)

 

I believe Hans is correct.

 

The terminology IS strained, because they started calling it = =E2=80=9Cmulti-tenant=E2=80=9D to promote that feature AS IF every = containerized database deployment will in fact have greater than 1 PDB = resident.

 

The huge growth in process count of background jobs (which = facilitates not time slicing each other for waits) makes deploying = multiple databases expensive in machine resource = footprint.

 

Figuring out the license cost matrix (can I use a smaller enough chip = count due to process reduction so that license is less by enough to pay = for the upcharge for multi-tenant at resident count over 1) to net = benefit seems difficult to forecast.

 

The logical obstacles to database consolidation remain, for example = patch cycles and support certification. The multitenant architecture = DOES help with that by creating the possibility of a small number of = =E2=80=9Ccontainers=E2=80=9D each at a different release level, with the = PDBs smoothly moving forward by the unplug =E2=80=93 plug upgrade = operation without forcing consolidation on databases that should not be = consolidated. So if you have 10 databases that would be awkward to = consolidate, maybe having only, say, 3 containers up and running would = be sufficient and reduce the background process count to 30 percent of = what it would have been. How many chips will that save? I don=E2=80=99t = know. It seems like a one-off calculation for each = implementation.

 

Unless your salesman=E2=80=99s name is Ed Rearick, you probably have = to figure out your own best net benefit. (Ed sold computers for Sequent, = and he believed getting the best value matrix to his customers = ultimately paid off for his customers, his company, and himself in the = long run. Plus he slept like a baby. Oh how I wish we could clone him to = be deployed as an Oracle saleman!)

 

mwf

 

From:= = oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] = On Behalf Of Jeremy Schneider
Sent: Friday, June 06, = 2014 8:04 AM
To: niall.litchfield@gmail.com
Cc: = fuzzy.graybeard@gmail.com; John Hallas; = oracle-l@freelists.org
Subject: Re: DB12c in = Production?

 

Is the = extra cost option for using PDBs at all or is it for having more than = one PDB?

 

-Jeremy

--

Sent from my = iPhone


On Jun 6, 2014, at 6:20 AM, Niall = Litchfield <niall.litchfield@gmail.com= > wrote:

On Thu, Jun 5, 2014 at 9:52 PM, Hans Forbrich <fuzzy.graybeard@gmail.com> = wrote:

Three things come to = mind

1) The non-multi-tenant architecture is known as the = 'Pre-12c' architecture.  In other words, in the future, we will = have no choice.

 

I = agree that the wording and marketing tends to point in that direction. = However I consider it unlikely that the old architecture will disappear = any time soon for one major reason. Multi-tenant has been introduced as = an extra cost option, and its an option I think a reasonable number of = customers, but by no means all will pay for. A future decision for = Oracle to drop support for the option would have to do one or more of = the below (or some other smart = alternative). 

 

  • make multi-tenant part of the base license killing a = revenue stream. 
  • make existing customers who don't see value in multi-tenant = pay for it (reducing a revenue stream). 
  • make it cost neutral or advantageous to move to = multi-tenant (perhaps by playing with overall discount rates for those = who purchase it)  
  • allow multi-tenant for SE = customers

I suspect = that any of the above will be difficult and have unexpected side = effects. 


 

-- =
Niall Litchfield
Oracle DBA
http://www.orawin.info =

------=_NextPart_000_114E_01CF8164.3AF12A70-- -- http://www.freelists.org/webpage/oracle-l