Conference varese::basestar_open

    
    Vinod, 
    
    which Oracle version are you using ?
    
    Please repeat the bstr_realm_setup_db step, then have a look at the
    
    	$ORACLE_HOME/rdbms/log/alert_BSTR.log
    
    file; near the bottom, you should find information about the problem
    happened, and possibly a pointer to a trace file, maybe:
    
    	$ORACLE_HOME/rdbms/log/pmon_<pid>.trc
    
    If those files won't give you the key of the problem, feel free
    to either post them here or mail them to me. We'll try to find out
    some Oracle guru.
    
    - Beppe -
    
    

        The oracle version is 7.1.6 .


        I done what you suggested without any success. The following log file
        $ORACLE_HOME/rdbms/log/alert_BSTR.log had now related messages in at
        all. I fact this file has not been updated since November last year.

        I also searched for any pmon*.trc files but again the last one updated
        was December last year.

        From the above you can see that the environment at this site has been
        very static since November, Hence, they did not need to use the
        Permanent database until now.

        The other thing which is slightly confusing is that the ora* processes
        all contain the realm name (PDAS). I expected then to be prefixed with
        BSTR.

        ie.

        ora_dbwr_PDAS  instead of       ora_dbwr_BSTR
        ora_smon_PDAS  instead of       ora_smon_BSTR
        ora_lgwr_PDAS  instead of       ora_lgwr_BSTR
        ora_pmon_PDAS  instead of       ora_pmon_BSTR


        The other option I have is to unset the BASEstar node altogether.
        This will destroy the Master database config, as well as the realm
        database config, allowing us to start clean.


        What do you recommend.



	Thanks
		Vinod.

    
    Vinod,

    >> very static since November, Hence, they did not need to use the
    >> Permanent database until now.

    	but something *must* have been changed in the meantime: what ?

    >> I expected then to be prefixed with BSTR.

    	It depends on what DB_Identifier has been choosen at
    	bstr_node_setup time: BSTR is the default, but you can choose
    	any other name. However, what has been specified at bstr_node_setup
    	is recorded into the 
    
    		$BSTR_ETC/db_parameters.h_<hostname>
    
    	file, at the 
    
    		DB.DB_Identifier:
    
    	keyword.
    
    
    >> This will destroy the Master database config, as well as the realm
    >> database config, allowing us to start clean.
    
    	I agree, but I would also add an Oracle shutdown / restart
    	in between:
    
    	1. bstr_node_shut -h
    	2. bstr_node_unset
    	3. shutdown Oracle
    	4. startup Oracle
    	5. bstr_node_setup
    	6. bstr_node_start
    	7. bstr_realm_setup_node PDAS
    	8. bstr_realm_setup_db PDAS
    	
    	
    - Beppe -
    

	Beppe,


        >> but something *must* have been changed in the meantime: what ?

                Good question, no one seems to know.


        >> It depends on what DB_Identifier has been choosen at
        >> bstr_node_setup time: BSTR is the default, but you can choose
        >> any other name. However, what has been specified at bstr_node_setup
        >> is recorded into the
        >>
        >>      $BSTR_ETC/db_parameters.h_<hostname>


                I'm sure the default was used at bstr_node_setup and looking
                in the above file, seems to verify this.

                ie.

grcps3> cat $BSTR_ETC/db_parameters.h_grcps3

        DB.DBMS_Type: ORACLE
        DB.DBA_Username: oracle
        DB.DB_Identifier: BSTR
        DB.Initial_DB_Datafile_Path: /usr/opt/pdas/basestar/work/node/cnf
        DB.Initial_DB_RedoLog1_Path: /usr/opt/pdas/basestar/work/node/cnf
        DB.Initial_DB_RedoLog2_Path: /usr/opt/pdas/basestar/work/node/cnf
        DB.Initial_DB_Tables_Path: /usr/opt/pdas/basestar/work/node/cnf
        DB.Initial_DB_Indexes_Path: /usr/opt/pdas/basestar/work/node/cnf
        DB.Initial_DB_Rollseg_Path: /usr/opt/pdas/basestar/work/node/cnf
        DB.Initial_DB_Tempseg_Path: /usr/opt/pdas/basestar/work/node/cnf




        If there is nothing else you can think of, I'll schedule some down
	time later on this week to unset the BASEstar node altogether and       
        recreate it.


        Thanks
                Vinod.

    
    Vinod,
    
    >> I'm sure the default was used at bstr_node_setup and looking
    >> in the above file, seems to verify this.
    >>    DB.DB_Identifier: BSTR
    
    	Hmmm ... in this case the bunch of oracle process should contain
    	`BSTR`, not `PDAS`, in their names.
    
    	I can't figure out how this situation could have been generated,
    	but the normal situation is that the *same* ORACLE_SID (either 
    	BSTR or PDAS or whatever) must be found in:
    
    	1 - the $BSTR_ETC/db_parameters.h_<hostname> file, i.e.
    
    	      DB.DB_Identifier: BSTR
    
    	2 - one of the oracle database initialization files' name, i.e.
    
    	      $ORACLE_HOME/dbs/initBSTR.ora
    
    	3 - the oracle processes' names, i.e.
    
    	      ora_smon_BSTR
    	      ora_pmon_BSTR
              ora_lgwr_BSTR
              ora_dbwr_BSTR
    
    
    - Beppe -

        Hi Beppe,

        I finally got everything working again, by unsetting the BASEstar node
        altogether and re-creating the whole config/environment.

        One other thing to note, I had to re-boot the machine after shutting
        down ORACLE. This was the only way I could create a new BASEstar
        database. Once the machine was rebooted I created the whole envirnoment
        from scratch without ant problems. The ORA process names were also back
        to being prefixed with BSTR rather than PDAS.

        Why ????

        Oh Well, Thanks for all the help.

	
	
	Vinod.