Migracja danych z Oracle 10g XE do 11g XE z powodu braku pamięci >4GB

[09061303]

@Sorn
Ostrzeżenia po imporcie są dopuszczalne jak chodzi o widoki, ale tam wywalają się triggery. Tego, bez dokładnego spojrzenia co to za tabela i czego dotyczy błąd raczej bym nie przepuszczał.

@BartOr
Błąd z impa IMP-00041: Warning: object created with compilation warnings dotyczący jakiegoś obiektu nie mówi o samej przyczynie problemu. Kod takiego obiektu trzeba wziąć, podłączyć się na użytkownika na którym obiekt ma być jakimś klientem sql  - może być wszędzie obecny sqlplus - i go odpalić. Wtedy powinieneś dostać błąd bardziej nas interesujący, bo będzie w nim napisane jakiego elementu kodu dotyczy problem. Ja dalej śmiem twierdzić, ale to tylko strzelanie, że problem leży po stronie DBMS_ALERT, ale może być inaczej.
Błąd, który siadł Ci na DSWD, może wynikać z nieutworzenia jakiegoś obiektu typu trigger lub sekwencja z odpowiednią wartością razem z niezałączeniem klucza podstawowego na tej tabeli. Rzeczywiście, zgadzam się z przedmówcami, że pusta.ora niekoniecznie jest pusta, tym bardzie, że z Kamsoftu masz skrypt tworzący tabelę KSLIC a nie przestrzenie. Bez przestrzeni, ale z użytkownikiem może się udać import, ale wszelkie dane wejdą nie do wydzielonej przestrzeni tylko wspólnej systemowej. Wtedy szukanie w razie problemów czegokolwiek w bazie jest średnio przyjemne.

Mam nadzieję, że stawiasz tego Someda w celach jedynie edukacyjnych, ponieważ elementy, o które pytasz są w zakresie podstawowym bawienia się oraclem (namierzenia czemu się trigger nie kompiluje w ostrzeżeniu z IMPa), ponieważ postawienie bazy to jedno, ale problem jest jak się coś sypnie w trakcie działania produkcyjnego, a forum wtedy nie zareaguje szybko.

[Sorn]

Ostrzeżenia po imporcie są dopuszczalne jak chodzi o widoki, ale tam wywalają się triggery. Tego, bez dokładnego spojrzenia co to za tabela i czego dotyczy błąd raczej bym nie przepuszczał.

W logu są ostrzeżenia dotyczące niemożności skompilowania procedur/pakietów itp. Jest to normalny objaw przy imporcie ponieważ podczas importu nie możesz zagwarantować, że wszystkie zależne procedury, funkcje i pakiety wywoływane w danym obiekcie zostały już zaimportowane. Somed przy pierwszym podłączeniu do bazy kompiluje wszystkie potrzebne mu obiekty. Jeżeli jakiś niezbędny obiekt się nie skompiluje to Somed będzie wymagał naprawy. BartOr nie importuje pusta.ora bo ma dump z bazy produkcyjnej i tutaj postępuje słusznie nie wczytując pusta.ora.

Brak uprawnień do DBMS Somed sam wykrywał i sam odpalał odpowiednią aplikację. O ile się nie mylę to zrezygnowano już z alertów (chyba, że nie do końca).

Dziwi mnie to, że Somed się uruchamia i jak rozumiem podłącza do bazy i można na nim pracować, jednak aktualizacja powoduje problemy.
@BartOr a to polecenie, które Ci wysłałem uruchamiasz jako użytkownik gabinet? Jak się łączysz do bazy?

[MK]

@09061303 Z tego co pamiętam z informacji z Kamsoftu to właśnie 32-bitowe BDE miało być przeszkodą w użyciu 64b klienta ale szczegółów technicznych nie znam. Przy okazji przetestuję.

Nie wiem, czy to już wyjaśnione, chciałbym jednak tu i teraz nieoficjalnie oczywiście (nie reprezentuję o takiej godzinie firmy Kamsoft :-) ) wyjaśnić. TYLKO I WYŁĄCZNIE KLINET 32-BITOWY! Nie wierzę, że taka informacja (z powodu BDE klient 32-bitowy) padła z ust lub spod klawiatury kogoś z Kamsoftu zajmującego się KS-SOMED, jeśli tak, to biedak nie wiedział co czyni.
Dla systemu KS-SOMED TYLKO klient 32-bitowy. Serwer - wszystko jedno - klient 32-bity. I BDE nie ma tu nic do rzeczy raczej to, że sam KS-SOMED jest systemem32-bitowym. Klient oracla to nic innego jak biblioteka dll. Biblioteka (no może kilka, ale to nie istotne), którą aplikacja - w tym przypadku KS-SOMED - ładuje. System operacyjne takie ma cechy, że dla aplikacji 32-bitowej mam tylko 32-bitowe dll. Nie da się "pomieszać" i załadować do 32-bitowej aplikacji 64-bitowej dll. Tego nie dopuści sam system operacyjny. Nie jestem fachowcem od systemów, ale z tego co mnie się wydaje, aplikacje 32-bitowe działają tak jak gdyby w osobnym środowisku wydzielonym z 64-bitowego systemu. Stąd chociażby katalog WOW czy gałęź cośtamWOWcośtam. Aby korzystać z klienta 64-bitowego musielibyśmy mieć 64-bitowego KS-SOMED a takowy zaś nie mógłby działać na 32-bitowych systemach operacyjnych.

[09061303]

Co klienta 32/64bit mogę jedynie powtórzyć, co napisałem wcześniej z praktyki - co prawda nie z Somedem, ale  z Farmanetem miałem dziwne błędy (nie pamiętam czy nie nawet przy samym uruchamianiu) dopóki nie zainstalowałem klienta 32bit za radą Kamsoftu i stwierdzeniem, że aplikacja 32bit=klient 32bit.

@Sorn
Ok - masz rację, te triggery zawierają pakiety lub widoki i dlatego może być ostrzeżenie.

Nawiązałem do pusta.ora, ponieważ się kilka razy przewinęła w wątkach ze strony BartOr'a - wydawało mi się, że chce postawić od nowa Someda da sprawdzenia czy ma dobrze założone użytkownika, przestrzenie i odpowiednio nadane uprawnienia (pusta.ora to dump pustej bazy, rzeczywiście niepotrzebny przy imporcie dumpa z produkcyjnej - nie zauważyłem jednej odpowiedzi BartOr'a, gdzie napisał, że import pustej pomija).

Z tym DSWD - ja bym sprawdził jak to wygląda w bazie pierwotnej, bo albo dump wykonuje się błędnie, albo baza pierwotna jest rozjechana, chociaż ciężko jest usunąć index na kluczu podstawowym.
Somed nie sprawdza wszystkiego przy starcie, uszkodzona DSWD może przejść przy logowaniu, a nawet pracy, jeśli albo nie ruszamy DSWD edycją/dodaniem nowego rekordu albo wartość sekwencji z danymi id nam się tak zgrała, że nie było takiej wartości w DSWD.ID (wtedy nawet indeks klucza podstawowego nie pomoże).

@BartOr
Jeśli zapytanie Sorn'a odpala Ci się z takim błędem jak dałeś wcześniej, to czy aby na pewno łączysz się do dobrego schematu lub czy zaimportowałeś dumpa przez dobrego użytkownika czyli gabinet?
Ogólnie spróbuj jeszcze raz może od:
1. wyrzucenia użytkownika/przestrzeni Somedowych lub reinstalacji Oracla
2. utworzenia użytkownika gabinet i przestrzeni jak pisał Sorn
3. zaimportowania dumpa wykonanego z użytkownika gabinet w pierwotnej bazie przez użytkownika gabinet w nowej.
W tym momencie, przynajmniej ja, zaczynam widzieć tutaj jakąś niespójność - brak obiektu w przypadku zapytania kiedy obiekt jest z poziomu odpalenia aktualizacji, bo mamy błąd.

[BartOr]

Dzięki za zainteresowanie,

Opiszę może po kolei co robiłem. Export mam robiony przez kopie bazy z someda.

Instalacja oracle 32bit 11g XE, następnie kodowanie:

Kod: [Zaznacz]

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;     
ALTER DATABASE CHARACTER SET INTERNAL_USE EE8MSWIN1250;
SHUTDOWN IMMEDIATE;
STARTUP OPEN;
Następnie :

Kod: [Zaznacz]

CREATE PUBLIC SYNONYM V$P FOR V_$PROCESS;
GRANT SELECT ON V_$PROCESS TO PUBLIC;
CREATE PUBLIC SYNONYM V$I FOR V_$INSTANCE;
GRANT SELECT ON V_$INSTANCE TO PUBLIC;
CREATE PUBLIC SYNONYM V$L FOR V_$LOCKED_OBJECT;
GRANT SELECT ON V_$LOCKED_OBJECT TO PUBLIC;
CREATE PUBLIC SYNONYM V$S FOR V_$SESSION;
GRANT SELECT ON V_$SESSION TO PUBLIC;
CREATE PUBLIC SYNONYM V$SI FOR V_$SESS_IO;
GRANT SELECT ON V_$SESS_IO TO PUBLIC;
GRANT SELECT,INSERT,UPDATE ON DUAL TO PUBLIC;
GRANT EXECUTE ON SYS.DBMS_LOCK TO PUBLIC;
GRANT SELECT ON V_$LOG_HISTORY TO PUBLIC;
CREATE PUBLIC SYNONYM V$H FOR V_$LOG_HISTORY;
później użytkownik:

Kod: [Zaznacz]

CREATE TABLESPACE meddata DATAFILE
'C:\oraclexe\app\oracle\oradata\XE\meddata.dbf'
SIZE 150M AUTOEXTEND ON NEXT 50M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
CREATE TABLESPACE medidx DATAFILE
'C:\oraclexe\app\oracle\oradata\XE\medidx.dbf'
SIZE 150M AUTOEXTEND ON NEXT 50M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
CREATE USER gabinet DEFAULT TABLESPACE meddata identified by gm
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT ACCOUNT UNLOCK;
GRANT CONNECT TO gabinet;
GRANT RESOURCE TO gabinet;
GRANT CREATE ANY SEQUENCE TO gabinet;
GRANT CREATE ANY SYNONYM TO gabinet;
GRANT CREATE ANY TABLE TO gabinet;
GRANT CREATE ANY VIEW TO gabinet;
GRANT DROP ANY SEQUENCE TO gabinet;
GRANT DROP ANY SYNONYM TO gabinet;
GRANT DROP ANY TABLE TO gabinet;
GRANT DROP ANY VIEW TO gabinet;
ALTER USER gabinet DEFAULT ROLE ALL;
REVOKE UNLIMITED TABLESPACE FROM gabinet;
ALTER USER gabinet QUOTA UNLIMITED ON meddata;
ALTER USER gabinet QUOTA UNLIMITED ON medidx;
Następnie importuję bazę przez:

Kod: [Zaznacz]

imp userid=gabinet@XE file=c:\expdat.dmp log=c:\import.log ignore=y buffer=500000 fromuser=gabinet touser=gabinet
Następnie instaluję klienta 32 bit 10g i someda. Konfiguruje dostęp do bazy przez someda, podgrywam licencje i robię aktualizację bazy do wersji someda. Przy aktualizacji wywala błędy z kompilacją i na końcu ten z DSWD. Po uruchomieniu someda wszystko się importuje i działa. Jak uruchamiam aktualizację jeszcze raz to na koniec wywala tylko błąd z DSWD, żadnego innego nie ma.

[09061303]

1. Nie wiem czy akurat to może powodować jakiś błąd, ale zainstalowałbym klienta 32bit i później dopiero tworzył użytkownika, przestrzenie i robił impa za pomocą impa z klienta 32bit. Ewentualnie klient przed samym impem po założeniu przestrzeni i użytkownika
Nawiasem mówiąc daj przy tworzeniu użytkownika gabinet wreszcie to uprawnienie do DBMS_ALERT, może zniknie część ostrzeżeń.
2. Sprawdź co się dzieje z tym DSWD na bazie pierwotnej, przed eksportem dumpa. Może tam już jest coś zdublowane lub baza jest jakoś uszkodzona (uszkodzona może działać i nie pokazywać żadnych problemów do momentu np defragmentacji przy przenoszeniu).

[Sorn]

@BarOr tak jak napisał @09061303, sprawdź czy na bazie źródłowej jest tabela dswd. Możesz też na niej wykonać moje zapytanie i daj znać jaki jest wynik. Łączysz się sqlplus gabinet@xe ?
Wklej nam jeszcze komendę jaką wykonujesz do eksportu. Proponuję zrobić ci exp jako gabinet z lini komend
exp gabinet@xe buffer=500000 file=<sciezka> log=<sciezka>

[BartOr]

OK, spróbuje jeszcze wykorzystać wasze podpowiedzi i dam znać.

[BartOr]

Ok więc zrobiłem wszystko zgodnie z waszymi wskazówkami. To samo z tym DSWD... Sprawdziłem na bazie źródłowej i na to samo zapytanie dostałem odpowiedź "no rows selected".

[andy83]

rozumiem że na nowej bazie zapytanie też zwraca 0 wyników ?
jeśli tak to sprawdź coś takiego :

SELECT *
FROM user_sequences where sequence_name ='ID_DSWD'

[BartOr]

Ok jest inaczej
Na starej bazie na 10xe zwraca "no rows selected" na nowej na 11xe teraz zwraca:

Kod: [Zaznacz]

         ID   COUNT(*)
---------   -----------
   65355   2

Zrobiłem aktualizację do najnowszej wersji, oczywiście na końcu ten sam błąd z DSWD, a przy próbie włączenia programu i aktualizacji słownika procedur i programów terapeutycznych dostaje:

Kod: [Zaznacz]

Błąd w dostępie do tabeli PRPT.DB
@andy83 Na twoje zapytanie dostaję to co w załączniku.

[Sorn]

Ok więc zrobiłem wszystko zgodnie z waszymi wskazówkami. To samo z tym DSWD... Sprawdziłem na bazie źródłowej i na to samo zapytanie dostałem odpowiedź "no rows selected".

Czyli na bazie źródłowej masz poprawnie.
Wykonałeś to zapytanie na 11XE przed aktualizacją?
Też miałeś wynik no rows selected? Jeżeli tak to aktualizacja Ci coś psuje.

[BartOr]

Nie, przed czy po aktualizacji na nowej bazie dostaję taką odpowiedź jak w poście wyżej.

[Sorn]

W takim razie import idzie źle.
Export robisz jakimś narzędziem Kamsoftu czy z linii poleceń?

[BartOr]

Export z 10XE zrobiłem przez exp gabinet@xe file=ścieżka log=ścieżka buffer=500000, import na 11XE zrobiłem przez imp gabinet@XE file=ścieżka log=ścieżka buffer=500000.

Może to jest spowodowane tym, że export robię na wersji która korzystała jeszcze z BDE(2015.3.0.4) a import na wersji która nie korzysta z BDE(2015.3.1.0) ? Czy to nie ma znaczenia ?