Witam KS-SOMED jest zainstalowane na "serwerze" Windows XP 32bit. Problem pojawił się wczoraj podczas rejestracji nowego pacjenta wyrzuca błąd z informacją o braku miejsca w bazie. Baza zajmuje więcej niż 4GB i jedyną możliwością jest migracja bazy do Oracle 11g XE gdzie limit bazy wynosi 11GB.
Czy ktoś przeprowadzał taką migrację? Może ktoś posiada instrukcję jak to wykonać?
Z góry dziękuję za pomoc.
P.S. Jestem "świeżakiem" w tym systemie.
Witam
Dołączam się do prośby i również proszę o przesłanie instrukcji.
Z góry serdecznie dziękuję i pozdrawiam
Witam
Dołączam się do prośby i również proszę o przesłanie instrukcji.
Z góry serdecznie dziękuję i pozdrawiam
Wysłałem ci info w prywatnej wiadomości.
Próbowałem wykonać prodecurę opisaną przez Oracle (expdp oraz impdp łącząc się z bazą poprzez sqlplus jako sys@XE as sysdba) ale nie udało się.Gdybyś kupił bazę danych w wersji płatnej to podobno migracja z xe jest bezbolesna ( ale działa tylko w górę).
Przy okazji , ktoś może podpowie jak dokladnie sprawdzić ile zajmuje baza. ;DMoże pomoże
Od grudnia ceny poszły ok 3 krotnie w górę :/
To już nie będzie wersji Oracle z produktami Ks w niższej cenie?
Dziwnie wysoki skok cenowy, $ nie poszedł przecież tak bardzo w górę....
Próbowałem wykonać prodecurę opisaną przez Oracle (expdp oraz impdp łącząc się z bazą poprzez sqlplus jako sys@XE as sysdba) ale nie udało się.Spróbuj klasycznego exp/imp.
Czy migracja jest robiona za pomocą exp/imp czy expdp/impdp - nie ma różnicy. Kwestia jest po stronie odpowiedniej konfiguracji i tyle.Próbowałem wykonać prodecurę opisaną przez Oracle (expdp oraz impdp łącząc się z bazą poprzez sqlplus jako sys@XE as sysdba) ale nie udało się.Spróbuj klasycznego exp/imp.
To teraz by się przydał wróżbita do interpretacji, bo na działającej bazie wyskoczyło mi 3915 bytes, a na pustej jaką sobie roboczo na drugim kompie zrobiłem 1345.Przy okazji , ktoś może podpowie jak dokladnie sprawdzić ile zajmuje baza. ;DMoże pomoże
http://sumedha.blogspot.com/2009/10/how-to-check-size-of-oracle-database.html
To już nie będzie wersji Oracle z produktami Ks w niższej cenie?
Dziwnie wysoki skok cenowy, $ nie poszedł przecież tak bardzo w górę....
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
zawsze klienta 32 bitowego.Teraz już chyba nie, nie ma BDE to i na 64b powinno działać. Ktoś przetestuje? :D
Żeby była jasność. Pierwsze okienko służy do weryfikacji. Podajemy tu hasło, aby pozwolić w następnym okienku na zmianę tego hasła. Jest to zabezpieczenie przed przypadkowym uszkodzeniem hasła przez osobę niezorientowaną. Na tym etapie nie testujemy jednak hasła w bazie a sprawdzamy je z zapisanym w pliku ini lub w rejestrach. Jeśli więc mieliśmy zamieszanie z licencją może być tak, że hasło w rejestrach zakodowane było innym kluczem niż też wpisujemy. Stąd np. komunikat o niepoprawnym haśle. Który wcale nie sugeruje, że hasło bazie jest inne! Jeśli tak mamy, najlepiej usunąć wpis z rejestrów i z pliku ini z użytkownikiem i hasłem i wpisać je od nowa. Wówczas na początek należy wpisać hasło GM, które znów nie musi odpowiadać rzeczywistości, program je po prostu wymaga na starcie.
Później pojawia się drugie okienko i tu już należy wskazać użytkownika i hasło takie, jakie mamy w bazie.
To samo dotyczy hasła systemowego. I znów jeśli są problemy należy hasła wyciąć i wpisać od nowa i z rejestrów i z pliku ini. I wówczas na starcie mamy użytkownika SYSDBA i hasło masterkey, które oczywiście nie musi odpowiadać rzeczywistości. Należy je jednak wpisać i w drugim okienku wpisać właściwego użytkownika i hasło
@09061303Ale klient Oracle XE czy klient Oracle do pełnej bazy - wiem, że jest takie narzędzie w kliencie do pełnej bazy, ale nie wiem czy zgodnie z licencją możesz takowego używać w przypadku XE.
Tak jak pisałem takie narzędzie jest w kliencie Oraclowym w przypadku bazy 10 XE wystarczyło postawić serwer i było OK, w przypadku 11 XE 64 bitowej trzeba było instalować klienta żeby programem podłączyć się bazy.
Ok, powiedzmy, że uruchomiłem someda, ale ten problem w graniem pusta.ora ciągnie się dalej i nie można zaktualizować bazy z powodu tych problemów.Powtórzę się: skąd masz plik pusta.ora? I z kiedy? Ostatnio stawiałem Someda na XE pod koniec 2014 i też miałem podobny problem, pomogło wczytanie nowego pliku, który dostałem mailowo z Kamsoftu ale niestety nie mogę go znaleźć :(
CREATE TABLE KSLIC
(
LICE VARCHAR2(30),
SYST VARCHAR2(8) NOT NULL,
NROK VARCHAR2(4),
PFSY VARCHAR2(10),
SERNAZW VARCHAR2(25) NOT NULL,
ODDNAZW VARCHAR2(25),
NRKL VARCHAR2(10) NOT NULL,
SKRT VARCHAR2(40) NOT NULL,
NIPV VARCHAR2(15),
KONC VARCHAR2(50),
ILST NUMBER(5),
ILPR NUMBER(5),
IMAG NUMBER(5),
IODD NUMBER(5),
WLBZ NUMBER(5),
MODL VARCHAR2(255),
OPCJ VARCHAR2(255),
DTGN DATE NOT NULL,
DTMD DATE NOT NULL,
DTWG DATE,
DTAS DATE,
DTPL DATE,
DTZP DATE,
CZZP VARCHAR2(1),
NCRC VARCHAR2(25),
PASS VARCHAR2(40)
)/
CREATE UNIQUE INDEX KSLIC_SYROPF_I ON KSLIC(SYST, NROK, PFSY)
/
GRANT ALL ON KSLIC TO PUBLIC
/
IMP-00019: row rejected due to ORACLE error 12899
IMP-00003: ORACLE error 12899 encountered
ORA-12899: value too large for column "GABINET"."SKPR"."NAZW" (actual: 82, maximum: 80)
alter table spkr modify nazw varchar2(100);
CREATE TABLE KSLIC
(
LICE VARCHAR2(30),
SYST VARCHAR2(8) NOT NULL,
NROK VARCHAR2(4),
PFSY VARCHAR2(10),
SERNAZW VARCHAR2(25) NOT NULL,
ODDNAZW VARCHAR2(25),
NRKL VARCHAR2(10) NOT NULL,
SKRT VARCHAR2(40) NOT NULL,
NIPV VARCHAR2(15),
KONC VARCHAR2(50),
ILST NUMBER(5),
ILPR NUMBER(5),
IMAG NUMBER(5),
IODD NUMBER(5),
WLBZ NUMBER(5),
MODL VARCHAR2(255),
OPCJ VARCHAR2(255),
DTGN DATE NOT NULL,
DTMD DATE NOT NULL,
DTWG DATE,
DTAS DATE,
DTPL DATE,
DTZP DATE,
CZZP VARCHAR2(1),
NCRC VARCHAR2(25),
PASS VARCHAR2(40)
)/
CREATE UNIQUE INDEX KSLIC_SYROPF_I ON KSLIC(SYST, NROK, PFSY)
/
GRANT ALL ON KSLIC TO PUBLIC
/
SQL> @C:\sql\tabela.sql
)/
*
ERROR at line 29:
ORA-00922: missing or invalid option
GRANT ALL ON KSLIC TO PUBLIC
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL>
Błąd wykonania skryptu:
CREATE UNIQUE INDEX PK_DSWD
ON DSWD (ID )
TABLESPACE MEDIDX
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Kod: 1452
(klasa błędu: EUniError)
Błąd w dostępie do tableli PRPT.DB
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ł.
@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ę.
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;
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;
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;
imp userid=gabinet@XE file=c:\expdat.dmp log=c:\import.log ignore=y buffer=500000 fromuser=gabinet touser=gabinet
ID COUNT(*)
--------- -----------
65355 2
Błąd w dostępie do tabeli PRPT.DB
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.
Export robię z wersji 2015.3.0.4 czy coś takiego, a po imporcie instaluję wersję 2015.3.1.0 więc nim włączy się somed muszę zrobić aktualizację bazy. Po skończeniu aktualizacji wywala błąd z DSWD...To może po eskporcie nie instaluj nic, tylko weź pliki, które już masz (katalog Someda, spod którego obecnie działasz) i za ich pomocą podepnij się do nowej bazy. Ominiesz samą aktualizację. Puść wtedy test bazy i zobacz co i jak. Dopiero wtedy spróbuj zaktualizować.
(użyj expd,impd)W XE o ile się nie mylę expdp impdp nie działają.
Zapytam na forum, czy jest możliwość aby nie płacić tej kwoty i dalej pracować na Somedzie mimo, że baza jest przepełniona, czy można pozostać przy darmowej wersji Oracle?.Tzn to pytanie raczej nie wymaga odpowiedzi, bo jak się baza przepełni to zwyczajnie nie rozszerzy pliku danych i każda czynność w aplikacji skończy się błędem.
Pozdrawiam
Odnośnie typów licencji, to w przypadku kiedy nie mamy zamiaru używać oracle'a do innych celów niż współpraca z KS, to wersja ASFU wydaje się optymalna kosztowo - np. dla liczba stanowisk <10.Piszesz o ASFU terminowej czy bezterminowej?