Re: startup nomount

SQLPLUS "SYS/CHANGE_ON_INSTALL AS SYSDBA" ... Have you looked at response files for the installer ? ... oracle packages a basic database with the default install - and perhaps you might want to install at that point ...

Don't know much about them though....

"CS" <sheley_at_interaccess.com> wrote in message news:U7u9a.5686$fa.2470438_at_dca1-nnrp1.news.algx.net...
> 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!
> >
> >
>
>
Received on Thu Mar 06 2003 - 03:29:01 CST