OMF and account separation are mutually exclusive

10g R1 win32 (10.1.0.4 <http://10.1.0.4> patch 5).

A request comes in for a smallish dev database with a unicode db charset. Outside consultants are going to be allowed to hit it, most likely with privileged accounts.
They will apparently be permitted to create java packages.

I create a new local OS group and local OS user account to support this database
(think of this as creating a sandbox on a beach, whereby one drove 4 two-by-fours into the sand).

For convenience, I went ahead and enabled the OMF parameters so that if they need to create app-specific tablespaces when a dba isn't available ... they could do it themselves, within their own sandbox(es) of the server filesystems.

D:\oracle\product\10.1.0\db_1\bin> sqlplus /nolog SQL> connect / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01261: Parameter db_create_file_dest destination string cannot be translate

ORA-01263: Name given for file destination directory is invalid
OSD-04018: Unable to access the specified directory or device.
O/S-Error: (OS 5) Access is denied.

SQL> startup pfile='D:\Oracle\Admin\mydb\pfile\initmydb.ora' ORA-01261: Parameter db_recovery_file_dest destination string cannot be translated

ORA-01263: Name given for file destination directory is invalid
OSD-04018: Unable to access the specified directory or device.
O/S-Error: (OS 5) Access is denied.

SQL> startup pfile='D:\Oracle\Admin\mydb\pfile\initmydb.ora' ORACLE instance started.

Total System Global Area 612368384 bytes Fixed Size 790432 bytes
Variable Size 170127456 bytes
Database Buffers 440401920 bytes
Redo Buffers 1048576 bytes
Database mounted.
Database opened.
SQL> These were the parameters that had to be commented out in order to startup:

#db_recovery_file_dest=S:\oracle\flash_recovery_area
#db_recovery_file_dest_size=8589934592
#db_create_file_dest='I:\Oracle\Oradata'
#db_create_online_log_dest_1='E:\Oracle\Oradata'
#db_create_online_log_dest_2='F:\Oracle\Oradata'

In order for these parameters to be enabled, the oracle process needs to have write access at the directory level ABOVE the database specific files, even though the folders exist and the service account has "full control" of that level.

That completely circumvents account separation/privilege separation.

OMF - I guess its an option provided that the one true OS account, with one true OS dba group can rule them all.
(99% of the time, "LocalSystem").
I do not trust a database instance to not overwrite another database instance's files.
If it can, it will. Eventually.
Once again, I set that type of functionality aside as useful for the boss's laptop.
Not on a database server.

Paul

--
http://www.freelists.org/webpage/oracle-l