Oracle-DB Listener geht ständig auf Block bei MSSQL-Prozedur

[Klaus]

Hallo,

ich hoffe, ich kann bei Euch Unterstützung finden (und ihr die Geduld habt, durch den längeren Text zu lesen), da ich selber nicht weiterkomme.

Auf einer recht alten Oracle-DB (8i) läuft ein Listener mit 3 Instanzen. Eine dieser Instanzen geht mit wachsender Begeisterung auf Block.
Ich hab früher dann immer händisch den Listener gestoppt und gestartet. Früher heißt noch vor ein paar Jahren, da es nur hin und wieder vorkam, also 5-6 Mal pro Jahr.
In der letzten Zeit (seit ein paar Monaten) ist das allerdings so häufig geworden, dass ich zunächst das Stoppen und Starten automatisiert hatte (Bash-Script über Crontab jede Minute aufgerufen, der den Status prüft und gegebenenfalls selber stoppt und startet).
Nun habe ich mir in einer Textdatei protokolliert, wann der Listener auf Block geht und festgestellt, dass er es immer nur in einem festen Zeitfenster stattfindet (zwischen 07 Uhr und 20 Uhr) und mittlerweile 70 Mal pro Tag.
Auf einem 2. physikalischen Server läuft eine alte MSSQL-DB, in der der Oracel-DB als Verbindungsserver eingetragen ist (ODBC-Verbindung).
Hier startet genau in diesem Zeitfenster zwischen 7 und 20 Uhr eine Stored Procedure.
Ich habe testweise diese nur zwischen 13 Uhr und 20 Uhr laufen lassen und festgestellt, dass das Listener-Problem jetzt nur noch in diesem Zeitfenster auftrat.
Hiermit dürfte die Stored Procedure als Ursache ausgemacht sein.

Weder am Oracle-Server oder am MSSQL-Server noch an den Proceduren wurde etwas geändert (Das letzte Mal vor 7 Jahren).
Die Prozedur ist recht einfach, wenn auch umfangreich aufgebaut. Es werden eine ganze Reihe von Tabellen abgefragt bzw. aktualisiert.

SQL-Fehler treten keine auf, die wären sonst in einer ErrorLog-Tabelle protokolliert worden.
In der Synclog-Tabelle fallen ein paar leere Einträge auf, aber nicht in der Häufigkeit wie der Listener auf Block geht.

Es hat eventuell indirekt oder direkt mit der zu aktualisierenden Datenmenge zu tun, denn das ist das Einzige, was ständig gewachsen ist.

Hat jemand eine Idee, wie ich verhindern kann, dass der Listener auf Block geht?

Ich habe den Trace-Level maximiert, aber weder im listener.log noch im listener.trc finde ich etwas.
Ich müsste eventuell den automatischen Neustart mal ausschalten, denn mit jedem Neustart wird die listener.trc wieder neu erstellt und der alte Inhalt verworfen.

Klaus

[hotti]

hi Klaus,

Weder am Oracle-Server oder am MSSQL-Server noch an den Proceduren wurde etwas geändert (Das letzte Mal vor 7 Jahren).

Ein Überlegung erster Ordnung sagt mir, dass Du das eigentliche Problem seit 7 Jahren mit Dir rumschleppst.

Die Prozedur ist recht einfach, wenn auch umfangreich aufgebaut. Es werden eine ganze Reihe von Tabellen abgefragt bzw. aktualisiert.

SQL-Fehler treten keine auf, die wären sonst in einer ErrorLog-Tabelle protokolliert worden.

Hab ich auch schon erlebt, dass der Listener stirbt ohne Auauaa zu sagen. Syntax ok, aber es waren einfach zuviele Daten mit Stringoperationen. Da gibts in Oracle eine Begrenzung. Schau Dir die Daten an, die da bewegt werden, meine Lösung (ist schon par Jahre her) bestand darin, die Daten auf mehrere Statements aufzuteilen, was zwar mehr Netzwerktraffic erzeugte aber auf Dauer funktionierte.

MfG

[Klaus]

Hi hotti,

Weder am Oracle-Server oder am MSSQL-Server noch an den Proceduren wurde etwas geändert (Das letzte Mal vor 7 Jahren).

Ein Überlegung erster Ordnung sagt mir, dass Du das eigentliche Problem seit 7 Jahren mit Dir rumschleppst.

Da liegst Du nicht falsch ;-)) Zu meiner Entschuldigung: Damals gab es noch einen internen DB-Admin, der sich bemühte. Nachdem dieser nicht mehr verfügbar war, ist das Problem geschoben worden. Weil es auch nur selten auftrat. Allerdings hätte man (ich) spätestens aktiv werden müssen, als man per crontab automatisch reagiert hat.

Hab ich auch schon erlebt, dass der Listener stirbt ohne Auauaa zu sagen. Syntax ok, aber es waren einfach zuviele Daten mit Stringoperationen. Da gibts in Oracle eine Begrenzung. Schau Dir die Daten an, die da bewegt werden, meine Lösung (ist schon par Jahre her) bestand darin, die Daten auf mehrere Statements aufzuteilen, was zwar mehr Netzwerktraffic erzeugte aber auf Dauer funktionierte.

Ich weiß nicht, wie ich eine der Update-Aufgaben auf mehrere Statements aufteilen könnte.
Hier exemplarisch ein Beispiel für eine Tabelle (von 36). Der Aufbau ist nahezu identisch bei allen.

  
	if (@tablename = 'T_AI_SPRACHE')  and exists (select 1 from oradoc..ORADOC.VIEW_T_AI_SPRACHE)  
	begin  
  
		select @updcount = 0,  
			 @inscount = 0,  
			 @actcount = 0,  
			 @error = 0  
  
		select @actcount = count(1)  
		from	oradoc..ORADOC.VIEW_T_AI_SPRACHE  
		where abs(lngSYNCID) > @syncid_mssql  
  
		update firma.myweb.T_AI_SPRACHE  
		set 	LNGSYNCID = s.LNGSYNCID,  
			LNGAUTOID = s.LNGAUTOID,  
			STRBESCHREIBUNG = s.STRBESCHREIBUNG,  
			INTREIHENFOLGE = s.INTREIHENFOLGE  
		from 	firma.myweb.T_AI_SPRACHE d join oradoc..ORADOC.VIEW_T_AI_SPRACHE s on d.INTAIID = s.INTAIID  
											and d.INTLANGID = s.INTLANGID  
		where   abs(s.lngSYNCID) between @syncid_mssql+1 and @syncid  
  
		select @error = @@error,  
			 @updcount = @@rowcount  
  
		If @error <> 0  
		Begin  
			Set @errortext = 'Fehler beim Update der Tabelle T_AI_SPRACHE'  
			exec firma.myoracle.sp_kut_import_error @p_error=@error, @p_errortext=@errortext  
		End  
		ELSE  
		BEGIN  
			set @updtext = @updtext + cast(@updcount as varchar(5)) + ' DS in T_AI_SPRACHE aktualisiert' + @crlf  
  
			insert into firma.myweb.T_AI_SPRACHE (  
				 INTAIID, LNGSYNCID, LNGAUTOID, INTLANGID, STRBESCHREIBUNG, INTREIHENFOLGE)  
			select INTAIID, LNGSYNCID, LNGAUTOID, INTLANGID, STRBESCHREIBUNG, INTREIHENFOLGE  
			from	 oradoc..ORADOC.VIEW_T_AI_SPRACHE s  
			where  not exists (select 1 from firma.myweb.T_AI_SPRACHE d where d.INTAIID = s.INTAIID  
										and d.INTLANGID = s.INTLANGID)  
  
			select @error = @@error,  
				 @inscount = @@rowcount  
  
			If @error <> 0  
			Begin  
				Set @errortext = 'Fehler bei Import der Tabelle T_AI_SPRACHE'  
				exec firma.myoracle.sp_kut_import_error @p_error=@error, @p_errortext=@errortext  
			End  
			ELSE  
			BEGIN  
  
				set @updtext = @updtext + cast(@inscount as varchar(5)) + ' DS in T_AI_SPRACHE eingefügt' + @crlf  
  
				if @updcount + @inscount = @actcount and @testflg = 0  
				begin  
					update oradoc..ORADOC.T_SYNCTABELLE set  
						syncid_mssql = @syncid,  
						aender_datum_mssql = getdate(),  
					      aender_bediener_mssql = user  
					where tabellenname = @tablename  
				end  
			end  
		END  
	end  

[hotti]

hi Klaus,

Weder am Oracle-Server oder am MSSQL-Server noch an den Proceduren wurde etwas geändert (Das letzte Mal vor 7 Jahren).

Ein Überlegung erster Ordnung sagt mir, dass Du das eigentliche Problem seit 7 Jahren mit Dir rumschleppst.

Da liegst Du nicht falsch ;-)) Zu meiner Entschuldigung: Damals gab es noch einen internen DB-Admin, der sich bemühte. Nachdem dieser nicht mehr verfügbar war,

Wenn jemand unersetzlich geworden ist, macht den sein unmittelbarer Vorgesetzter seinen Job nicht richtig...

ist das Problem geschoben worden.

... und wenn das so ist in diesem Fall: Wahrscheinlich die ganze Geschäftsleitung.

Schönen Abend.

[Klaus]

Guten Morgen hotti,

Wenn jemand unersetzlich geworden ist, macht den sein unmittelbarer Vorgesetzter seinen Job nicht richtig...

... und wenn das so ist in diesem Fall: Wahrscheinlich die ganze Geschäftsleitung.

Diese Antwort war unglaublich hilfreich und hat mir bei der Lösung des Problems erheblich weitergeholfen </ironie>