SAN FRANCISCO -- SearchOracle recently had a chance to sit down with James Lui, Oracle applications database administrator at Philadelphia-based uniform and career apparel company Aramark. Lui talked about his company's testing of Oracle Database 12c and how its multi-tenancy feature -- formerly called Pluggable Databases -- is an improvement over the transportable tablespace feature in Oracle Database.
Can you tell me about Aramark's use of transportable tablespace?
James Lui: We've used transportable tables a lot. We have an Oracle partner that brings vertical software for our industry for managing laundry and uniform rentals. Their stack is consolidated into individual schemas. That normally provides a fast way to get to everything, but once we begin to augment or build BI [business intelligence] on top of it, you end up with a larger database impact because there are larger architectural things on top of it.
What metadata issues or concerns have you encountered with traditional ways of moving Oracle databases around?
Lui: We always thought that the only thing you had to clone was the data repository, but in the real world that doesn't work. Sometimes when you have metadata that has to replicate between instances, if you push it back into test/dev and debugging scenarios, we'll find that the metadata doesn't match. You can't just containerize the database by user ID. You need to conserve everything that goes with a particular table set.
We looked at Pluggables as a good solution. Let's say we have a major vendor that installs schemas. We augment that with third-party, in-house development. That creates a small capsule, and with Pluggables, it allows that capsule to be portable. Before you would have to do a rip and refresh. You'd have to install all security such as single sign-on and identity management. All that breaks when you just take a database and move it around.
How do Pluggable Databases and transportable tablespaces differ?
Lui: If you understand transportable tablespaces, they just moved that up to the database level. That was the flexibility we were looking at. If you have encrypted tables and you unplug and re-plug, it stays encrypted. Those are the kind of niceties you can't get with a standard import-export. You can't get that with transporting tablespaces.
For us there is also the soft cost savings in administration. You don't have to think about security and identity management if you just copied an entire database. That level of thinking can slow you down a lot.