Re: startup nomount

CS wrote:

> Gabriel,
>
> You are 100 percent correct that Oracle is the wrong db for this project. I
> can't change that decision. What I did change was that it was ONLY for
> Oracle 8.17 running on NT 4. Period. Well maybe SQL2000 running on Server
> 2k. Already project creep VBG
>
> You are correct again that a DBA is required for on site setup. But that
> cost is prohibitive. I'm going to try and change that with my script.
>
> My initial batch file does the following:
> My scripts modify Init., Listener and the sqlnet. ora files and put them in
> the correct location with the Host and GlobalDatBaseName changes.. Then it
> starts the listener and runs tnsping to make sure we have made it thus far.
>
> Then it deletes the pwdMYDB.ora file and calls the oradim statement. Even
> if these services are running already, no fatal error.
> oradim -new -sid MYDB -startmode manual -pfile
> D:\ORACLE\ora81\database\initMYDB.ora -intpwd password
> I'm not sure if deleting the password file is causing me not to be able to
> log on as sysdba. I can login SYSTEM or SYS using the normal passwords but
> not as SYSDBA.
>
> After the Startup Nomount, I Create and size the DB. ( I think) I'm really
> not sure what the minimum requirements are to run the IMP. I got 3 rather
> large books on Oracle and none of them tell exactly what to expect/do using
> IMP/EXP utilities. They do say to login as INTERNAL/ORACLE as sysdba but
> that doesn't work either. They did say that internal was for older systems
> and change to sys.
>
> STARTUP NOMOUNT
>
> -- Create database
>
> CREATE DATABASE MYDB
> LOGFILE 'DRIVELETTER\oracle\oradata\MYDB\redo01.log' SIZE 51200K,
> 'DRIVELETTER\oracle\oradata\MYDB\redo02.log' SIZE 51200K,
> datafile 'DRIVELETTER\oracle\oradata\MYDB\system01.dbf' size 1024M REUSE
> AUTOEXTEND ON NEXT 10240K
> MAXLOGFILES 32
> MAXLOGMEMBERS 2
> MAXLOGHISTORY 1
> MAXDATAFILES 254
> MAXINSTANCES 1
> CHARACTER SET WE8ISO8859P1
> NATIONAL CHARACTER SET WE8ISO8859P1;
>
> CREATE ROLLBACK SEGMENT SYSROL TABLESPACE SYSTEM STORAGE (INITIAL 100K NEXT
> 100K);
> ...
>
> I could create an installation that created each object and user and then do
> the IMP for individual tablespaces, or use the script that dbArtisan
> created.. I thought it might be better to try and just do IMP
> fulldatabase.
> I think I have to run the CATxxx.sql scripts first. so I have to add them
> somewhere also.
>
> Thanks.for the time people, Oracle has me on my knees.
> BTW I'm an expert(haha) running crystal reports on oracle using store
> procedures. I can really make it sing now,(I've been on my knees here
> also).
> BTW2 What is the user/password as sysdba. connection string?? I think that
> was my initial question
> Thank You,
> CS
>
> "Gabriel Gonzalez" <no-spam_at_no-spam.com> wrote in message
> news:U_OcnesC_agBg_ujXTWckg_at_giganews.com...
> > 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!
> >
> >

Have you considered the possiblity that your clients might pay for the extra service of having a DBA fly in, install, and configure? I have several clients that sell software packages that do that with some of my senior students. If your database decision is based on installation and configuration, rather than solidly written requirements for performance, scalability, stability, and security ... you might want to reconsider a lot of aspects of what you are doing.

Daniel Morgan Received on Wed Mar 05 2003 - 17:51:35 CST