Aktualizacja 2016.02.0.00 z dnia 2016-07-27 JOB_CLEARSESSIONS

[tom-kom.pl]

Witam.
Bardzo proszę o pomoc w temacie nie zamkniętych sesji w bazie Oracle.
Po instalacji aktualizacji nie mogę zalogować się do systemu gdyż wyskakuje błąd JOB-CLEARSESSIONS (Możliwość uruchomienia programu z innych stanowisk została zablokowana do czasu naprawienia blędu. Jeśli są stanowiska na których są już zalogowani użytkownicy byłoby dobrze, gdyby zakończyli pracę).
Proszę o instrukcję w jaki sposób mogę zamknąć istniejące sesje i zalogować się do programu

[09061303]

Z opisu aktualizacji - nawiasem bez czytania opisu aktualizować to dość odważne

Opis nowej wersji systemu KS-SOMED w załączniku. Uwaga. W przypadku aktualizacji bazy Oracle mogą pojawić się problemy z procedurą JOB_CLEARSESSIONS. Wynikają one z braku uprawnień. W takiej sytuacji upgrade zgłosi problem iż nie może utworzyć procedury na bazie danych, która odpowiada za czyszczenie sesji. Nie jest to problem uniemożliwiający korzystanie z systemu. Ot, w przypadku sesji, które pozostały po zawieszonym programie, job na bazie ich nie usunie, bo job działać nie będzie. Jak pisaliśmy w biuletynie można te sesje zabić ręcznie. Można też zalogować się na użytkownika systemowego i nadać uprawnienia: GRANT ALL ON GV_$SESSION TO PUBLIC.

[Slawek]

A tak po ludzku?
Muszę wynajmować informatyka do oprogramowania jednego gabinetu stomatologicznego?

[maciejj]

Równie dobrze można powiedzieć: czy muszę płacić dentyście za odbudowę ubytku?

Tak, jak napisane w opisie aktualizacji - zaloguj się do Oracle'a na użytkownika systemowego (as SYS) i wykonaj polecenie GRANT ALL ON GV_$SESSION TO PUBLIC

[Slawek]

Dzięki za odpowiedź.
Dentyście za odbudowę ubytku zapłacę.
Tylko dlaczego przed tym muszę sam sporządzić amalgamat i założyć mu nowe wiertło?!

[Sorn]

Dzięki za odpowiedź.
Dentyście za odbudowę ubytku zapłacę.
Tylko dlaczego przed tym muszę sam sporządzić amalgamat i założyć mu nowe wiertło?!

Nie musisz... możesz zlecić te czynności komuś innemu

[Grumens]

Cześć,
Zalogowałem się, wpisałem polecenie, pojawiła się cyfra 2 i dalej to samo. Czy coś robię nie tak?

[Sorn]

Cześć,
Zalogowałem się, wpisałem polecenie, pojawiła się cyfra 2 i dalej to samo. Czy coś robię nie tak?

GRANT ALL ON GV_$SESSION TO PUBLIC;

Musisz podać ";" na końcu polecenia.

[Grumens]

Ok, dziękuję, jednak to nie wystarczyło, musiałem zalogować się na SYS, bo na SYSTEM za mało uprawnień.

[jawala]

Witam, mam ten sam problem po aktualizacji bazy ale nie mogę w ogóle otworzyć strony bazy, po wpisaniu http://127.0.0.1:8080/apex/apex otwiera mi się strona z jakimś tekstem w html. Bardzo proszę o pomoc bo jutro gabinet musi pracować, a w tym momencie nie można uruchomić KS-a i trochę gorąco się robi.

Edit: Dla potomnych - udało się zalogować do bazy bez znajomości hasła przez wiersz poleceń oracle i wykonać polecenie GRANT ALL ON GV_$SESSION TO PUBLIC; dzięki temu tematowi, a w szczególności postowi http://forumpps.pl/index.php?topic=9781.msg68964#msg68964

[adam5]

Witam
Po tej aktualizacji też mam ten sam problem. Nie mogę wykonać tego polecenia na koncie systemowym (sysdba), bo nie mogę się na nie zalogować - wymagane jest hasło, którego nie znam.

W komunikacie kamsoft napisał "...Jak pisaliśmy w biuletynie można te sesje zabić ręcznie...."
W somedzie mogę jedynie wejść do modułu serwis i tam widzę swoje 2 sesje, z których tylko jedną mogę zamknąć ale i to nie pomaga.

Próbowałem te polecenie odpalić na bazie będąc zalogowanym na użytkowniku "GABINET", ale wyskakuje błąd:
GRANT ALL ON GV_$SESSION TO PUBLIC;
GRANT ALL ON GV_$SESSION TO PUBLIC
             *
BŁĄD w linii 1:
ORA-00942: table or view does not exist

Wersja Oracle to 10g zainstalowana se serwerze pod Debianem.
Może ktoś zna inne rozwiązanie, chociaż żeby wyłączyć tą procedurę "JOB_CLEARSESSIONS" do czasu ustalenia hasła konta systemowego.
 
Z góry dziękuje i pozdrawiam
Adam

[09061303]

Nic nie wyłączysz - chyba, że cofniesz się z wersją Somedu do tej sprzed aktualizacji.
No ale przecież jak masz dostęp do serwera, to zaloguj się na nim na konto oracla (linuksowe konto oczywiście), odpal sqlplusa i zaloguj się jako sysdba - jak się logujesz do bazy z serwera, to bez hasła można się zalogować (connect /as sysdba). Dodatkowo będziesz mógł sobie hasło na sys'a zmienić od razu.

[adam5]

Po zalogowaniu na serwer wszystko robi się z lini komend i nie działa polecenie sqlplus.

Loguje się poprzez program putty na konto root. Wydaje mi się, że należało by jakiś pakiet doinstalować z klientem oracla?

Po wyświetleniu wszystkich katalogów widzę folder oracle-xe a w nim dwa pakiety instalacyjne oracla
oracle-xe_10.2.0.1-1.1_i386.deb  oracle-xe-universal_10.2.0.1-1.1_i386.deb
i nic więcej.

Jakby konto roota nie miało dostępu do wszystkich folderów?

[09061303]

A jest może konto o nazwie oracle - standardowo takie powinno być stworzone do instalacji oracla. Jak tak, to zaloguj się na nie.
Po drugie muszą na sesji być ustawione przynajmniej dwie zmienne środowiskowe pod Oracla - ORACLE_HOME i do zmiennej PATH ma być dodana ścieżka do home'a oracla (powinny być, bez nich raczej oracle nie wystartuje, ale kto tam wie).
Po trzecie - jeżeli nie masz dodanej jako alias czy zmienna środowiskowa nic pod sqlplus'a, to wejdź do katalogu bin w Oraclu i odpalaj to stąd, powinno się udać.
To że działa się w linii poleceń jest wystarczające. sqlplus instaluje się zawsze razem z serwerem. Root pewnie ma dostęp do wszystkiego, ale nie wiadomo, gdzie został zainstalowany oracle, w którym katalogu. Pakiety deb to są instalki, domyślnie oracle 10 instalował się w /usr/lib/oracle (przynajmniej na opensusach, na tych wcześniej stawiałem dzieisątki), ale jak się nie skonfigurowało dobrze konta oracle przed instalacją, mógł wylądować gdzie indziej.

[adam5]

Dzięki za pomoc. Na konto oracla i tak nie mogę się zalogować, jeżeli takowe nawet jest. Na koncie roota mam tylko jeden folder związany z oracle, na którym jest tylko pakiet instalacyjny. Spróbuje jeszcze dzisiaj fizycznie dostać się do serwera, może domyślnie jest uruchomione konto oracla.