Autor Wątek: Zmiany w Somedzie. (Przeczytany 28400 razy)

Sławek · « **Odpowiedź #45 dnia:** Grudnia 29, 2015, 16:49:28 pm »

Miałem taki przypadek że nie zapisywał skierowań, po kliknięciu dodaj pojawiał się komunikat o błędzie i aplikacja się zamykała. Okazało się że jakiś indeks był zablokowany i odblokowanie zablokowanych rekordów pomogło, drugi przypadek dotyczył także problemów z otwieraniem formularzy, na szczęście okazało się że dotyczy to tylko Windows Serwer, ( przeglądarka działała bez problemu ) i na stanowiskach roboczych nie było z tym problemu. W każdym bądź razie sprawdź czy to jest tylko na jednym stanowisku czy na wszystkich, sprawdź bazę testami z modułu serwis i dobrze jakby IE była zaktualizowana.

Pozdrawiam

zibi82 · « **Odpowiedź #46 dnia:** Stycznia 14, 2016, 08:37:57 am »

Ja mam problem z terminarzem tzn. jeśli jest dodana konkretna poradnia do terminala danego użytkownika to nie może on wejść do modułu bo go wywali i rozłączy program z bazą danych. Próba dodania tego gabinetu u użytkowników, którzy nie mają go dodanego, także powoduje ten sam problem. Problem pojawił się po aktualizacji do wersji 2016.03.1.06 wgranie 2016.03.1.07 nic nie pomogło. Baza Oracle błąd -ORA-03113: koniec pliku w kanale komunikacyjnym.

leszekr · « **Odpowiedź #47 dnia:** Lutego 03, 2016, 18:34:53 pm »

Cytat: gringo w Grudnia 14, 2015, 13:42:34 pm

Tak przy okacji, czy ktoś już stawiał Somed na Oracle 12?
Zmieniła się architektura w 12 i nie można używać zmiennych $ dla widoków w bazie a jak wiadomo jeden z nich w Somedzie ma nazwę "v$s". Coś z tym fantem KS zaradził, czy jeszcze nie używamy v. 12 ?

Ja używam na 12 (u jednego klienta od 2 lat). Ale są problemy z integracją. Przy każdej aktualizacji trzeba wykonać kilka dodatkowych czynności od strony bazy.

gringo · « **Odpowiedź #48 dnia:** Lutego 07, 2016, 20:37:47 pm »

Cytat: leszekr w Lutego 03, 2016, 18:34:53 pm

Cytat: gringo w Grudnia 14, 2015, 13:42:34 pm

Tak przy okacji, czy ktoś już stawiał Somed na Oracle 12?
Zmieniła się architektura w 12 i nie można używać zmiennych $ dla widoków w bazie a jak wiadomo jeden z nich w Somedzie ma nazwę "v$s". Coś z tym fantem KS zaradził, czy jeszcze nie używamy v. 12 ?

Ja używam na 12 (u jednego klienta od 2 lat). Ale są problemy z integracją. Przy każdej aktualizacji trzeba wykonać kilka dodatkowych czynności od strony bazy.

No właśnie, podejrzewam że to w związku z tym nieszczęsnym widokiem w ks-somed. Możesz coś więcej napisać? Pewnie jakiś alter, który zmienia nazwę widoku i odwołania innych obiektów do zmienionej nazwy....
Teoretycznie można by przeanalizować odwołania do tego widoku, zmienić jego nazwę i odwołania....

Sławek · « **Odpowiedź #49 dnia:** Lutego 08, 2016, 00:00:17 am »

Cytat: zibi82 w Stycznia 14, 2016, 08:37:57 am

Ja mam problem z terminarzem tzn. jeśli jest dodana konkretna poradnia do terminala danego użytkownika to nie może on wejść do modułu bo go wywali i rozłączy program z bazą danych. Próba dodania tego gabinetu u użytkowników, którzy nie mają go dodanego, także powoduje ten sam problem. Problem pojawił się po aktualizacji do wersji 2016.03.1.06 wgranie 2016.03.1.07 nic nie pomogło. Baza Oracle błąd -ORA-03113: koniec pliku w kanale komunikacyjnym.

ten problem już dwa razy mi wyskoczył, na szczęście restart serwera załatwia sprawę, ale pytanie pozostaje dlaczego tak się dzieje i Oracl się zapycha ?

zibi82 · « **Odpowiedź #50 dnia:** Lutego 23, 2016, 09:46:38 am »

Niestety u mnie problem znów powrócił tym razem w module ZLECENIA->WYKONANIE. Paraliż straszny każdy rozkłada ręce. Troszkę boję się resetowania serwera bo mamy integracje z RIS, MEDISA i inne pierdoły. Jeśli ma ktoś jakieś pomysły co można zrobić to jestem otwarty na propozycję.

Sorn · « **Odpowiedź #51 dnia:** Lutego 23, 2016, 10:52:02 am »

wygeneruj query z momentu w którym problem występuje.
Może będzie widać w czym jest problem

MK · « **Odpowiedź #52 dnia:** Lutego 23, 2016, 12:15:38 pm »

Cytat: zibi82 w Lutego 23, 2016, 09:46:38 am

Niestety u mnie problem znów powrócił tym razem w module ZLECENIA->WYKONANIE. Paraliż straszny każdy rozkłada ręce. Troszkę boję się resetowania serwera bo mamy integracje z RIS, MEDISA i inne pierdoły. Jeśli ma ktoś jakieś pomysły co można zrobić to jestem otwarty na propozycję.

Sprawdź co piszą w Internetach. Taki błąd, a więc: Oracle błąd -ORA-03113: koniec pliku w kanale komunikacyjnym może być spowodowany fizycznym uszkodzeniem bazy danych. Nie wiązałbym go z samym KS-SOMED. Trzeba by było fachowca od Oracle, zebrać logi z pracy serwera, inne pliki serwerowe (nie QueryTrace, bo według mnie, nie jest to problem KS-SOMED) i przeanalizować. Dopiero wówczas będzie coś więcej wiadomo. Nie przechodziłbym do porządku dziennego nad tym problemem.

09061303 · « **Odpowiedź #53 dnia:** Lutego 23, 2016, 13:41:30 pm »

Spróbuj testowo zrobić dumpa z wszystkich schematów z bazy poza systemowymi. Jak przejdzie bez ostrzeżeń, to, jak napisał MK, przyglądnij się bazie danych. Jeśli kopia pójdzie bez ostrzeżeń, to przynajmniej masz kopię i można nawet myśleć o reinstalacji bazy. Sprawdź sobie dyski czy nie mają jakichś bad sectorów - często jest to powód niewyjaśnionych problemów.

Sorn · « **Odpowiedź #54 dnia:** Lutego 24, 2016, 08:57:26 am »

Cytat: MK w Lutego 23, 2016, 12:15:38 pm

może być spowodowany fizycznym uszkodzeniem bazy danych.

Ale nie musi

Dlaczego napisałem o query: w query trace będzie informacja przy którym zapytaniu pojawia się błąd. Wtedy wystarczy to zapytanie wywołać ręcznie w dowolnym kliencie bazy danych. Jeżeli pojawi się błąd to jest szansa na więcej szczegółów i błąd będzie ewidentnie po stronie bazy danych. Może uda się coś ręcznie naprawić jakimś updatem z pomocą Kamsoft bez konieczności przywracania bazy z backupu.
Jeżeli wykona się poprawnie to znaczy, że Somed nie radzi sobie ze zwracanym wynikiem bo jest z jakiegoś powodu niestandardowy. Tu też może pomóc update na bazie albo poprawka w Somed

MK · « **Odpowiedź #55 dnia:** Lutego 24, 2016, 10:52:34 am »

Cytat: Sorn w Lutego 24, 2016, 08:57:26 am

Cytat: MK w Lutego 23, 2016, 12:15:38 pm
może być spowodowany fizycznym uszkodzeniem bazy danych.
Ale nie musi

Jeżeli wykona się poprawnie to znaczy, że Somed nie radzi sobie ze zwracanym wynikiem bo jest z jakiegoś powodu niestandardowy. Tu też może pomóc update na bazie albo poprawka w Somed

Powoli, to jest błąd zgłaszany przez klienta oracle. I to błąd nie typu, że ktoś głupoty od klienta chce (np. błędna składnia rozkazu) ale błąd komunikacji klient-serwer. To nie SOMED nie radzi sobie z danymi...
A innego błędu nie będzie, nie będzie więcej szczegółów niż zgłosił SOMED. SOMED przekazał dokładnie ten komunikat, jaki mu zwrócił klient Oracle. Stąd numer ORA-03113.
Kolejna sprawa, zapytanie zwykle się wykonuje, ale... ale zwykle każdy poprzestaje na tym co mu dowolny edytor SQL zwróci. A one zwracają np. 25 pierwszych rekordów. Aby być święcie przekonanym, że zapytanie wykona się poprawnie, należy pobrać WSZYSTKIE zwrócone dane. Proszę zauważyć, jak wygląda wykonanie zapytania SQL. W miarę szybko dostajemy wynik, np. 25 rekordów. Przeskakujemy "o ekran", chwila zwłoki i pojawiają się kolejne dane. I tak dalej i tak dalej. Omawiany tu błąd zwykle pojawi się po jakimś czasie, gdy serwer pobiera i próbuje nam zwrócić dane z uszkodzonego obszaru. Indeks był prawidłowy, więc Oracle dany rekord zakwalifikował do wyświetlenia i jak będzie potrzeba to go pobierze i prześle do klienta. I właśnie, dopiero podczas przeglądania, gdy rzeczywiście do danego rekordu nastąpi odwołanie (a nie do indeksu, który na rekord wskazuje) mamy błąd.
Oczywiście, to tylko jeden ze znanych mi scenariuszy, chciałbym tylko raz jeszcze sugerować, opis błędu wyraźnie mówi o problemach pomiędzy klientem a serwerem oracle. SOMED nie ma tu nic do tego. Tak przynajmniej wszystkie dostępne mi informacje o tym błędzie mówią.

Sorn · « **Odpowiedź #56 dnia:** Lutego 26, 2016, 10:01:28 am »

Cytat: MK w Lutego 24, 2016, 10:52:34 am

Oczywiście, to tylko jeden ze znanych mi scenariuszy, chciałbym tylko raz jeszcze sugerować, opis błędu wyraźnie mówi o problemach pomiędzy klientem a serwerem oracle. SOMED nie ma tu nic do tego. Tak przynajmniej wszystkie dostępne mi informacje o tym błędzie mówią.

Jest dużo prawdy w tym co Pan pisze i zgadzam się z tym w 99%. Nie zgodzę się jednak z tym, że Somed nie ma tu nic do powiedzenia.
To, że Somed zwraca jakiś błąd Oracle nie znaczy to, że Somed sam w sobie nie ma błędnie zaimplementowanej funkcjonalności.
Czasami włączenie jednej opcji może spowodować, np niemożność dodawania zleceń do systemu (ponieważ Somed inicjuje transakcję ex w trakcie trwania transakcji ex, co powoduje błąd oracle i wywołanie rollback przez Somed - taki błąd ostatnio rozwiązywałem).

Dlatego query.trc jest dla mnie zawsze podstawą analizy problemu, bo wiem gdzie problem wystąpił i mamy punkt zaczepienia.

Dodatkowo błąd o którym mówimy, może ale nie musi być spowodowany błędem na bazie. Przyczyn tego błędu może być wiele.

Ps. W większości programów klienckich wystarczy nacisnąć ctrl+end aby przejść na koniec listy wyników co powoduje pobranie wszystkich rekordów wynikowych z bazy.

MK · « **Odpowiedź #57 dnia:** Lutego 26, 2016, 15:59:01 pm »

Cytat: Sorn w Lutego 26, 2016, 10:01:28 am

Czasami włączenie jednej opcji może spowodować, np niemożność dodawania zleceń do systemu (ponieważ Somed inicjuje transakcję ex w trakcie trwania transakcji ex, co powoduje błąd oracle i wywołanie rollback przez Somed - taki błąd ostatnio rozwiązywałem).

Ależ oczywiście, tyle, że rozważamy tu problem całkiem innej natura. Ten konkretny błąd oracle, o tym konkretnym numerze. I tu się upierać będę, to jest błąd komunikacji Oracle (klient - serwer)

Cytat: Sorn w Lutego 26, 2016, 10:01:28 am

Ps. W większości programów klienckich wystarczy nacisnąć ctrl+end aby przejść na koniec listy wyników co powoduje pobranie wszystkich rekordów wynikowych z bazy.

Jasne, ale w tym rozwiązaniu nie wiemy kiedy się wywali. idąc rekord po rekordzie możemy ocenić np. o jakich pacjentów mogło chodzić. Co nie zmienia faktu, że sam bym skoczył kombinacja na koniec aby powiedzieć: moja rola się skończyła SOMED nic tu do tego nie ma, sprawdź bazę.

Co do transakcji też zgoda, aczkolwiek... aczkolwiek błąd transakcji zwraca UniDac nie klient ani też serwer Oracle. Dlatego też problemy te teraz wychodzą. BDE maskowało takie błędy i podwójne transakcje, zastosowanie których umówmy się, jest naszym przeoczeniem i wyszło przez przypadek (jak mamy funkcję w funkcji w funkcji i to jeszcze poganiane inną funkcją czasem można przeoczyć, że najgłówniejsza funkcja transakcję rozpoczęła już i rozpoczynamy ponownie w funkcji wewnętrznej, w której i tak transakcji być musi, bo w innej konfiguracji, to ta wewnętrzna jest najgłównijeszą

) przepuszczało, UniDAC jest tu bardziej restrykcyjny.

Sorn · « **Odpowiedź #58 dnia:** Lutego 29, 2016, 13:19:47 pm »

Cytat: MK w Lutego 26, 2016, 15:59:01 pm

Ależ oczywiście, tyle, że rozważamy tu problem całkiem innej natura. Ten konkretny błąd oracle, o tym konkretnym numerze. I tu się upierać będę, to jest błąd komunikacji Oracle (klient - serwer)

Za docs.oracle.com:
ORA-03113: end-of-file on communication channel
Cause: The connection between Client and Server process was broken. It may also happen if the external agent extproc crashes for some reason.
Action: There was a communication error that requires further investigation. First, check for network problems and review the SQL*Net setup. Also, look in the alert.log file for any errors. Finally, test to see whether the server process is dead and whether a trace file was generated at failure time. There may be some system calls in the .NET function which might terminate the process. Remove such calls.

Błąd jest związany z zerwaniem sesji. Równie dobrze Somed może rozłączać sesję w związku z jakimś błędem, lub jest to uszkodzenie bazy, jej niepoprawna konfiguracja itp. Bez logów z bazy i query nasza dyskusja jest czysto akademicka, więc chyba powinniśmy już ją zakończyć zwłaszcza, że sam zainteresowany milczy

Aktualności:

Reklama