| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: startup nomount
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 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
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 Wed Mar 05 2003 - 15:39:00 CST
 |
 |