Canned Oracle (or Oracle Runtime Env)

Canned Oracle (or Oracle Runtime Env)

Post by Rick Denoi » Thu, 15 Jul 2004 06:55:34


We have customers who provide us with their data that we put in our
Oracle DB in a special application. When the application is customized
and all data delivered and loaded, the customer would like to actually
get the whole thing over to his site. But:
-we don't know the degree of DB expertize of the customer
-the customer assumes that he just needs to "start" the application
-the application should run without typical DB maintenance.
-license issues should be simplified for the customer

Is there a way to put an Oracle application into a "can" providing a
kind of Runtime Environment, that is, limited functionality in order
to allow the DB just to mount + open the database and "run".

So the Application would be a package containing datafiles, needed
binaries and documentation all together ready to install and run.
I think something similar exists for MS Access.

Alternatively, we would need to rewrite the application and use flat
files. That is like trying to reinvent the DB engine anew.

In some particular cases, the customer maintains itself Oracle
databases. We would need to deliver the database as such (that means,
the files). Is there any simplified method to mount a database from
CD-ROM, for example? (Would be opened readonly, of course).

Any ideas?

Bye
Rick Denoire
 
 
 

Canned Oracle (or Oracle Runtime Env)

Post by Daniel Mor » Thu, 15 Jul 2004 09:13:42


This has all the sounds and smells of a disaster waiting to happen.

I'd dump the custome if I couldn't talk sense into them. Sense would
start with your firm having remote access to their servers and a
contract that pays you to provide remote management.

Daniel Morgan

 
 
 

Canned Oracle (or Oracle Runtime Env)

Post by bdbaf » Thu, 15 Jul 2004 14:46:20

ick Denoire < XXXX@XXXXX.COM > wrote in message news:< XXXX@XXXXX.COM >...

assume that they have none.


publish an app so that it appears to be an app, nothing more.


if the database is read only, maintenance will be minimal.
you will still need to configure parameters related to

v$parameter:
global_name
service_names
db_domain

sqlnet.ora
names.default_domain

tnsnames.ora
tns_alias, service_name, host

listener.ora
host
(127.0.0.1 is not real effective in multi-user environments)


per CPU pricing under 10g standard edition is relatively simple.


yes, oracle has a packager, and you can use OUI to deploy your own
provided database that you have "jarred". you can use reponse files to
drive the install of the oracle server software + patchsets. response
files can chain to other response files. This is covered in the docs
for the Oracle Universal Installer. I've supplied response files to
client sites that when coupled with a batch file, covered deploying an
Oracle Client + config files, plus application runtime environment off
of a unc share.


aim for having everything OFA, with a known:

ORACLE_BASE\
ORACLE_ADMIN
ORACLE_HOME0

and a single db_file_create_dest
(although no new datafiles, logfiles will be created with a db open
read only)

If you must be flexible regarding datafile location, you might want to
use symbolic links from under the ORACLE_BASE to the real location.

I'm assuming that the read-only database will be NOARCHIVELOG
(attempt at a cheap laugh).

I would recommend that you dig up several docs by Thomas Cox:

- low administration oracle server (LAOS)
- dba checklist v1.5
- O'Reilly Oracle DBA Checklists

For a canned app that you know very well that is frozen, if you're
running a database in noarchivelog, its not that difficult to set it
up for minimal maintenance. Oversize the hardware. Schedule OS jobs to
create logical and physical backup sets on disk (compress afterwards)
and have the client site pickup the backup sets as part of their
network backups. for Bonus points (and revenue) have the backup jobs
send an email report of free space, success of backups, invalid
objects, errors from the alert log, etc. AND CHARGE FOR IT.

Also - consider partnering with a 3rd party provider of Remote DBA
Services.


expect advocates of PostGRES and MySQL to chime in here.
this might be an option that you should consider.


sure - but I've only heard of mounting datafiles for read only
tablespaces via CD-ROM, not an entire database.


interesting.
Perhaps DVD-ROM would be better, if a 700MB cd won't do.
I'd hate to have to add compression to the mix.

Do you intend to allow them to produce sorts, hash_joins, use global
temporary tablespaces?
If so, you're going to have to mount temp files.
This can be done with a database opened read only (e.g. standby
database opened read only for verification purposes).
I think that the controlfiles and system tablespace would have to be
read/write in order for the location of the tempfiles to be recorded.
You could ship temp files on the CDROM and locate them in a well known
location during install, turn them read/write and this would be a
non-issue.

but I still don't know about atempting to open an entire database read
only.

you're still going to need to groom files
- alert log (bdump)
- listener log(s)
- core dumps
- process crashes (udump)

and they might need t
 
 
 

Canned Oracle (or Oracle Runtime Env)

Post by Rick Denoi » Fri, 16 Jul 2004 06:52:02


Stimulating caveats.


Very, very interesting. I miss more keywords about the packager but I
will get along with this info. I knew about response files but nothing
about using the OUI to deploy a packaged ("jarred") application.


I actually meant mounting the DB, but of course, the really
enlightning idea is mounting (transportable) tablespaces.

Thanks a lot, you gave me some ideas to start with.

Bye
Rick Denoire.