Błąd po migracji do Oracje 11g XE

[Robinson]

witam,
zrobiłem migrację do Oracja 11g XE i wszystko wyglądało ok, Somed chodził, Pełny test ładnie przeszedł zrobiłem aktualizację do nowej wersji tj 2016.03.0.3 i wysypał się błąd:

Przebudowa obiektu: KSPL_ALERTS (typ: PACKAGE BODY), zakończyła się niepowodzeniem:
   linia poz. Błąd         
==========================
      26    7 PLS-00201: identifier 'DBMS_ALERT' must be declared
      26    7 PL/SQL: Statement ignored
      29    7 PLS-00201: identifier 'DBMS_ALERT' must be declared
      29    7 PL/SQL: Statement ignored
      32    7 PLS-00201: identifier 'DBMS_ALERT' must be declared
      32    7 PL/SQL: Statement ignored
      35    7 PLS-00201: identifier 'DBMS_ALERT' must be declared
      35    7 PL/SQL: Statement ignored
      38    7 PLS-00201: identifier 'DBMS_ALERT' must be declared
      38    7 PL/SQL: Statement ignored

a przy wejściu do Gabinetu przy imporcie:

Wystąpił błąd podczas kopiowania słownika PRPT.

Kopiowany rekord:
  KOD: 90134
  NAZW: LECZENIE PIERWOTNYCH NIEDOBORÓW ODPORNOŚCI (PNO) U PACJENTÓW DOROSŁYCH Z ZASTOSOWANIEM IMMUNOGLOBULINY LUDZKIEJ NORMALNEJ PODAWANEJ Z REKOMBINOWANĄ HIALURONIDAZĄ LUDZKĄ
  NAZ2:
  DEL: 0

---
ORA-12899: value too large for column "GABINET"."PRPT"."NAZW" (actual: 155, maximum: 150)

czy ktoś mógłby pomóc? Z góry dziękuję i pozdrawiam.

[09061303]

Duże prawdopodobieństwo, że nie masz(user somedowy gabinet) uprawnień do DBMS_ALERT. Daj spod SYS'a
grant execute on dbms_alert to gabinet
(chyba, że użytkownika inaczej nazwałeś, to zmień odpowiednio), puść test pełny bazy (rekompilowane są wtedy obiekty bazy) i sprawdź czy błąd jest dalej.

Z tego co widzę w jednej instalacji to w wersji z końcówką 01 rozmiar kolumny NAZW jest taki sam. Wg mnie Kamsoft coś pokręcił w aktualizacji albo nie przeszedł alter zwiększający dopuszczalną długość tekstu. Raczej to pierwsze, bo w tabeli jest pole NAZ2, gdzie w przypadku innych kodów jest przerzucana reszta tekstu powyżej 150znaków. Podpada to pod zgłoszenie Kamsoftowi, ale doraźnie spróbuj tak zrobić (tylko musisz się podłączyć jakimś narzędziem do edycji baz, ostatecznie sqlplus):
- kopia danych z tabeli w razie W
create table prptkopia as select * from prpt
- dalej rozszerzamy pole NAZW do 200znaków
alter table prpt modify nazw varchar2(200)
- zatwierdzamy zmiany
commit
- teraz zrób aktualizację aplikacji - nie powinno być błędu
- przywrócenia rozmiaru kolumny do stanu początkowego
-- sprawdzenie czy jest tylko jeden rekord o kodzie 90134 - ma być tylko jeden
select * from prpt where kod='90134'
-- rozdzielenie odpowiednie tekstu
update prpt set naz2=substr(nazw,151,length(nazw)),nazw=substr(nazw,1,150) where kod='90134'
--zmiana długości pola nazw do stanu początkowego
alter table prpt modify nazw varchar2(150)
-- zatwierdzenie zmian
commit

Powinno być ok, ale nie przeszedłem całości pod bazą, także może jakaś literówka się trafić.
Po dwa mogą wyjść jakieś problemy pod Twoją instalacją - ogólnie wolałbym to sam robić (nie lubię pisać komuś jak próbować bawić się pod bazą z powodu nieprzewidzianych komplikacji, ale tym akurat nie powinno się zepsuć nic).

Sorki za brak ładnego formatowania, ale pisałem to na szybko.

[Robinson]

cześć 09061303, jesteś moim mistrzem działającym nawet w wigilię
zatem:
1. DBMS_ALERT wg Twojego przepisu poszło i jest ok
2. odnoście rozszerzenia pola NAZW poszło, aktualizacja poszła ok, próbując zmienić :

--zmiana długości pola nazw do stanu początkowego
alter table prpt modify nazw varchar2(150)

pojawił się błąd ORA-01441: cannot decrease colum length because some value is too big
robiąc select * from prpt where kod='90134' pole

Program działa, pełny test przechodzi ok.

Dzięki za pomoc !!! pozdrawiam

[09061303]

Fajnie.
Co do błędu ORA-01441 to w takim razie trzeba by sprawdzić, które rekordy mają kolumnę nazw>150 i odpowiednio je skrócić przesuwając nadmiarowe znaki do naz2 (opis procedury jest po prostu cięty pomiędzy nazw i naz2) i później puścić jeszcze raz to polecenie i zacommmitować. Teoretycznie bez zmiany do stanu pierwotnego definicji tej tabeli nie powinno się nic zdarzyć, ale jestem zdania, że jednak lepiej po sobie zostawić "porządek" twórcy bazy, bo mimo wszystko może mieć to w przyszłości podczas aktualizacji znaczenie.
Wesołych Świąt

[Robinson]

Też i tak uczynię

Jeszcze raz dzięki !!!

[Sorn]

Takich modyfikacji bym nie wprowadzał na bazie. Jeżeli po migracji występują błędy długości nazw to najprawdopodobniej bazę zainstalowałeś w domyślnej amerykańskiej stronie kodowej (innej zresztą nie można wybrać). Trzeba ją zmienić na EE8MSWIN1250 inaczej tekst zajmuje dwa razy więcej miejsca niż powinien i dlatego pojawiają się błędy. Baza raczej nie będzie działać poprawnie i takie błędy będą pojawiać się notorycznie.
Na ftp Kamsoftu jest instrukcja i skrypty jak to zrobić ftp.kamsoft.pl/pub/Archiwum/ORACLE/OracleXE_10g/OracleXE_Windows
Tylko operacje trzeba wykonać na pustej bazie zaraz po zainstalowaniu (zmiana strony kodowej jest oficjalnie niewspierana przez Oracle ale działa).
Ewentualnie można wykorzystać gotowe w odpowiedniej stronie kodowej. Pliki także dostępne są na ftp.

Radzę zrobić to jak najszybciej zanim pracownicy zaczną wprowadzać dane...

[MK]

Potwierdzam. Raczej nie stawiałbym na to, że Kamsoft coś zepsuł w aktualizacjach. Raczej stawiałbym na to, że baza jest źle przygotowana. I każda "polska literka", pewnie poza o z kreską, jest zapisywana zamiast na jednym bajcie na dwóch. I już to powoduje, że do pola o długości 6 znaków może się zmieścić  ,. 5 czy nawet mniej tekstu - taka żółć mogła by takie pole zabić :-)

[09061303]

Zapewne koledzy mają rację. Ja niestety założyłem, że jak ktoś robi migrację to rzeczy podstawowe (m.in. strona kodowa) są sprawdzone/ustawione - mój błąd, stąd powyższe nie pomoże na dłuższą metę. Jak napisał Sorn - baza do ponownej migracji po przestawieniu strony kodowej.

[Robinson]

Dzięki za podpowiedź, z tego co czytam to tu jest sposób dla nowej czystej bazy a co w moim przypadku migracji ale z importem bazy już istniejącej?

[Robinson]

Przy imporcie bazy mam :

Export file created by EXPORT:V10.02.01 via conventional path
import done in EE8MSWIN1250 character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
List contents of import file only (tak/nie): nie >

[konzik]

Zainstaluj EE8MSWIN1250 na nowy Oracle. Wtedy import powinien ruszyć. Jeśli potrzebujesz skryptów instalujących język Win1250 dla Oracle Xe, to napisz na priv.

[09061303]

Import pójdzie tak czy inaczej - jest to tylko komunikat. Poobcinane mogą być jednak znaki narodowe.
Baza istniejąca (dump) jest na dobrej stronie kodowej. Teraz musisz mieć czystą instalację - bez schematu gabinet i zaimportowanych do niego danych (możesz wszystko dropnąć), na której odpalasz skrypt zmiany strony kodowej. Później imp dopiero.
Uwaga tylko na jedną rzecz w skrypcie spod linku podanym przez Sorna - parametr JOB_QUEUE_PROCESSES. Na podstawie wypowiedzi jednego z programistów Kamsoftu ustawienie go na 0 nie jest do końca dobre, może powodować błędy przy działaniu Somedu (o ile dobrze pamiętam to nowy mechanizm zarządzania sesjami jest od jobów zależny, a ten parametr jest z nimi powiązany). Lepiej wydaje się go nie zmieniać z wartości domyślnej.

[Sorn]

@09061303 Masz rację w sprawie JOB_QUEUE_PROCESSES.
Nie zauważyłem, że ten skrypt zmienia wartość na zero
Lepiej zostawić go na domyślnym poziomie lub podnieść jeżeli jest zbyt mały.

Znalazłem wieki temu wzór do ustalania wartości zależnych parametrów (sessions i transactions).
processes=x
sessions=x*1.1+5
transactions=sessions*1.1

@Robinson Tak jak pisali koledzy musisz zainstalować wszystko od nowa.
Najprostszym sposobem jest odinstalowanie OracleXE, usunięcie katalogu i instalacja wszystkiego od nowa.
Zaraz po instalacji uruchamiasz skrypt ale usuń wcześniej z pliku .sql ustawianie JOB_QUEUE_PROCESSES na zero (jak słusznie zauważył 09061303).
Teraz możesz kontynuować i importować dane z oryginalnej bazy.
Wszelkie nowe dane wprowadzone na nowej bazie utracisz dlatego trzeba będzie je wprowadzić od nowa już na poprawnie zaimportowanej bazie.

[MK]

Z tym programistą i JOB_QUEUE_PROCESSES to pewnie o mnie chodziło 
To nie jest tak, że ustawienie w tym skrypcie tej wartości na 0 jest głupie.  Ma ono całkiem głęboki sens. Po prostu ustawienie na 0 gwarantuje nam, że żaden proces w tle się nie dzieje, że nic nam nie przeszkadza i że możemy spokojnie zmienić stronę kodową. A że to musi być "na spokojnie" to wynika chociażby z tego, że możemy zrobić to tylko na czystej bazie. Z JOB_QUEUE_PROCESSES jest ten problem, że PO ZAKOŃCZENIU skryptu, czyli PO WYKONANIU zmiany strony kodowej należy PONOWNIE ustawić preferowaną wartość. Ja nie powiem jaką, bo nie mam pojęcia co i jak na danym serwerze jeszcze pracuje albo pracować będzie. Na pewno nie wartość 0.

[Robinson]

Dzięki Panowie za wskazówki biorę się za testy.
Dam znać jak poszło

Pozdrawiam