SecureFiles in Action

Data stored inside SecureFiles can be accessed by both database clients and file system clients.

Database clients

SecureFiles is 100% backward compatible with LOB interfaces. Applications can transparently take advantage of SecureFiles using existing LOB interfaces. Supported clients include JDBC (Java thick and thin clients), ODBC, OCI, .NET, PL/SQL

For more information on how to build applications using SecureFiles and how to perform various associated database administrative tasks, please refer to refer to the SecureFiles and Large Object Developer's Guide.

File system clients

SecureFiles can be setup as a POSIX-compliant file system and data can be accessed through open data protocols such as WebDAV, HTTP and FTP. Oracle ContentDB's WebDAV servers can be used to access SecureFiles through Operating System interfaces. A WebDAV server can be natively mounted by Windows Explorer giving access to SecureFiles on Windows platforms. MacOS also supports WebDAV server mounting. SecureFiles can also be mounted on Linux using davfs File system. More information can be found in the SecureFiles and Large Object Developer's Guide.

Cadaver can also be used to get FTP-like access using WebDAV. Click here for more information.

Oracle products using SecureFiles as the underlying storage infrastructure include:

XML DB (Binary XML)
Oracle Multimedia
Oracle Spatial
Content DB

Migrating to SecureFiles

Securefiles is 100 percent backward compatible with BasicFiles (old LOBs) APIs. All existing applications that adhere to LOB interface can take advantage of SecureFiles without any application changes. Most applications will also see performance gains, with the use of Securefiles, without any code change. Securefiles is not a new SQL data type but a new storage type for storing unstructured data in LOBs.

Advanced features of SecureFiles such as Compression, Deduplication, Encryption can be turned on using DDL commands. These features only change properties of data as it resides on disk and are completely transparent to all applications. E.g. If Encryption is turned on a SecureFiles LOB, data is encrypted not only on disk but also on other images such as redo, backup etc . However when an application tries to read this SecureFiles LOB using existing LOB APIs, then data is transparently decrypted before passing it to the application.

Migration for existing installations

SecureFiles can be introduced and fully leveraged in an existing system with no schema or application change.

* Existing schemas can be partitioned and SecureFiles can be enabled only on new partitions while older partitions continue to use BasicFiles or older LOBs. This option does not involve any data migration. New data can start seeing advantages of using SecureFiles. Adding new SecureFiles partition will require a very small amount of downtime to change the dictionary. The down time is not related to size of data and is only a dictionary change.

* Online redefinition can be used to migrate BasicFile content to SecureFiles. Since this is an online operation it requires no downtime. This requires temporary extra space to accommodate new SecureFiles data while old data also exists. The extra disk space usage can be reduced by doing online redefinition one partition at a time. Smaller partitions reduce the amount of temporary extra space required.

A step-by-step example of migration from BasicFiles to SecureFiles can be found here.

Migration path for new installations

With no change to its interfaces or source code, a new installation of an application can take advantage of SecureFiles by specifying the 'db_securefiles=always' parameter to create all the LOBs as SecureFiles. For more on this parameter, refer to the SecureFiles and Large Object Developer's Guide.