Sent via Deja.com http://www.deja.com/
Before you buy.
02-APR-00 21:27:03 * (CONNECT_DATA=(SID=v8i815)(CID=(PROGRAM=C:\Program
Files\toad\Toad.exe)(HOST=KKINDER)(USER=kkinde
r))) * (ADDRESS=(PROTOCOL=tcp)(HOST=199.239.69.152)(PORT=3261)) *
establish * v8i815 * 0
Seems normal enough.
In article <8c8oam$coq$1...@nnrp1.deja.com>,
--
Ken Kinder
Is the ORALCE_HOME path correct in the listener.ora file?
Best to do I think is used the sample listener.ora file and use that as the
basis for configuring your listener.
Billy
In article <8c9dul$p6e$1...@ctb-nnrp1.saix.net>,
Luke
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Ken Kinder wrote:
> For some reason, when I connect over TCP/IP listeners, I am getting
> ORA-01034: ORACLE not available
> This happened after a reboot. I used dbstart to restart the database and
> restarted the listener as well. I can connect using sqlplus directly on
> the server, and run queries, so I know the database is OK. The problem
> is then certainly in the listener.
> Yes, the SID is set correctly.
> Can anyone give me some direction here?
> (oracle8i/RH Linux)
> For some reason, when I connect over TCP/IP listeners, I am getting
> ORA-01034: ORACLE not available
> This happened after a reboot. I used dbstart to restart the database and
> restarted the listener as well. I can connect using sqlplus directly on
> the server, and run queries, so I know the database is OK. The problem
> is then certainly in the listener.
> Yes, the SID is set correctly.
> Can anyone give me some direction here?
> (oracle8i/RH Linux)
When making a connection to a database, a server process is started
that accesses a shared memory segment.
To create and to find this shared segment, the database uses the
ORACLE_HOME and the ORACLE_SID.
Now, if ORACLE_HOME or your ORACLE_SID is slightly different in the
environment in which you started up the database, and the setting in
the listener.ora, you will typical get the ORA-1034.
Check for a trailing / in the ORACLE_HOME or a symbolic link for the
ORACLE_HOME.
Something else to check : Oracle8i uses a service name to identify to
which database you want to connect (when connecting through
Net8). Check if service_name in the listener.ora is the same as
service_name in the init.ora.
Or use the old syntax with the SID.
--
The fundamental aim of King Crimson is to organize anarchy, to utilize
the latent power of chaos and to allow the varying influences to
interact and find their own equilibrium.
-Robert Fripp
I would assume that the tnsnames.ora wouldn't be the problem, as
everything worked fine before an unexpected powerloss.
In article <1852fb60...@usw-ex0102-013.remarq.com>,
[oracle8i@snoopy oracle8i]$ lsnrctl status
LSNRCTL for Linux: Version 8.1.5.0.0 - Production on 03-APR-00 13:23:52
(c) Copyright 1998 Oracle Corporation. All rights reserved.
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=snoopy.corp.messagemedia.com)(
PORT=1521))(PROTOCOL_STACK=(PRESENTATION=TTC)(SESSION=NS)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 8.1.5.0.0 -
Production
Start Date 02-APR-00 15:09:02
Uptime 0 days 22 hr. 14 min. 50 sec
Trace Level off
Security OFF
SNMP OFF
Listener Parameter File
/usr/local/oracle/8i/u01/app/oracle/product/8.1.5/network/admin/listener
.ora
Listener Log File
/usr/local/oracle/8i/u01/app/oracle/product/8.1.5/network/log/listener.l
og
Services Summary...
v8i815 has 3 service handler(s)
v8i815 has 1 service handler(s)
The command completed successfully
Seems fine...
I can ping the server. Infact, trying to connect through TCP/IP loopback
with SQL*Plus gives me the same message:
sqlplus user/pass@host
on the database server returns oracle not availible.
I also assume that it couldn't be the tnsnames configuration, as it
worked fine before a nasty powerloss/reboot.
In article <38E88C6F...@dplus.net>,
Em Pradhan <empr...@dplus.net> wrote:
> Hi
> Listener is running or not. Hopefully yes but again
> check the services whether it is running or not.
> Also are you able to ping your server address.
> On the server at which port listener is listening.
> Is your tnsnames.ora compatible with listener.ora
> on the server side.
> Good luck
> HTH
> Pradhan
>
> Ken Kinder wrote:
>
> > For some reason, when I connect over TCP/IP listeners, I am getting
> > ORA-01034: ORACLE not available
> > This happened after a reboot. I used dbstart to restart the database
and
> > restarted the listener as well. I can connect using sqlplus directly
on
> > the server, and run queries, so I know the database is OK. The
problem
> > is then certainly in the listener.
> > Yes, the SID is set correctly.
> > Can anyone give me some direction here?
> > (oracle8i/RH Linux)
I can use sqlplus locally using an IPC listener, and run quieries fine.
When I try adding the user/pass@service part, it gives me ORA-01033:
ORACLE initialization or shutdown in progress
This message is also returned from clients on other machines trying to
connect to the database.
If this helps shed some light on why this is happenning, I would
appreciate anyone's suggestions. I know the database is running nicely,
as I can run queries on non-TCP connections.
Thanks BTW.
In article <8c8mpn$b6m$1...@nnrp1.deja.com>,
Have you bounced the database since your restarted it after the
power loss? The ORA-1033 leads me to suspect that Oracle did not
come up cleanly, yeah I know it really should be okay, but when
you get a power loss funny things can happen -- and the message
changing from ORA-1034 to ORA-1033 is suspicious.
--
Jerry Gitomer
Once I learned how to spell DBA, I became one
>Thing is, it seemed to be configured fine before the system lost power
>and rebooted.
In that case, check the IP configuration of the Unix box. Maybe the
resolv.conf file is incorrect, causing the listener to timeout connections
because it can not resolve an ip address to a hostname.
Or maybe there's some firewall software being enabled?
Best is to make sure that you have a standard vanilla flavoured ip protocol
stack configuration and then take things from there.
regards,
Billy
2) Daft idea (probably doesn't merit mention but for completeness here
goes) - start your listener first then run svrmgrl and startup the
database.
To check that your tnsnames.ora file is being read properly by the
listener, try
SVRMGR> CONNECT SYS@<service name> AS SYSDBA
and if you get asked for your password, then the listener has
successfully read the tnsnames.ora file. If not, you might have a
problem with tnsnames on the server (as above).
(You can always just SVRMGR>CONNECT SYS and the default Bequeath (IPC)
protocol should be used.)
Now SVRMGR>STARTUP OPEN etc. etc.
This should then bring the server up, after the listener.
David P.
Oracle Certified DBA
=====================================================================
Ken Kinder wrote:
>
> I tried it on two machines.
>
> I would assume that the tnsnames.ora wouldn't be the problem, as
> everything worked fine before an unexpected powerloss.
>
> In article <1852fb60...@usw-ex0102-013.remarq.com>,
> luke.davies <luke.davi...@centers.co.uk.invalid> wrote:
> > Have you checked your tnsnames.ora file to see if the values are
> > correct?
> >
> > Luke
> >
> > * Sent from RemarQ http://www.remarq.com The Internet's Discussion
> Network *
> > The fastest and easiest way to search and participate in Usenet -
> Free!
> >
> >
I agree. Any time a database is the subject of a power loss I always
shutdown the instance immediate and start it up again, to make certain
that everything is running smoothly. I have experienced a number of
complications because an instance did not start cleanly, even hanging
on a local SQL*Plus connection; after a shutdown and startup the
database connections worked without incident. Shut the instance down,
and start it up again.
Something tells me it's in the listener, as IPC SQL*Plus seems to work
though...
In article <8cdfcn$j0e$1...@nnrp1.deja.com>,
ORA-01102: cannot mount database in EXCLUSIVE mode
which was after this:
Total System Global Area 71998864 bytes
Fixed Size 64912 bytes
Variable Size 54984704 bytes
Database Buffers 16777216 bytes
Redo Buffers 172032 bytes
In article <38EA36...@btinternet.com>,
The error you're getting is because Oracle thinks you want to create
another instance (a set of shared memory and proceeses) to access the
very same datafiles. It knows the first instance was opened with the
instruction that no other instances should be able to connect to it. The
default startup parameter is EXCLUSIVE (as opposed to SHARED). Thus the
conflict.
Getting back to the original problem, can you connect to the instance
using TCP/IP ?
David P.
Oracle Certified DBA.
=====================================================================
ANALYZE TABLE <table_name> VALIDATE STRUCTURE CASCADE; or just
do a full export. Either will validate the existing tables. But
I don't think that is your problem. Rebuild both the listener
and the TNSnames file on the server. You should be able to find
copies of the originals on the system and edit them. (I don't
know if it is still so but in the good ol' days we had to be
careful to preserve the leading tabs or leading spaces WITHOUT
CHANGE when editing one or both of the above -- and you can't see
the difference with the naked eye.) If you are running Unix
check /etc/services to see if the ports are still assigned to
Oracle.
Sorry, but I am now out of ideas.
J.L.
Ken Kinder wrote:
>
> Upon restarting the database (I had to shut it down to start it up),
> what do you make of this:
>
> ORA-01102: cannot mount database in EXCLUSIVE mode
>
> which was after this:
>
> Total System Global Area 71998864 bytes
> Fixed Size 64912 bytes
> Variable Size 54984704 bytes
> Database Buffers 16777216 bytes
> Redo Buffers 172032 bytes
>
--
Jochen Lübbers lueb...@tele-data-electronic.de
Software Development Group I lueb...@tde-online.de
TDE - Tele Data Electronic GmbH s...@tde-online.de