Re: Pluggable database in 12C
Date: Thu, 18 Oct 2012 07:08:37 -0700 (PDT)
Message-ID: <7a43902d-d300-46e4-b90b-3677127d636f_at_googlegroups.com>
On Thursday, October 18, 2012 3:21:53 AM UTC-6, Jonathan Lewis wrote:
> "Noons" <wizofoz2k_at_yahoo.com.au> wrote in message
>
> news:k5ogqf$bds$1_at_dont-email.me...
>
> |
>
> | 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
>
> http://jonathanlewis.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' 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 Received on Thu Oct 18 2012 - 16:08:37 CEST