Also called EBR, or just editioning, this is a new feature in Oracle 11gR2. A fair amount has already been written about the “how”, and a little bit about the “why”. I’m not going to go over that, but instead present a series of posts about my experiences implementing editioning in a production environment.
First of all, I prefer to call this editioning, but often shorten it to editions, though that could cause some confusion with the whole standard vs enterprise edition thing. In this context I will expect you to understand editions to refer to editioning within the db.
This is a very complex new feature, but Oracle does not charge extra for using it, and I think I know why. At a high level all that editions do is to correct a decades old design flaw in the way Oracle runs code inside the db. In the modern world we expect always up systems, but that is fairly new concept (except for mainframes, which everyone mostly ignores). Back when Oracle was building the engines that run code, hard downtime was acceptable and worth taking to ensure a single point of consistent code execution. This was when there was a movement to put all business logic inside the database. The need for scalability proved that to be ill-advised in many cases, and the rise of a middle tier made it possible to scale out horizontally, and as a side-effect, to run different code versions at the same time — so long as the db portion of the code didn’t require a corresponding change. If it did, you were just out of luck, until the use of editions corrected that deficiency. So Oracle could not charge for what is really a design fix. If they tried to, few would pay for it, preferring to spend that money to move the rest of the business logic out of the db.