Re: startup nomount

First of all, I would re-evaluate Oracle as the best choice for this project... You are trying to automate the install and make it painless for your customers, which is fine... But Oracle is not maintenance-free, and you might be giving your customers a huge headache.

For example, you are having your customer install Oracle, possibly they know nothing about Oracle. You are having them create a default database and then inserting your own stuff in there. Already there are several potential problems:

1. Who sized the database? The default DB is really a bad thing in Oracle, as it is almost never the best DB you could create for a given situation... I have never been happy with the default DB, that's why the rule of thumb is to create scripts with the DBCA tool, and then hand-modify those scripts to fit how the DB is going to be used.
2. There is probably no DBA on-site... This means trouble up ahead. Who is going to maintain the DB periodically?
3. Have you looked at the license implications? Oracle's not cheap...

These are a few things that quickly come to mind.

From what you said so far, I think Oracle is one of the worst DB you could use for this: If the volume requires Oracle, then your client should have a DBA on site who should create the DB. If the volume is too low and there is no DBA, then you shoudl certianly use another database for this.

I'm sure I don't have the full picture, but there's something wrong here...

Some other points:

> I planed on creating a database with my own specs first, mounting it then
> doing an import. (Plan not proven)

To do an import the DB should fully up and running. You do not need to "startup nomount". "startup" alone should be fine.

> Our initial script asks for the user to insert their Oracle Install CD and
> Install Oracle.
> Then I want to replace the default oracle DB with ours.

If you REALLY want to go this route, I remember you can create "response files" for the installer. You can automate the installation of Oracle without the need for user interaction. You could have the installer install Oracle without creating a DB. Afterwards you run your custom create DB scripts, no need to have a default DB created.

>The original plan
> was to use DBartisan to create scripts. I thought we could just use
> Export/Import utilities in a script.

1. You should really use the Oracle DBCA (DB Config Assistant) to create the scripts. It's easy enough to do, and you'll have less trouble.
2. Yes, after DB creation you create the users to hold the schemas, then do import to recreate the objects.

> I inherited this project so thing are a but fuzzy, especially since I'm
new
> to Oracle dba requirements. I've been developing in MSSQL the porting all
> of the triggers and SP to Oracle. My company thinks it is a short step to
> Oracle DBA chores. NOT

Your company's attitude might be what kills this for you... Be careful.

One last thing: Be very mindful of Oracle versions. An export done (for example) from Oracle 8.1 may not be imprtable into 8.0, buit will be imprtable into 9.0 for example. Likewise, running the 8.1 exp utility against a 8.0 database will not work without tweaking, so for an easier life, make sure the exp/imp utils match the target database version. If you are going to support doing this in multiple Oracle versions then you really have a nightmare in your hands... For example if you have to distribute DB creation scripts that have to work with all versions of Oracle out there...ouch! Received on Wed Mar 05 2003 - 10:05:45 CST