2012-08-17 9 views
5

mam nadzieję, że ktoś może mi pomóc tutaj.Tridion CMS & Oracle: ORA-01000: maksymalnie otwarte kursory przekroczone

Używamy Tridon CMS do zarządzania swoją stronę WWW hostowane na JBoss i Apache.

Używamy SDL Tridion 5.3 przez 5 lat i nagle mamy napotkał błąd z bazą danych Oracle za nim. Większość naszych treści jest obsługiwana jako normalne strony jsp z systemu plików, ale mamy pewne składniki, które są obsługiwane przez wywołanie interfejsu API języka Tridion, które zwraca fragment HTML z bazy danych Oracle.
Niedawno zauważyliśmy, że niektóre z tych fragmentów HTML nie były wyświetlane, a podczas przeglądania plików dziennika serwera stwierdziliśmy, że wygenerowany został błąd Oracle ORA-01000: maksymalna liczba otwartych kursorów przekroczyła.
Nasze maksymalne kursory ustawiono na 300, więc zwiększyliśmy je do 350, aby zobaczyć, czy pomógł, ale nie.
Monitorując aktywne sesje Oracle, mogliśmy zauważyć, że liczba sesji osiągnęła maksymalną liczbę kursorów, więc zrestartowaliśmy serwer aplikacji. To wydawało się pomocne, ale tylko tymczasowo. Liczba sesji osiągających próg maks. Kursorów stopniowo wzrasta. Wczoraj po południu, wkrótce po ponownym uruchomieniu było około 30 sesji z max kursorami, dziś rano jest 150.

Oczywiście coś się ostatnio zmieniło, aby to spowodować, ale nie jesteśmy pewni co. Baza danych Oracle nie jest czymś, do czego zwykle mamy dostęp, a na pewno nie jest to coś, do czego wprowadzamy zmiany bezpośrednio - wszystkie codzienne operacje na bazach danych odbywają się za pośrednictwem interfejsu API Tridion. Nie zrobiliśmy nic niezwykłego w kwestii rozwoju i publikowania Tridion, więc nic nie różni się od tego, co robiliśmy w ciągu ostatnich kilku lat. Natężenia ruchu na naszej stronie są obecnie stosunkowo niskie (i były znacznie wyższe w przeszłości), więc jesteśmy pewni, że nie ma w tym problemu.

Jedna rzecz, którą właśnie usłyszałem, może być podłączona - krótko przed pojawieniem się problemu nie udało nam się przeprowadzić jednej z naszych wewnętrznych zapór ogniowych, ale nie możemy wymyślić, w jaki sposób może to spowodować problem. widzenie. Poza przełączaniem awaryjnym zapory nie można znaleźć żadnych innych zmian w łączności między serwerem aplikacji a bazą danych.

Czy ktoś ma jakieś sugestie, gdzie moglibyśmy szukać rozwiązania tutaj? Właśnie otworzyliśmy zgłoszenie do pomocy technicznej z SDL, ale w tej chwili są tak samo zaskoczeni jak my.

Dzięki.

+0

Szukamy możliwego problemu z konfiguracją zapory ogniowej zgodnie z sugestiami przedstawionymi poniżej. Opowiem o tym, kiedy znam całą historię. – ThatITBloke

+0

Powróciliśmy do pierwotnej zapory sieciowej wczoraj (wczesnym rankiem), mimo że nasi użytkownicy infrastruktury nie wydają się sądzić, że te dane przechodzą przez wspomnianą zaporę. Wracamy więc do "oryginalnej" konfiguracji i chociaż wciąż widzimy sesje z maksymalnie otwartymi kursorami w dziennikach, nie rosną one w takim samym dramatycznym tempie, jak były - około 5-10 dziennie zamiast 50 -100. Wciąż nie jesteśmy mądrzejsi co do źródła problemu, ale zrobienie tego, co zrobiliśmy wraz ze zwiększeniem maksymalnej liczby kursorów do 1000, sprawiło, że kwestia ta jest teraz o wiele łatwiejsza w zarządzaniu. Obserwuj tą przestrzeń... – ThatITBloke

Odpowiedz

4

Nie jestem pewien co do SDL Tridion R5.3, ale w 2011 SP1 jest znany problem, który używa JNDI (w połączeniu z WebSphere I wierzę), gdy ResultSets nie są jawnie zamknięte, to pozostawi kursory otwarte.

Rozwiązaniem jest po prostu jak Oracle stany dokumentacji, należy zwiększyć liczbę dozwolonych kursorów lub jeśli biec do problemów, jak mówisz, może warto rozważyć nie używać JNDI. Jeśli to możliwe, możesz sprawdzić swój własny kod do poprawnego zamykania ResultSets (który zgodnie z JavaDoc dla ResultSet :: nie jest konieczny, chociaż wydaje się, że jest to prawdą tylko wtedy, gdy nie używa JNDI, podczas używania JNDI wydaje się opuszczać kursory otwarty).

7

Mamy doświadczonych podobny problem w przeszłości z IBM WebSphere. W naszym scenariuszu główną przyczyną problemu jest przekroczenie limitu czasu przez zaporę dla nieczynnych lub nieaktualnych połączeń i zerwanie połączeń między serwerem aplikacji a bazą danych, ponieważ limit czasu na zaporze jest niższy niż limit czasu połączenia serwera AppServer.

Może warto najpierw sprawdzić to i upewnić się, że to nie jest podstawowa przyczyna, zajęło nam trochę czasu, aby dowiedzieć się tego dla nas, ponieważ spędzamy dużo czasu analizując logi aplikacji i aplikacji Tridion itp. Zakładam jBoss ma podobne ustawienie jak WebSphere.

Rozwiązaniem, które zaimplementowaliśmy, jest ustawienie wartości niższej niż ustawienie limitu czasu zapory sieciowej na . Pozwoliło to serwerowi WebSphere Application Server wyczyścić nieużywane połączenia, zanim zapora ich upuści.

Powiązane problemy