All Things Database: Education, Best Practices,
Use Cases & More

  • November 11, 2017

Configurable Isolation

Patrick Wheeler
Vice President, Product Management

Economies of scale through consolidation are of limited use if that consolidation comes at the expense of isolation. In 12.2 we introduce some very sophisticated capabilities in this area that can ensure great isolation between PDBs and avoid what is colloquially referred to as “the noisy neighbor problem”. Importantly, this is configurable so that the level of isolation can be tailored appropriately for the use case. In general when considering the topic of PDB isolation – one that is especially important in a highly consolidated environment such as a Database Cloud – we need to consider all of the potential risks of sharing. These fall into several categories:

  • Contention for shared computing resources

  • System access

  • File system access

  • Network access

  • Common User or Common Object Access

  • Administrative Features

In 12.2 we build on what was already a powerful suite of isolation capabilities to deliver a comprehensive model, which can simply be configured to deliver precisely the appropriate level of isolation for a particular use case.

These capabilities will be explored in more detail shortly, but before then it is important to understand why a “one size fits all” approach to isolation is not appropriate for the Database Cloud, and why the true requirement is configurable isolation. When considering this topic, it’s helpful to consider a familiar real-world analogy: residential security. At first thought, one might think that the more security the better, but in reality security is a trade-off with convenience. “Maximum Security” is a phrase associated more with a prison than with a home. A home might be more secure with bars on the windows, surrounded by a high wall topped with barbed wire, armed sentries and triple locks on a steel door, but it probably wouldn’t be very nice to live there. On the other hand, leaving all the doors and windows unlocked, while making it easy for the kids to come and go, is likely to result in loss of property. One tries to find the appropriate balance, and that balance will be different in different circumstances. In a dense city environment one is likely to take more precautions than in a suburb where the neighbors are better known. In small towns people sometimes don’t bother to lock at all. Everybody knows what everybody is doing. Security in business hotels is interesting to consider. There’s typically 24-hour security, with cameras in all common areas, security guards and sophisticated keys providing access to the guest rooms. Isn’t it interesting to think how alarming is the prospect that a guest in another room might have access to yours, yet we typically learn to have very little concern that the hotel staff have access to the room literally at countless times during the day without our knowledge (except that perhaps the beds are made and the bathroom is cleaned) and in general even when we’re in the room at night. Somehow in this situation it becomes perfectly acceptable to delegate security to the hotel management.

Similar considerations apply to the Database Cloud in different use cases.

In Database as a Service (DBaaS) on a Public Cloud, it’s reasonable to assume that “adjacent” tenants may be competitors. This is a particularly challenging use case because each tenant wants both powerful administrative capabilities within his own PDB, but also that this PDB is fully isolated from all PDBAs in adjacent PDBs. A good residential analogy here is condominium ownership. One wants full sovereignty over one’s own space. Everything on the inside of the front door is one’s responsibility.

DBaaS on a Private Cloud is a very productive configuration for development teams. Each developer needs to be isolated from the others to the extent that one developer’s test does not interfere with another’s, but it’s typically a collaborative environment in which there is an expectation that everybody will respect everybody else’s environments. A good analogy here is sharing a large house with friends. Everybody has a key to the same front door and the individual bedroom doors are usually left unlocked. There are some common areas and common equipment but there’s a reasonable expectation of privacy in one’s own bedroom.

Software as a Service (SaaS) may be compared to staying in a hotel. For the price of your room you delegate all maintenance and security to the hotel management and within reason expect them to respect the sovereignty of the contents of your room even though they have access more or less at any time. (Perhaps in this case we’d use the in-room safe to secure anything sensitive from the housekeepers.) Everyone understands that there are other guests in the hotel and there is a well-founded expectation that no guest from another room with have access to yours.

It is with these considerations in mind that we designed a configurable isolation model for Multitenant. 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.