Thursday Mar 29, 2012

ODA: Announcing ODA External Storage (read/write) Support

Effective immediately a customer can now use ODA with database files stored on an external NFS file server for both read and write operations.   This effectively eliminates ODA's 4TB storage capacity limit, which has been a concern with some of potential ODA customers.

Below is some additional information regarding the ODA external storage support

Q: What are we announcing?

A: Effective immediately, you can now use the Oracle Database Appliance with database files stored on a NFS-attached file server for both read and write operations.

Q: Does this differentiate the Oracle Database Appliance from an Oracle Database running on a 3rd-party server?

A: No, this feature is a generic feature of the Oracle Database. This puts Oracle Database Appliance on par with other Oracle Database server platforms.

Q: Is there an approved list of NFS servers I can use with the Oracle Database Appliance?

A: No, but we strongly recommend using a commercial file server such as an Oracle ZFS Storage Appliance, or a similar product from a major storage vendor (i.e., EMC, NetApp).

Q: Do I use ASM with the NFS-attached storage?

A: No. Simply mount the file system and store your files on it the same way you would store Oracle database files in any file system. Use of ASM for NFS-attached storage is not recommended.

Q: Can I have some of their database files on internal ODA storage, and some on NFS-attached storage?

A: Yes, you can have a mix of tablespaces—some on the local SAS storage internal to the ODA, and some on the NFS server.

Q: Can I create an ASM diskgroup that spans the local storage and the NFS storage?

A: No. ASM diskgroups should be constructed on disks internal to the ODA. ASM is not needed (nor recommended) for use on NFS-attached storage.

Q: If I don’t use ASM with my NFS Filer, how do I online add storage to my NFS-attached file system.

A: Most commercial NFS filers provide this functionality.

Q: Will I be required to patch their storage sub-system separately or will the ODA patching process take care of the NFS server?

A: The ODA patching process will only patch the local ODA server. If patches are required for an NFS filer, the customer is responsible for patching that themselves.

Q: If I put critical business data on an NFS filer and the server is down, what happens?

A: Your database is down. Make sure you use a highly available NFS filer.

Q: if I put non-critical archive data on an NFS filer, can I configure it so a failure to the filer won’t affect my database?

A: Yes, mark the archive data read-only, and set the init.ora parameter READ_ONLY_OPEN_DELAYED=TRUE

Q: What NIC in the ODA should I use to connect to NFS-attached storage?

A: The ODA has plenty of NICs. Use a bonded pair that is not in use.

Q: What mount options should I use?

A: rw,bg,hard,rsize=32768,wsize=32768,vers=3,nointr,timeo=600,tcp,actimeo=0*

Q: Where can I find more information?


Q: What is Direct NFS (dNFS)?

A: dNFS is a feature of the Oracle Database that allows an NFS client in the database kernel to directly connect to and access data on an NFS Filer.

Q: Should I used the native OS client or dNFS to connect to my NFS Filer?

A: You can use either, but Oracle recommends using dNFS.

Q: How do I configure and use dNFS?

A: Refer to MOS note 762374.1.

Q: How can I use Hybrid Columnar Compression (HCC) with ODA?

A: HCC is available for use with database files stored on and Oracle ZFS Storage Appliance. You can thus use HCC with ODA as long as the files are stored on and NFS-attached ZFS Storage Appliance. Your ODA must be running database (releasing in April 2012) and you must connect via dNFS.

Q: How should I distribute my data between the local storage and the NFS filer?

A: Put hot data on the internal storage, as that will give the best performance. Put colder data on the NFS filer.

Q: I have tables containing both hot and cold data. How can I move just the cold data to the filer without affecting the application which expects everything in one table?

A: Use the database partitioning option to keep data in different partitions. Place the hot data in partitions on the internal storage, and cold data in partitions on the NFS Filer.

Q: Is there a limit to the amount of data I can store on the NFS Filer?

A: Yes, it is limited by the maximum database size supported by the Oracle Database. This is very big.

Q: Is there a white paper on this subject I can read?

A: An ODA specific white paper will be available shortly. In the mean time, a dNFS white paper is available describing the generic functionality. You can find it here:

eSTEP: Virtualization@Oracle (Part 4: Oracle Solaris Zones and Linux Containers)

After the Oracle VM coverage in the previous two articles we will now cover the Operating System side by looking at the

Oracle Solaris Zones and Linux Containers

Oracle Solaris Zones or also Linux Containers are not a separate product, but a technology, a feature of an Operating System. Both technologies are in principle based on the same technologies. They are a virtualization at the application level, so “above” the OS kernel. Compared to the Hypervisor based virtualization, we do not have such an additional software layer here. We have one OS kernel that is shared by many zones or containers.

To put it into perspective, let’s reuse the image from the first articles, where we show the positioning of Oracle Solaris Zones, which can roughly be compared to Linux Containers. The difference between both technologies is more at the implementation level and on the way it is integrated into the OS.

Let’s first dive more into detail with the

Oracle Solaris Zones

This Solaris feature at first showed up in Solaris Express and Sun Solaris 10 3/05 as Solaris Containers, but has always been called Solaris Zones. With Oracle Solaris 11 we now officially call it Oracle Solaris Zones. Zones are a virtualization technology that create a virtualization layer for applications. We could say a zone is a “sandbox” that provides a playground for an application. Those zones are called non-global zones and are isolated from each other, but all share one global zone. The global zone holds the Solaris kernel, the device drivers and the devices, the memory management system, the filesystem and in many cases the network stack.

So the global zone sees all physical resources and provides common access to these resources to the non-global zones.

The non-global zones appear to applications like separate Solaris installations.

Zones have their own filesystems, their own process namespace, security boundaries, and own network addresses. Based on requirements, zones can also have their own network stack with separated network properties. And yes there also is a separated administrative login (root) for every non-global zone, but still even as a privileged user there is no way to break-out/in from one non-global zone into a neighborhood non-global zone. But looking from the global zone, such a non-global zone is just a bunch of processes grouped together by a tag, called zoneid.

This type of virtualization is often called lightweight virtualization, because we have nearly no overhead in which we have to invest for the virtualization layer and the applications, running in the non-global zones. Therefore we get native I/O-performance from the OS. Thus zones are a perfect choice, if many applications need to be virtualized and high performance is a requirement.

Due to the fact, that all non-global zones share one global zone, all zones run the same level of OS software – with one exception. Branded zones run non-native application environments. With that, for Oracle Solaris 10 we have the special case of being able to create Solaris 8 and Solaris 9 Legacy Containers, providing Solaris 8 and Solaris 9 runtime environments, but still sharing the Solaris 10 kernel in the global zone. With Oracle Solaris 11 it is possible to create Solaris 10 Zones.

Within Oracle Solaris 11, zones have been much more integrated with the OS, compared to zones in Solaris 10. It’s no longer just an additional feature of the OS. Zones are well integrated into the whole lifecycle management process of the OS when it comes to (automatic) installation or updates of zones. A big step forward is, once again, the better integration of zones with more kernel security features, which enables more delegated administration of Zones. Better integration into ZFS, consistent use of boot environments, network virtualization features and the Solaris resource management are additional improvements, made to the zones in Oracle Solaris 11. Oracle Solaris Zones have always been very easy to setup on the command line and easy to use. If you want to use a Graphical Tool to configure Zones, you can use Oracle Enterprise Manager OpsCenter (which we will cover later on in this series).

Now while we have discussed Oracle Solaris Zones, what are:

Linux Containers (LXC)

Is this the same technology like zones or if not, how do they differ ?

First of all, compared to Oracle Solaris Zones, it’s really a new technology in Linux starting with kernel 2.6.27 and provides the resource management through control groups (also called userspace process containers) and resource isolation through namespaces. The LXC project page at has a very good explanation of Linux Containers: “Linux Containers take a completely different approach than system virtualization technologies such as KVM and Xen, which started by booting separate virtual systems on emulated hardware and then attempted to lower their overhead via paravirtualization and related mechanisms. Instead of retrofitting efficiency onto full isolation, LXC started out with an efficient mechanism (existing Linux process management) and added isolation, resulting in a system virtualization mechanism as scalable and portable as chroot, capable of simultaneously supporting thousands of emulated systems on a single server while also providing lightweight virtualization options to routers and smart phones.”

So we are talking here about chroot-environments, that can be created on various isolation levels, but also share as isolated group of processes one Linux kernel.


Oracle Solaris Zones and Linux Containers are offering a lightweight virtualized runtime environment for applications. Solaris Zones exist since Solaris 10 and are now highly integrated into Oracle Solaris 11. Linux Containers are available as BETA for Oracle Linux with the Unbreakable Enterprise Kernel only for testing and demonstration purposes.

With that we'd like to close this article on Oracle Solaris Zones and Linux Containers and hope we've kept you eager to read the ones coming in the following newsletters.

Further Reading

This series already had the following articles:

  • December 2011: Introduction to Virtualization (Matthias Pfützner)
  • January 2012: Oracle VM Server for SPARC (Matthias Pfützner)
  • February 2012: Oracle VM Server for x86 (Matthias Pfützner)

The series will continue as follows (tentative):

  • April 2012: Resource Management as Enabling Technology for Virtualization
    (Detlef Drewanz)
  • May 2012: Network Virtualization (Detlef Drewanz)
  • June 2012: Oracle VM VirtualBox (Detlef Drewanz)
  • July 2012: Oracle Virtual Desktop Infrastructure (VDI) (Matthias Pfützner)
  • August 2012: OpsCenter as Management Tool for Virtualization (Matthias Pfützner)

If you have questions, feel free to contact me at: Detlef Drewanz

Read more:

<<< Part 3: Oracle VM Server for x86 >>>> Part 5: Resource Management as Enabling Technology for Virtualization


eSTEP LogoeSTEP is an integrated program for our partner, focusing at the technical community to provide them with relevant technical information for their day-to-day business with us


« March 2012 »