- zeller blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Le van írva szépen, hogy ez így megy. Elolvastad az Upgrade/Migration guide-ot?
You must upgrade from Oracle Database Express Edition to Oracle Database Enterprise Edition, and then upgrade to the current Oracle Database release.
Oracle Database Express Edition (Oracle Database XE) is an entry-level edition of Oracle Database.
To upgrade Oracle Database 11g release 2 (11.2) Express Edition (Oracle Database XE) to Oracle Database 12c Release 2 or later releases, you must first upgrade from Oracle Database XE to Oracle Database 12c Release 1 (12.1.0.2) Enterprise Edition, and then upgrade to a later Oracle Database Enterprise Edition release.
- A hozzászóláshoz be kell jelentkezni
El... Hogy a nadrág rohadjon rájuk... Ebben még a 11/12 vonalról hablatyolnak, feltételeztem, hogy a 18XE-ről már van direkt path a 18SE-re, de ezek szerint nincs - az expdb meg ugye azzal indítana, hogy néhány dolgot kreálna az adatbázisban - ahol viszont nincs hely, ergo expdb sem megy le.
- A hozzászóláshoz be kell jelentkezni
Oracle-lel már nagyon rég volt dolgom, úgyhogy ezt most csak ötlet szinten írom, de mennyire futottatok túl a kvótán? Teljesen, vagy csak annyira, amennyi a teljes DB exportálásához kéne? Mert ha az utóbbi, akkor lehet, hogy darabokban ki tudja pumpálni a dumpot, csak fel kell mérni minden export előtt ESTIMATE_ONLY
-val, hogy ami expdp
parancsot szeretnél futtatni, annak még lesz hely, vagy sem.
- A hozzászóláshoz be kell jelentkezni
simán expdp/impdp-nek működnie kellene, mi a hibaüzenet pontosan, meg a command,amit futtattál? nem rémlik, hogy a datapump-nak kellene bármi extra objektum az adatbázisban, egy directory object-en kívül.
vagy lehet még rman full backup és restore,de az a nehezebb, szerintem.
fyi:nincs olyan,hogy enterprise-ból downgrade se-re. az mindkettő egy verzió, csak más licenc.
- A hozzászóláshoz be kell jelentkezni
Az expdb-be sys as sysdba akartam bemenni:
Connected to: Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production
ORA-31626: job does not exist
ORA-31633: unable to create master table "SYS.SYS_EXPORT_SCHEMA_05"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 1142
ORA-12954: The request exceeds the maximum allowed database size of 12 GB.
ORA-06512: at "SYS.KUPV$FT", line 1035
ORA-06512: at "SYS.KUPV$FT", line 1023
Marha rég csináltam ilyesmit (tízzel korábban, és nem XE-jellegű motyóval), úgyhogy lehet,hogy én vagyok a hunyó...
Az EE/SE érdekes kérdés: ha az installernek oracle.install.db.InstallEdition=SE lett megadva, akkor kaptam a képembe a dbua-tól a topicindítóban lévő hibát, ha oracle.install.db.InstallEdition=EE, akkor meg nem - viszont nem engedtem végig, mert előbb mindenképp kéne egy hidegmentés a DB-fájlokról.
Az is jó kérdés, hogy mit kell 12GiB alá letornázni, mert nekem ennek a selectnek a kimenetéből nem világos, hogy hol fogytunk el:
select df.tablespace_name "Tablespace",
totalusedspace "Used MB",
(df.totalspace - tu.totalusedspace) "Free MB",
df.totalspace "Total MB",
round(100 * ( (df.totalspace - tu.totalusedspace)/ df.totalspace))
"Pct. Free"
from
(select tablespace_name,
round(sum(bytes) / 1048576) TotalSpace
from dba_data_files
group by tablespace_name) df,
(select round(sum(bytes)/(1024*1024)) totalusedspace, tablespace_name
from dba_segments
group by tablespace_name) tu
where df.tablespace_name = tu.tablespace_name ;
- A hozzászóláshoz be kell jelentkezni
Őszintén szólva, XE -> nonXE upgrade-et még sosem csináltam, de nem gondolnám, hogy akkora különbségek lennének. Elképzelhető, hogy beleraktak az új verziókba valami ellenőrzést, ami nézi, hogy melyik option lett választva, mert a dbua olyan feature-t használna, ami nincs SE-ben (mondjuk ezen meglepődnék, lévén, hogy Oracle-ről van szó). Ez ennyiből sajnos nem derül ki.
De nem értem, ha van EE licenc, akkor miért akarnál egyáltalán SE-t?
Az expdp parancsot még mindig nem írtad le.
Az, hogy mi a select, amit lefutattál, az sokat nem segít, az eredmény viszont talán tudna.
Az,hogy telinek érzékeli több mindentől is függ, lehet például, hogy GB-ban nincs annyi, de ha új extent-et allokálna, akkor már túllépné és ezért kapod a hibaüzenet.
- A hozzászóláshoz be kell jelentkezni
Van standard 2 licenc, viszont az XE-ről standard-ra csak dump/restore lenne, az viszont nem ment, mert a DB fullon volt. Telepítettem EE-t ( ugyanabból a zip-ből ment a telepítés, csak oracle.install.db.InstallEdition=EE volt oracle.install.db.InstallEdition=SE helyett), abba szépen bevitte a dbua az XE-s adatbázist. Az export egy "szimpla" expdp \"SYS as SYSDBA\" FULL=Y lett volna - ez az EE-vel szépen lement.
Most jön az, hogy az EE-s dumpot egy másik SE-be betolni - ha nincs tele invalid objektumokkal az így összerakott új DB, akkor készen vagyunk - ha meg igen, akkor az EE mellé felrakok egy SE-t, az SE-ben lévő expdb-vel kipumpálom az adatokat ismét, és azt húzom be egy SE-be.
A méret témához a select kimenete - bár most már nem igazán érdekes - ha rajtam múlik, a környékre sem fog senki XE-t hozni :-D (A Total a SYSAUX-ot beleszámolva, az UNDOTBS1-et meg a SYSTEM-et kivéve mondjuk "stimmelhet" a 12G max.-ra...):
Tablespace Used MB Free MB Total MB Pct. Free
------------------------------ ---------- ---------- ---------- ----------
SYSTEM 1248 112 1360 8
SYSAUX 1453 167 1620 10
UNDOTBS1 139 6301 6440 98
USERS 0 5 5 100
ALMA_PARTITIONED_DATA 2895 3105 6000 52
ALMA_INDEX 1843 1207 3050 40
ALMA_DATA 1372 528 1900 28
7 rows selected.
- A hozzászóláshoz be kell jelentkezni
Így már tényleg nem érdekes,a lényeg, hogy sikerült. Viszont nekem még mindig nem tiszta, hogy akkor hogy sikerült áthidalni a korábban említett hibát? Hátha segít másnak is a jövőben.
- A hozzászóláshoz be kell jelentkezni
Röviden: XE, 12G korlát elérve, expdb nem megy, egyébként is cél az SE-re migrálás. Regisztrált userként (support azonosítóval) letöltött 18-as zip-et (V978967-01.zip) került telepítésre, oracle.install.db.InstallEdition=EE paraméterrel, a https://oracle-base.com/articles/18c/upgrading-to-18c illetve https://oracle-base.com/articles/18c/oracle-db-18c-installation-on-orac… alapján.
Ez után a futó XE mellett ORACLE_HOME és PATH beállítva a 18c-nek megfelelőre, majd dbua indít, végigkattintgat, örül. A két rpm-ből felment indítóscript (etc/init.d/ alatt) elejére egy exit 0, expdb az EE-ből, ami most megy befelé egy másik gépen lévő "szűz" SE-be. Ha ezzel nem lesz gond, akkor az eredeti gépen letakarítom a két rpm-et - a yum erase _előtt_ némi takarítással/trükkel, hogy az uninstall scriptek véletlenül se csináljanak baromságot (sajnos van rá esély...), felmegy az SE ide is, betöltöm a dump-ot, lezúzom az EE-t mindenestől, és ennyivel ennyi.
Ha az EE-s dump nem jó az SE-nek, akkor az SE telepítése után az SE-ben lévő expdb-vel csináok dumpot, és azt töltöm be az SE-be.
- A hozzászóláshoz be kell jelentkezni
Na most küldtem el az orákulumot meg a nőnemű felmenőit mindenestől oda, ahova nem kívánnak menni... "ORA-00439: feature not enabled: Partitioning." Vagy inkább: ORA-$$$$ Insert credit card to continue." Szóval most jöhet a fejlesztővel történő asztalboro... izé, egyeztetés, hogy ha már ki merte jelenteni, hogy a SE2 jó, akkor ugyan, legyen oly kedves, és kapj... kapjunk olyan eszközt, amivel a partícionált táblák eliminálhatóak...
- A hozzászóláshoz be kell jelentkezni
12 gigás adatbázisnal mit szineztek particionalassal meg egyéb szarsagokkal? Befér memóriába az egész!
- A hozzászóláshoz be kell jelentkezni
És az a 12GiB expdp-vel lett 2.6-2.7GiB... Szóval vannak érdekes dolgok, na... Lehet persze, hogy az autoextend-es undotbs a hunyó a maga 6gigás méretével, de aki XE-nél autoextend-et állít be... Nos, az szerintem bármilyen más galádságra is képes :-P Valamikor még megpróbálom az EE-ből kinyert dump-ot berámolni egy XE-be, de már csak "hobbiból" :)
- A hozzászóláshoz be kell jelentkezni
azért van XE-nél autoextend (meg auto undo managerent), mert tipikusan olyan embereknek van, ahol nincs külön DBA vagy sysadmin és ne kelljen kézzel állandóan új datafile-okat hozzáadni, ha elfogyna hely (persze lehetett volna előre megcsinálni, fix méretűre, de ez már másik kérdés)
- A hozzászóláshoz be kell jelentkezni
Jó dolog az autoextend, csak ha a teljes user data méret korlátozott, akkor azért nem igazán... Hiába van külön tablespace, ha az egyik a másik rovására fel tudja zabálni a területet, a következmény sokkalta nagyobb szívás lesz, mintha valamelyik táblatérben fogyna el a hely.
- A hozzászóláshoz be kell jelentkezni
mármint a ti saját tábláitok vannak particionálva? miért?
- A hozzászóláshoz be kell jelentkezni
Azt csak az alkalmazás fejlesztője tudja, hogy miért...
- A hozzászóláshoz be kell jelentkezni
(Szerintem ez tipikus üzemeltetési kérdés... A derék programozó nem is kellene ismerjen olyen fogalmakat, mint 'táblatér', meg 'partícionálás'... Kb az 'index', a 'trigger' meg az 'idegen kulcs' az a szint, ami még rá tartozik.)
- A hozzászóláshoz be kell jelentkezni
Mondjuk a "DELETE FROM sales partition (dec98);" -hoz, vagy épp az "ALTER TABLE sales DROP PARTITION dec98 UPDATE INDEXES;"-hez mit szólsz? Ezek hasznosak tudnak lenni, ha olyan adataid vannak, ahol - a példáknál maradva - havi adatokat kell a DB-ből törölni, és ezek a havi adatok havonta egy új partícióba esnek be.
- A hozzászóláshoz be kell jelentkezni
Hát hasznosnak hasznos, csak éppen egy implementációs részlet abúzálása... Ilyenkor szokott megérkezni az adatbázisgazda, aki közli, hogy a diszkek formáját, színét és kihasználtságát elemezve másféle partícionálást választott. (Ja és mellékesen a programozó kezdje el vizsgálni, hogy (mivel az Oracle drága) MSSQL-re vagy DB2-re tudna-e könnyebben átállni. Bár ez mindegy, úgyis MySql lesz.)
- A hozzászóláshoz be kell jelentkezni
Tábla partícionálása, ember... :-) A DBA-nak nem az a dolga, hogy az architect és a fejlesztő helyett átdolgozza az alap adatstruktúrát, megmondja, hogy milyen platformot használjanak, hanem az, hogy a sémageneráló scriptet lefuttassa, biztosítsa a kért táblateret adott paraméterekkel, megoldja a mentést és a többi, és a többi...
Ja, és pl. MariaDB-ben is van partícionálás :-P És nagyon jó dolog. Ott is. Bár butább, mint az Oracle-ben.
- A hozzászóláshoz be kell jelentkezni