Received: by 10.68.213.103 with SMTP id nr7mr5194962pbc.7.1351102611426;
        Wed, 24 Oct 2012 11:16:51 -0700 (PDT)
Received: by 10.68.219.198 with SMTP id pq6mr5210670pbc.0.1351102611406; Wed,
 24 Oct 2012 11:16:51 -0700 (PDT)
Path: s9ni23372pbb.0!nntp.google.com!kr7no9612683pbb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.databases.oracle.server
Date: Wed, 24 Oct 2012 11:16:51 -0700 (PDT)
In-Reply-To: <7a43902d-d300-46e4-b90b-3677127d636f@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=15.219.169.69;
 posting-account=qJFqbQkAAACYQSLN0-cvP6ydkRfuOu6u
NNTP-Posting-Host: 15.219.169.69
References: <pan.2012.10.18.03.13.15@gmail.com> <k5ogqf$bds$1@dont-email.me>
 <u8qdnR8z8v6sV-LNnZ2dnUVZ8g-dnZ2d@bt.com> <7a43902d-d300-46e4-b90b-3677127d636f@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <216b84a7-313c-4c30-ad2e-977e1e6f6b22@googlegroups.com>
Subject: Re: Pluggable database in 12C
From: Mark D Powell <Mark.Powe...@hp.com>
Injection-Date: Wed, 24 Oct 2012 18:16:51 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, October 18, 2012 10:08:37 AM UTC-4, ddf wrote:
> On Thursday, October 18, 2012 3:21:53 AM UTC-6, Jonathan Lewis wrote: > "=
Noons" <wizofo...@yahoo.com.au> wrote in message > > news:k5ogqf$bds$1@dont=
-email.me... > > | > > | Last bit of info I have indicates they got it comp=
letely wrong: all PDBs > > share > > | the same container redo log set! Tal=
k about contention... > > | One of the *biggest* advantages MSSQL has in th=
is field is that it is > > possible > > | to optimize I/O for each PDB log =
set. > > | With 12c if it stays with a global redo log? Ah yes, of course: =
buy > > Exadata! > > | That's gonna work really well... > > | > > > > > > T=
hat was such an obvious design flaw that I raised it at (I think) one of > =
> the Engineered Systems breakfast seminars. > > > > The point I made was i=
n reply to the "you only need one of each background > > process for the wh=
ole system rather than one of each for each database." > > > > The follow-u=
p answer to this was that you are able to define multiple log > > writers (=
not just I/O slaves for a single log writer). At that point I > > should ha=
ve asked whether these multiple writers would behave like the > > multiple =
log writers you get in RAC, viz: separate log file groups that > > have to =
be resynchronized on recovery - but I didn't ask that question > > because =
it was such an obvious implementation detail that I didn't even > > think a=
bout thinking about it. > > > > Regards > > > > Jonathan Lewis > > http://j=
onathanlewis.wordpress.com/all_postings > > > > Author: Oracle Core (Apress=
 2011) > > http://www.apress.com/9781430239543 I agree that the single set =
of LGWR processes will be the Achiles' heel of the 'pluggable database' rev=
olution. To be fair, though, MySQL got that idea from Sybase years before (=
the same place , I believe, Informix got it) so it's been around for a LONG=
, long time. As Noons mentioned SQL Server (and Sybase, if I remember corre=
ctly) have transaction logs for each database, not a single set for the ent=
ire server, so that contention between database transaction logging shouldn=
't happen. That Oracle couldn't think that far ahead ... well, I suppose th=
e marketing department was getting a lot of grumpy email and feedback on th=
e fact that 12c had been announced for quite a while but nothing was ever s=
aid to solidify WHEN it would be available. I would expect that in 12.2 the=
 LGWR flaw will be corrected (once the early adopters find bucketloads of c=
ontention after they load up their containers with several fairly active da=
tabases each) as the hoi paloi will not stand for such an obvious and corre=
ctable performance problem (again, if Sybase, SQL Server and MySQL can prev=
ent it why can't Oracle). David Fitzjarrell

>> single set of LGWR processes will be the Achiles' heel of the 'pluggable=
 database' revolution <<

Won't that really depend on how your containers are allocated?  Ignorning R=
AC you have one instance, one database, one log now.  If you split the data=
base schema into their own containers do you really have any more logging a=
ctivity to be handled that what the log writer process is currently handlin=
g?  In other words is this really an issue now?

Now if you have 10 RAC databases on one server like we do (mostly vendor pr=
oducts) that for security and upgrade reasons need to be separate if we put=
 them each into a PDB we would be increasing the activty of the one 12c ins=
tance about 4X so them maybe the logging would be an issue.  But I do not c=
onsider this type of consolidation to be the likely norm any time soon.

IMHO -- Mark D Powell --