Re: Pluggable database in 12C

From: Mark D Powell <>
Date: Wed, 24 Oct 2012 11:16:51 -0700 (PDT)
Message-ID: <>

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" <> wrote in message > > news:k5ogqf$bds$ > > | > > | Last bit of info I have indicates they got it completely wrong: all PDBs > > share > > | the same container redo log set! Talk about contention... > > | One of the *biggest* advantages MSSQL has in this 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... > > | > > > > > > That 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 in reply to the "you only need one of each background > > process for the whole system rather than one of each for each database." > > > > The follow-up 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 have 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 about thinking about it. > > > > Regards > > > > Jonathan Lewis > > > > > > Author: Oracle Core (Apress 2011) > > I agree that the single set of LGWR processes will be the Achiles' heel of the 'pluggable database' revolution. 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 correctly) have transaction logs for each database, not a single set for the entire server, so that contention between database transaction logging shouldn't happen. That Oracle couldn't think that far ahead ... well, I suppose the marketing department was getting a lot of grumpy email and feedback on the fact that 12c had been announced for quite a while but nothing was ever said 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 contention after they load up their containers with several fairly active databases each) as the hoi paloi will not stand for such an obvious and correctable performance problem (again, if Sybase, SQL Server and MySQL can prevent 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 RAC you have one instance, one database, one log now. If you split the database schema into their own containers do you really have any more logging activity to be handled that what the log writer process is currently handling? In other words is this really an issue now?

Now if you have 10 RAC databases on one server like we do (mostly vendor products) 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 instance about 4X so them maybe the logging would be an issue. But I do not consider this type of consolidation to be the likely norm any time soon.

IMHO -- Mark D Powell -- Received on Wed Oct 24 2012 - 20:16:51 CEST

Original text of this message