Jak skonfigurować Oracle Listener bez SID_LIST_LISTENER w listener.ora?

Mam dostęp do serwera ORACLE 11g przy użyciu następującego listener.ora

# listener.ora Network Configuration File: D:\app\Administrator\product\11.1.0\db_1\NETWORK\ADMIN\listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.111.111)(PORT = 1521))
    )
  )

i obsługuje wszystkie instancje na tym serwerze, co mogę zweryfikować przez

lsnrctl status

Mój problem polega na tym, że kiedy wykonuję nową instalację Oracle 11g na maszynie wirtualnej, muszę użyć pliku listener.ora takiego jak

# listener.ora Network Configuration File: C:\app\oracle\product\11.2.0\dbhome_1\network\admin\listener.ora
# Generated by Oracle configuration tools.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = CLRExtProc)
      (ORACLE_HOME = C:\app\oracle\product\11.2.0\dbhome_1)
      (PROGRAM = extproc)
      (ENVS = "EXTPROC_DLLS=ONLY:C:\app\oracle\product\11.2.0\dbhome_1\bin\oraclr11.dll")
    )

   (SID_DESC =
     (GLOBAL_DBNAME = ORCL)
     (ORACLE_HOME = C:\app\oracle\product\11.2.0\dbhome_1)
     (SID_NAME = orcl)
    )

   (SID_DESC =
     (GLOBAL_DBNAME = BMBK)
     (ORACLE_HOME = C:\app\oracle\product\11.2.0\dbhome_1)
     (SID_NAME = BMBK)
    )

 )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 169.254.200.102)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    )
  )

ADR_BASE_LISTENER = C:\app\oracle

Bez wpisu SID_LIST_LISTENER, tj. Za pomocą listener.ora takiego jak z innego serwera otrzymuję

C:\Windows\system32>lsnrctl status

LSNRCTL for 64-bit Windows: Version 11.2.0.1.0 - Production on 27-NOV-2011 10:14
:24

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Anmeldung bei (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
STATUS des LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for 64-bit Windows: Version 11.2.0.1.0 - Produ
ction
Startdatum                27-NOV-2011 10:14:08
Uptime                    0 Tage 0 Std. 0 Min. 18 Sek.
Trace-Ebene               off
Sicherheit                ON: Local OS Authentication
SNMP                      OFF
Parameterdatei des Listener C:\app\oracle\product\11.2.0\dbhome_1\network\admin\
listener.ora
Log-Datei des Listener    c:\app\oracle\diag\tnslsnr\WSV-BK-W7en64-S\listener\al
ert\log.xml
Zusammenfassung Listening-Endpunkte...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1521ipc)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=169.254.200.102)(PORT=1521)))
Der Listener unterst³tzt keine Services
Der Befehl wurde erfolgreich ausgef³hrt.

Ostatnia wiadomość jest tłumaczona na

Odbiornik nie obsługuje żadnych usług.

Nie mam pojęcia, dlaczego te dwa serwery zachowują się inaczej. Nie znalazłem żadnych wskazówek w plikach konfiguracyjnych ani w kluczach rejestru.

Edytować:

Myślę, że odpowiedź jest gdzieś zakopana w tym poście przez Burleson Consulting , ale nie znajduję miejsca, w którym jest ona właściwie skonfigurowana.

Trochę za późno na imprezę w tej sprawie ...

Baza danych powinna zarejestrować się automatycznie ze słuchaczem, dzięki czemu SID_LISTwpisy będą zbędne, i wydaje się, że dzieje się tak w twoim 192.168.111.111środowisku. Jeśli detektor zostanie uruchomiony po bazie danych, rejestracja może trochę potrwać, a mogą wystąpić sytuacje, w których w ogóle tego nie robi.

Możesz spróbować zarejestrować go za pomocą alter system registerpolecenia. Baza danych używa LOCAL_LISTENERparametru do identyfikacji nasłuchiwania, w którym powinna się zarejestrować. Domyślnie jest to null, co zgodnie z dokumentacją jest równoważne hostname:1521.

Jeśli alter system registerusługa nie pojawi się w danych lsnrctl statuswyjściowych, podejrzewam, że nie jest w stanie ani zidentyfikować nazwy hosta, ani rozwiązać go, lub jest przetwarzany na inny adres niż ten, na którym nasłuchiwanie jest włączone, lub LOCAL_LISTENERjest ustawiony na coś nieprawidłowego dla wirtualne pudełko. Możesz ustawić LOCAL_LISTENERdopasowanie listener.orabezpośrednio do, np .:

alter system set LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))' scope=both;
alter system register;

Lub możesz użyć aliasu, który zawiera te dane w twoim tnsnames.ora. Na przykład, jeśli dodasz tnsnames.orawpis, taki jak:

MY_LISTENER =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
  )

Następnie możesz:

alter system set local_listener='MY_LISTENER' scope=both;
alter system register;

Jedyną prawdziwą zaletą tej tnsnames.orawersji, oprócz zwięzłości, jest to, że możesz zmienić konfigurację w plikach SQL * Net zamiast w bazie danych; i nawet to naprawdę wydaje się przydatne tylko wtedy, gdy klonujesz bazy danych między komputerami, lub jeśli słuchacze i bazy danych działają na różnych kontach (np. z gridużytkownikiem RAC / HA).

Jest więcej na LOCAL_LISTENER tutaj .

Edycja: I wydaje się to dość kompleksowe.

Miałem podobny problem i stwierdziłem, że zamknięcie i ponowne uruchomienie instancji spowodowało, że rejestracja przebiegła poprawnie.

Można to zrobić za pomocą wiersza polecenia sqlplus. Musisz zalogować się jako użytkownik za pomocą składni przywilejów SYSDBA (np. Systemowych):

sqlplus name/pass as SYSDBA

następnie uruchom „zamknij” i poczekaj na zakończenie. następnie uruchom „startup” i poczekaj na zakończenie.

trzymajcie kciuki, powinieneś teraz zarejestrować instancję u słuchacza.

Aby sprawdzić, czy tak jest, możesz uruchomić lsnrctl i uruchomić polecenie „status”. jeśli to nie zadziała, nadal zobaczysz komunikat „Słuchacz nie obsługuje żadnych usług”, w przeciwnym razie zobaczysz coś takiego

Service "horse" has 1 instance(s).
 Instance "horse", status READY, has 1 handler(s) for this service...