Re: [Gusdev-gusdev] more help with installation please]

[Angel P. <an...@pc...>]

forgot to forward my reply to the list
angel
-------- Original Message --------
Subject: 	Re: [Gusdev-gusdev] more help with installation please
Date: 	Tue, 06 Jan 2004 10:17:40 -0500
From: 	Angel Pizarro <an...@pc...>
To: 	Matthew Hobbs <mat...@ve...>
References: 	<200...@ve...> 
<3FF...@pc...> 
<200...@ve...>



Matthew Hobbs wrote:

>Thanks Angel and Steve for your replies to my previous message.  
>
>I am however still struggling with this installation!  I am still getting 
>errors when running create-db.sh.  Angel advises me to 'use the schema.prop 
>file for setting appropriate logins and tablespace usage' but I don't 
>understand how schema.prop and create-db.sh could  interact.  schema.prop is 
>referrred to in GUS/build.xml and is used by ant in the build - but this is 
>not where I am having my problem.  As explained in installguide.html the 
>build must be run three times.  Between build 2 and build 3 the createdb.sh 
>script is run.  How is create-db.sh supposed to read any of the information 
>in schema.prop?  
>  
>
schmea.prop does indeed get read by the build process, and not by 
create-db.sh
The build process should read schema.prop and do macro replacements on 
all of the SQL files that create a GUS instance.

For example, the "@oracle_rad@" macro should have been replaced by the 
value in schema.prop for oracle_rad, but I just checked and there is not 
one there. There is a "oracle_rad3=RAD3", so this is my mistake as a 
result of dumping GUS 3.1 and trying to get rid of a historic version 
number from the RAD schema's name. So when you are runnning the $GUSHOME 
SQL files, that particular macro was (erroneously) not replaced. Sorry 
about that. The simple thing to do is to replace "rad3" with "rad" in 
the schema.prop file wherever you find it. Including the uppercase. (I 
just did so in my local copy and will commit it to CVS shortly)

>Having created some more tablespaces (answering my own previous question) the 
>first error reported by create-db.sh is now:
>
>
>SQL> DROP USER @oracle_rad@ CASCADE;
>DROP USER @oracle_rad@ CASCADE
>          *
>ERROR at line 1:
>ORA-01935: missing user or role name 
>
>
>This is the first place in the input sql file that '@' notation is 
>encountered.  I guess @oracle_rad@ is a variable but SQL*Plus doesn't know 
>its value.  Is the value is supposed to be read from schema.prop (a wild 
>guess but schema.prop does seem to have assignemnts of values to similar 
>names like 'oracle_rad3')???
>
Again yes, the the @some_variable@ macros are substituted in the 
build/install process with values from the schema.prop. So at least now 
you know where "tablespace1" came from ;) AND you should replace such 
minor strings "password*"  for the login to something a bit more secure.

You can now also customize the oracle tablespaces as you like for your 
particular installation. If this is just a test, I would use two 
tablespaces, one for indexes and the other for data. If not a test and 
you are limited in space, then I would separate the tablespaces as 
follows [DoTS], [RAD], [TESS,SRes,Core,App], [Indexes_DoTS], 
[Indexes_rest]. Otherwise, separate tablespaces for schema space and 
index space is best, but better names are recommended for easier admin 
(rad_data_tablespace, rad_index_tablspace, etc. )

Angel

>Again I would be grateful for help.
>
>
>Thanks,
>
>
>Matthew
>
>
>
>
>  
>