Tag: oracle

Posted on

Oracle adatbázis séma gyors törlése

Le akartam törölni pár nagyobb sémát Oracle alatt, aminek az lett az eredménye, hogy 20 órát futott a DROP USER… Kis olvasgatás után az körvonalazódott, hogy ezt a funkciót nem sikerült jól implementálni, ezért inkább töröljek kézzel mindent, és csak a végén töröljem a már üres sémákat… Nagy nehezen kiizzadtam magamból a lenti scriptet, ami működik is, de mivel az impdb implementációja sem sikerült teljesen ezért a végső megoldás az lett, hogy el kell dobni a teljes adatbázist, és újra kell gyártani nulláról… De ha már megírtam, akkor elmentem, hátha még jól jöhet a későbbiekben…

BEGIN
  FOR r1 IN ( SELECT 'DROP ' || object_type || ' ' || owner || '.' || object_name || DECODE ( object_type, 'TABLE', ' CASCADE CONSTRAINTS PURGE' ) AS v_sql
               FROM all_objects
               WHERE owner in ('SCHEMA1', 'SCHEMA2') AND 
                object_type IN ( 'TABLE', 'VIEW', 'PACKAGE', 'TYPE', 'PROCEDURE', 'FUNCTION', 'TRIGGER', 'SEQUENCE' ) 
                ORDER BY object_type, object_name ) LOOP 
    BEGIN 
     EXECUTE IMMEDIATE r1.v_sql; exception when others then null; 
    END; 
   END LOOP; 
  END; 
/ 

DROP USER CUSTOMER SCHEMA1 CASCADE;
DROP USER CUSTOMER SCHEMA2 CASCADE;
Posted on

Oracle 11g lejáró jelszavak és account lockout

A napokban kaptam egy hibaüzenetet a szokásos oracle login-nál, hogy a jelszavam hamarosan lejár… Mint kiderült az Oracle-nál a 11-es verzióban valakinek jó ötletnek tűnt, hogy egy adatbázisnál alapértelmezett beállítás az, ha lejárnak a jelszavak. Szerintem ez egy nagyon rossz ötlet, ami elég sok komplikációt okozott, ami aztán rengeteg blog és dokumentáció olvasásához vezetett (+1 db restore-hoz). Ezért gyorsan le is írom mire jutottam:

Azt, hogy egy oracle felhasználóra milyen jelszó lejárati/kitiltási beállítások vonatkoznak a felhasználó profile beállítása írja le. Hogy milyen profile tartozik az adott felhasználóhoz, azt az alábbi select mondja meg:

select profile from DBA_USERS where username = 'DETDB';

Ha megvan a profile (jó esetben DEFAULT) akkor annak a beállításait lekérdezhetjük az alábbi módon:

select resource_name,limit from dba_profiles where profile='DEFAULT';

Itt mindennek UNLIMITED-nek kellene lenni, kivéve a PASSWORD_VERIFY_FUNCTION változónak, mert annak NULL

Ha valaki sql-ből szeretné ezt állítani, akkor:

alter profile default limit password_life_time unlimited;

De a beállítások elérhetőek az Oracle Enterprise Managerben is: Server->Profiles->Default->Edit->Password->Expire in->Unlimited

(Oracle EM indítása (shell, oracle user): emctl start dbconsole)

Ha már megtörtént a baj (lejárt a jelszó), akkor az alábbit kell tenni:

 ALTER USER DETDB IDENTIFIED BY ******;
 ALTER USER DETDB ACCOUNT UNLOCK;

Ez megváltoztatja a felhasználó jelszavát (ezáltal újra resetelődik a lejárati idő) és visszaengedi a felhasználót. Célszerű a limitek módosítása után ezt megtenni, akkor többet nem kell vele foglalkozni.

Ha ezután sem tudunk belépni, akkor érdemes megvizsgálni azokat a felhasználókat akikkel gond van:

SELECT username, account_status, created, lock_date, expiry_date
 FROM dba_users
 WHERE account_status != 'OPEN';

Ha a felhasználónkat (mondjuk a jelszóváltoztatás után) folyamatosan zárolják a rossz jelszóval történő próbálkozások miatt, akkor jó lenne tudni, hogy ki és honnan. Ezt alapból nem tudjuk meg, ehhez engedélyezni kell a bejelentkezési események auditálását…

AUDIT network BY ACCESS;

Unlockoljuk a felhasználót, és várjuk a csodát (a 1017 return kóddal záródó login próbálkozásokat)

SELECT username,userhost,returncode, t.TIMESTAMP
 FROM dba_audit_session t
 WHERE username='DETDB' and returncode='1017'
 ORDER BY sessionid DESC;

A listában látható host-okon kell megváltoztatni a jelszót, és egy ideig megint minden jó lesz…

 

 

Posted on

Oracle 11g 64 bit telepítése ubuntu 12.04 64 bit alá

Az Oracle céget és piacvezető alkalmazásukat elég jól jellemzi, hogy az ubuntu és minden más normális linux disztribúció támogatása kimerül abban, hogy tedd redhat-ra mert az a supportált. Oracle adatbázis miatt redhat-et telepíteni pedig több mint nevetséges.

Az ubuntura történő telepítés nem is olyan bonyolult, csak rá kell jönni a telepítő (és a borzasztó oracle telepítést végző script halom) működésére.

A telepítő két dolgot csinál valójában:

  1. kimásolja az oracle fájlokat
  2. sok make fájlal, és elképzelhetetlenül sok (és értelmetlen) változó segítségével lefordítja a bináris dolgokat

Az első lépésen viszonylag könnyen felül lehet emelkedni, a neten megvan hozzá minden, én csak kigyűjtöttem egy helyre.

Kell egy kevés dependencia, hogy egyáltalán elinduljon a telepítés:

sudo apt-get install ksh less lesstif2 lesstif2-dev lib32z1 libaio1 libaio-dev \
libc6-dev libc6-dev-i386 libc6-i386 libelf-dev libltdl-dev libmotif4 \
libodbcinstq4-1 libodbcinstq4-1:i386 libpth-dev libpthread-stubs0 \
libpthread-stubs0-dev lsb-cxx make openssh-server pdksh rlwrap rpm \
sysstat unixodbc unixodbc-dev unzip x11-utils zlibc gcc-multilib \
ia32-libs libstdc++5 libstdc++5:i386

Egy két extra link, hogy minden ott legyen, ahol a telepítő keresi:

sudo ln -s /usr/bin/basename /bin/basename
sudo ln -sf /bin/bash /bin/sh
sudo ln -s /usr/bin/rpm /bin/rpm
sudo ln -s /usr/bin/awk /bin/awk
sudo mkdir /usr/lib64
sudo ln -s /usr/lib/x86_64-linux-gnu/libc_nonshared.a /usr/lib64/
sudo ln -s /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a /usr/lib64/
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib64/
sudo ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib64
sudo ln -s /usr/lib/i386-linux-gnu/libpthread_nonshared.a /usr/lib/libpthread_nonshared.a
sudo ln -s /bin/lib/libgcc_s.so.1 /lib/libgcc_s.so
sudo ln -s /usr/lib/libstdc++.so.6.0.13 /usr/lib/libstdc++.so.5

Egy user, és pár group a telepítőnek, és az oracle példánynak:

 sudo groupadd oinstall
sudo groupadd dba
sudo groupadd nobody
sudo useradd -m oracle -g oinstall -G dba
sudo passwd oracle

Kell még egy pár kernel paraméter:

sudo nano /etc/sysctl.conf

Ide az alábbi dolgokat kell felvenni:

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000

Ha a módosításokkal megvagyunk, olvastassuk fel újra a kernelparamétereket:

sudo /sbin/sysctl -p

A limits-eket is érdemes módosítani:

sudo nano /etc/security/limits.conf

ide fel kell még venni az alábbi sorokat:

* soft nproc 2047
* hard nproc 16384
* soft nofile 1024
* hard nofile 65536

És kell még egy ál-redhat release is, hogy a telepítő megnyugodjon:

sudo nano /etc/redhat-release

A fájl tartalma pedig:

Red Hat Enterprise Linux AS release 3 (Taroon)

Ha mindent default módon telepítünk, akkor érdemes még felvenni, az alábbi környezeti változókat, hogy az életünk könnyebb legyen már a telepítés alatt is:

#oracle exports
export ORACLE_BASE=/home/oracle
export ORACLE_HOME=$ORACLE_BASE/app/oracle/product/11.2.0/dbhome_1
export ORACLE_SID=orcl11
export PATH=$PATH:$ORACLE_HOME/bin

Ha ezzel megvagyunk, akkor jöhet a telepítő kitömörítése, és indítása (oracle userként).

xhost +
sudo su oracle
~/oracle_install/runInstaller

A fájlok másolása ha nem rontottunk el semmit, akkor hiba nélkül megtörténik, az érdekes rész ezután jön. Amikor elkezd fordítani az oracle, jó eséllyel látunk majd egy két hibát. Gondolom meg kell indokolni Oracle-nál, hogy mire kell azt a nagyon sok support költséget fizetni (hogy nem normális telepítő írására, az biztos). A hibák az alábbi főbb problémákra vezethetőek vissza:

  1. Ubuntu alatt a gcc picit szigorúbban fordít, és meg kell enyhíteni a lelkét, amin a „-Wl,–no-as-needed” paraéterpáros általában szokott segíteni.
  2. Hiányoznak a fordításhoz referenciák, amit a gcc általában –l(lib) formában kap meg.

Itt fontos megjegyezni, hogy a –lagtsh az valójában libagtsh.so-t jelent, azt érdemes keresni. Másik hasznos utasítás az nm parancs, aminek a segítségével megnézhetjük, hogy egy adott függvény, amit épp a make nem talál, milyen so fájlokban van benne. Pl:

nm -A $ORACLE_HOME/lib/*.so | grep procr_get_ctx

Ahol U van, ott az so fájl használja a szolgáltatást, ahol T ott implementálva van.

A neten sok problémára van megoldás, de nem mindre (én kettőre nem találtam). A tapasztalatom szerint ilyen esetekben érdemesebb picit beleásni a dolgokba, és megérteni, mit és miért csinálunk, mert az az esetek nagy részében célravezetőbb mint mindenféle misztikus sed-et, és egyéb utasításokat kiadni, hátha valami működik.

Az részletes fordítás alatt jelentkező (make) hibákat az alábbi módon érdemes nézni:

tail -f $ORACLE_HOME/install/make.log

Vegyük sorra, hogy nálam milyen problémák adódtak, és mi volt a megoldásuk:

– libagtsh.so: undefined reference to `nnfyboot’ in make: rdbms/lib/dg4odbc]

Ez egy elég ravasz hiba, a probléma az, hogy nincs még meg az a fájl, ami a fordításhoz szükséges. A megoldást az internet szállítja: fordítsunk magunknak egyet:

ln -s $ORACLE_HOME/lib/libclient11.a $ORACLE_HOME/lib/libagtsh.a
$ORACLE_HOME/bin/genagtsh $ORACLE_HOME/lib/libagtsh.so 1.0

 

– libnnz11.so: could not read symbols: Invalid operation /sysman/lib/ins_emagent.mk

Kis keresgetés után lehet látni, hogy a hívás a $ORACLE_HOME/sysman/lib/ins_emagent.mk fájlból indul, és egy olyan szolgáltatásra hivatkozik, ami a libnnz11.so-ben van benne. Ezt pótoljuk oly módon, hogy a dependenciát is kapja meg meg a gcc:

$ORACLE_HOME/sysman/lib/ins_emagent.mk

régi:

$(MK_EMAGENT_NMECTL)

új:

$(MK_EMAGENT_NMECTL) -lnnz11

– genorasdksh: Failed to link liborasdk.so.11.1

Szintén egy dependencia probléma, amikor a teljes oracle sdk-t próbálja lefordítani, akkor nagyon sok dolgot nem talál hirtelen. A megoldás hasonló az előző esethez, a megnézzük a szolgáltatásokat, azonnal feltűnik, hogy a libagtsh.so és a  liborasdkbase.so hiányzik neki nagyon. Értessük meg vele:

$ORACLE_HOME/bin/genorasdksh

Régi:

OLIBS="$LCLIENT $LSQL $LVSN $LNETWORK $LCLIENT \
$LCOMMON $LGENERIC $LMM $XAONDY $LNETWORK $LCLIENT $LCOMMON \
$LGENERIC $LTRACE $LNNET_ON $LSKGXP"

Új:

OLIBS="$LCLIENT $LSQL $LVSN $LNETWORK $LCLIENT \
$LCOMMON $LGENERIC $LMM $XAONDY $LNETWORK $LCLIENT $LCOMMON \
$LGENERIC $LTRACE $LNNET_ON $LSKGXP -lagtsh -lorasdkbase"

– getcrshome – libhashgen11 missing reference

Itt ha megnézzük, akkor az a szolgáltatás amit keres, megtalálható az .so fájlban, ami meg is van adva. Itt a hiányzó extra paraméter a gond. Kis keresgetés után erre is rá lehet találni. A megoldás:

$ORACLE_HOME/srvm/lib/env_srvm.mk

Régi:

LDOBJSZ=-m64

Új:

LDOBJSZ=-m64 -Wl,--no-as-needed

És láss csodát, hiba nélkül működik az oracle ubuntun. Szerencsére csak az oracle build script-jeit láttam, a forrását nem, de ha azt is olyanok írták, mint ezeket a scripteket, akkor jobb is ez így…

Posted on

Oracle XE too many connection

Ha valaki Oracle XE alatt too many connections hibaüzenetet kap, nincs más teendő csak megemelni a lehetséges kapcsolatok számát. Alapesetben ez 40, amit ki is írathatunk:

show parameter process

És megemelni 100-ra pedig így lehet:
alter system set processes = 100 scope=spfile;

Ezek után már csak egy oracle újraindítást kell tennünk és siker.

Posted on

Oracle lockok kezelése

A lock-ok listája:

SELECT l.inst_id,SUBSTR(L.ORACLE_USERNAME,1,8) ORA_USER, SUBSTR(L.SESSION_ID,1,3) SID,
S.serial#,
SUBSTR(O.OWNER||'.'||O.OBJECT_NAME,1,40) OBJECT, P.SPID OS_PID,
DECODE(L.LOCKED_MODE, 0,'NONE',
1,'NULL',
2,'ROW SHARE',
3,'ROW EXCLUSIVE',
4,'SHARE',
5,'SHARE ROW EXCLUSIVE',
6,'EXCLUSIVE',
NULL) LOCK_MODE
FROM sys.GV_$LOCKED_OBJECT L, DBA_OBJECTS O, sys.GV_$SESSION S, sys.GV_$PROCESS P
WHERE L.OBJECT_ID = O.OBJECT_ID
and l.inst_id = s.inst_id
AND L.SESSION_ID = S.SID
and s.inst_id = p.inst_id
AND S.PADDR = P.ADDR(+)
order by l.inst_id;

Lock-ok eltávolítása:

ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;

Ahol értelemszerűen a sid,serial# az előző selectből jönnek.

Posted on

Visio 2007

Van amikor az ember dolgozni szeretne, és azon kapja magát, hogy a szoftver amit használ ebben nem igazán támogatja.
Így jártam én a Microsoft Visio 2007-el, amikor adatbázist szerettem volna tervezni.
Természetesen a help, hibátlan magyarsággal, rövid és velős választ ad:


A Microsoft Office Visio programban Adatbázismodell-diagram sablonját használó személyek gyakori kérdése, hogy Mi történt a Létrehozás és a Frissítés parancsokkal?"
Röviden összefoglalva annyi, hogy a Létrehozás és a Frissítés parancs nem érhető el a Microsoft Office Visio 2003 Standard és Professional kiadásaiban vagy a Microsoft Office Visio 2007 alkalmazásban.
Az adatbázis-modellező szolgáltatások teljes körét, beleértve a Létrehozás és Frissítés parancsot is, a Microsoft Office Visio vállalati építészek számára készült verziójában találhatja meg. A Visio vállalati építészek számára az MSDN Premium Subscription része, mely a Microsoft Visual Studio Professional és a Visual Studio Team System szerepalapú kiadásaival érhető el.

Ezen a ponton látszik, hogy a help fordítói komolyan vették a munkát. Sebaj.
Tehát aki adatbázis modellből adatbázist akar generálni, annak szüksége van vállalatépítészeti visiora.
Mivel én komoly vállalatépítésznek gondolom magam, beszereztem egy Visio for Enterprise Architecht-et biztos ami biztos.
Nagy rutinnal a telepítő azt mondta, hogy Visual Studio nélkül ez nem telepíthető.
Szerintem meg igen, aki nem hiszi írja bele a registrybe az alábbi sort, és már működik is.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTD]
"ProductDir"="."

Egyébként a 2007-es Visio teljesen ugyanaz az engine mint a 2005-ös EA edition. Picit módosítottak a guin, eladták ugyanazt, mégegyszer, és még db-t sem lehet vele generálni…
Ha valaki mindkettőt felrakja (akárcsak én), akkor amint a másik verziót indítjuk kedvességből kapunk 10 perc setup-ot…
MS