Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.databases.oracle.server
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Pluggable database in 12C
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
joel garry  
View profile  
 More options Oct 18 2012, 12:14 pm
Newsgroups: comp.databases.oracle.server
From: joel garry <joel-ga...@home.com>
Date: Thu, 18 Oct 2012 09:14:56 -0700 (PDT)
Local: Thurs, Oct 18 2012 12:14 pm
Subject: Re: Pluggable database in 12C
Print | View thread | Show original | Report this message | Find messages by this author
On Oct 18, 2:21 am, "Jonathan Lewis" <jonat...@jlcomp.demon.co.uk>
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 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 Lewishttp://jonathanlewis.wordpress.com/all_postings

> Author: Oracle Core (Apress 2011)http://www.apress.com/9781430239543

My (admittedly muddled) thoughts on reading Noon's comments were:
Maybe this could really be an extension, conceptually anyways, of
private redo log threads (including the part about falling back to
"old ways" when the "new ways" are inappropriate);  and not to
discount the Exadata ability to write the same thing to different
devices including non-volatile memory - why assume that architecture
would stay specific to Exadata (aside from the obvious milking maximum
money)?  Which kind of begs the question of how to deal with redo when
you have no spinning rust at all (as already kind-of asked on the
forums, and there was a Linus Q&A session on /. where he mentioned his
personal machine).

The stock market discounts 6-12 months ahead.  Physical DB
architecture has to think 5-10 years ahead.

jg
--
@home.com is bogus.
"I think they're Iranians" - http://www.imdb.com/title/tt0080520/alternateversions
http://mobile.nytimes.com/2012/10/14/world/middleeast/us-suspects-ira...


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google