A tesztlaborból: Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra

Címkék

Fejlesztési és tesztelési igényeket kielégítendő szükségünk van egy Oracle 10g-t futtató linuxos "szerver" gépre. Az átadási határidőig volt egy kis időm játszogatni, így arra gondoltam, hogy megvizsgálom a lehetőségeimet arra nézve, hogy milyen disztribúciókra építkezhetek. Kíváncsi voltam, hogy mely általam favorizált Linux disztrókra tudom feltelepíteni a kedvelt adatbáziskezelő rendszert. Ugyebár nem mindegy, hogy az ember olyan disztróval dolgozik ami kézreáll vagy esetleg olyannal, aminek a működése, felépítése teljesen idegen számára...
Oracle-lel mindig is csak üzemeltetői oldalról volt dolgom. Telepítettem már Sun SPARC64-re, Windows-ra, vettem részt olyan telepítésen, ahol PA-RISC-es gépen futó HP-UX-re és támogatott Linux disztribúcióra telepítettük, de unsupported Linux-ra még sosem próbáltam telepíteni. Nyilvánvaló, hogy a támogatott Linux rendszerekre (RHEL, SLES és társai) nem probléma a telepítés. Azonban vannak olyan (elsősorban anyagi) előnyei az unsupported Linux disztribúciókra való telepítésnek, ami miatt érdemes egy kicsit dolgozni. Az általam alapnak választott Linux disztró (előbb az Ubuntu 6.10 "Edgy Eft" Server majd később) az Ubuntu 7.10 "Gutsy Gibbon" Server változata lett. Arra gondoltam, hogy ha már tesztelek, akkor nem áll sokból dokumentálni. Nekem is jól jöhet később, de talán másnak is hasznos lehet, hiszen ki tudja, hogy kinek és mikor kell valami hasonlóval foglalkoznia... Na nem mintha nem lennének elérhetők az információk az internetről innen-onnan. Azonban ezek a hasznos infók eléggé elszórva találhatók meg, a nyelvük angol, néhol hiányosak, néhol túlzottan terjengősek, így a rövid, magyar nyelvű dokumentáció talán egy kicsit hiánypótló is lehet. Nézzük mire jutottam.

Az alaprendszer telepítése:
-------------------------------

A telepítést egy egyszerű PC hardveren végeztem, szervernek csak csúfolni lehetne. A gép 2 GB fizikai memóriát, 2 darab 160 GB-os SATA merevlemezt, és egy Intel Core2 E4500 @ 2.20GHz processzort tartalmaz. Az Ubuntu 7.10 Server telepítését nem nagyon részletezem. A szokásos, "csak alapvető dolgok" telepítésével kezdtem.

Filerendszer:
---------------

Ebben az esetben szoftveres RAID1 a minimális biztonság miatt:

/dev/md0 on / type ext3 (rw,errors=remount-ro)
[...]
/dev/md1 on /opt type ext3 (rw)
/dev/md2 on /var type ext3 (rw)
[...]

Nyilvánvaló, hogy több és jobb rendelkezésre álló hardver esetén az Oracle alá komolyabb diszkalrendszert lenne illendő szervezni (hardveres RAID, RAID10, telepítési file-okat és az adatbázis file-okat, redo logokat, tablespace-eket külön, stb.), de most a rendelkezésre álló hardverből és keretből próbálunk meg valamit kihozni, ami a célnak remélhetőleg meg fog felelni.

Az Oracle-t a /opt alá telepítjük, így az külön került felcsatolásra.

Swap:
-------

A 2GB-nyi RAM mellé dupla ennyi swap került beállításra.

Hálózat:
---------

A szerver hálózati csatolója statikus IP címet kapott. A szokásos beállításokat elvégezzük: DNS, default gw, stb.

Alaprendszer telepítés és beállítás után:
----------------------------------------------

Ha kész az minimális alaprendszer telepítése (tasksel-ben semmi sallangra nincs szükség), akkor álljunk neki:

apt-get update
apt-get upgrade

Az Oracle telepítéséhez szükség lesz grafikus felületre. Ezt a legegyszerűbben így állíthajuk elő:

apt-get install ubuntu-desktop

Ha kész, és a gdm elindult, lépjünk be, majd indítsunk egy gnome-terminal-t. Itt folytatjuk a telepítést és a konfigurációt.

Néhány csomagra (például rpm, alien) szükségünk lesz az Oracle telepítéséhez, hiszen nem Ubuntu-ra tervezték:

apt-get install build-essential libaio1 rpm lesstif2-dev alien

A telepítéshez és az Oracle majdani futtatásához hozzunk néhány user-t, könyvtárat, stb:

groupadd oinstall
groupadd dba
groupadd nobody
useradd -g oinstall -G dba,nobody -d /opt/oracle -s /bin/bash oracle

Adjunk jelszót az "oracle" felhasználónak:

passwd oracle

Hozzuk létre a ~ könyvtárát, állítsuk be a tulajdonost és a jogokat:

mkdir /opt/oracle
chown -R oracle:oinstall /opt/oracle
chmod -R 775 /opt/oracle

Készítsük el az "oracle" felhasználó .bashrc file-ját, amelybe vegyük fel az Oracle telepítéséhez és futtatásához használt környezeti paramétereket:

vi /opt/oracle/.bashrc

export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=$ORACLE_BASE/product/10gR2
export ORACLE_SID=szintora
export PATH=$PATH:$ORACLE_HOME/bin

Az Oracle igényeli néhány kernelparaméter finomhangolását. Szerkesszük meg a /etc/sysctl.conf-ot:

vi /etc/sysctl.conf

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

Juttassuk érvényre a változtatásokat:

/sbin/sysctl -p

Szerkesszük meg a /etc/security/limits.conf állományt:

vi /etc/security/limits.conf

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

Ezután készítsünk el néhány symlinket, mert az Oracle ott fog binárisokat és .so állományokat keresni, ahol azok valójában nincsenek:

ln -s /usr/bin/awk /bin/awk
ln -s /usr/bin/rpm /bin/rpm
ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so
ln -s /usr/bin/basename /bin/basename

Ha ezzel megvagyunk, akkor a rendszert előkészítettünk az Oracle telepítésére. Neki is kezdhetünk:

Az Oracle 10gR2 telepítése:
--------------------------------

Oracle felhasználó nevében dolgozunk.

Töltsük le megfelelő telepítőcsomagot. Ez esetünkben a Oracle Database 10g Release 2 (10.2.0.1.0) Enterprise/Standard Edition for Linux x86 csomag. Letöltés után ellenőrizzük le a checksum-ot, majd bontsuk ki a .zip archívumot:

unzip 10201_database_linux32.zip

Ha kész, indítsuk el a telepítőt:

cd /opt/oracle/database
./runInstaller -ignoreSysPrereqs

Az "-ignoreSysPrereqs" paraméterrel mondjuk meg a telepítőnek, hogy ne foglalkozzon azzal, hogy nem támogatott rendszerre telepítünk. Ha nem adjuk meg, a telepítő ki fog lépni.

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Indul a telepítő

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Az "inventory" helyének és a könyvtár írására jogosult csoportnaknak (korábban létrehoztuk) megadása

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Telepítés típusának kiválasztása

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Telepítési előfeltétekek ellenőrzése illetve a felhasználó kérésére való mellőzése (nem támogatott rendszer, mi igazoljuk, hogy minden rendben)

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
A telepítő kérdéseinek megválaszolása után készen állunk a telepítésre

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Települ a rendszer

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Adatbázis létrehozása

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Végül elkészült a telepítés

Mivel nem "superuser"-ként csináltuk a telepítést, két scriptet kell futtatnunk "root" felhasználóként:

Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
orainstRoot.sh

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
root.sh

E két script elvégzi a további, rendszerszintű file-ok (pl: /etc/oratab, stb.) telepítését.

A telepítés probléma nélkül lezajlik (az összes kép a telepítés folyamatáról megtekinthető itt és itt), azonban a telepítés után akad még egy kis dolgunk.

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Gyors teszt: tnsping <host>

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
A "dbstart" egy (afaik) termékbug miatt elsőre problémás, de könnyen segíthetünk rajta

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Szerkesszük meg a "dbstart"-ot

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Cseréljük ki a hardcoded "/ade/vikrkuma_new/oracle"-t

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
A $ORACLE_HOME értékére, azaz "/opt/oracle/product/10gR2"-ra. Az indítás ezután már nem problémás.

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
A webes felületen beléphetünk az OEM-be, azaz az Oracle Enterprise Manager-be

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
Aholis rácsodálkozhatunk az Oracle adatbáziskezelőnk működésére

 Oracle 10g (32 bit) telepítése Ubuntu 7.10 "Gutsy Gibbon"-ra
És még szép grafikonokat is láthatunk

Automatikus indítás:
------------------------

Ha a telepítés kész, akkor a /etc/oratab file-ban megadhatjunk, hogy boot időben elinduljon az adatbázisunk vagy sem. Szeretnénk. Cseréljük ki a megfelelő sorban az "N"-t "Y"-ra:

vi /etc/oratab

szintora:/opt/oracle/product/10gR2:N

helyett:

szintora:/opt/oracle/product/10gR2:Y

Az automatikus induláshoz az alábbi scriptet készítsük el:

touch /etc/init.d/oracle
chmod 755 /etc/init.d/oracle
vi /etc/init.d/oracle

#!/bin/bash

ORACLE_HOME=/opt/oracle/product/10gR2/
ORACLE_OWNR=oracle

# if the executables do not exist -- display error

if [ ! -f $ORACLE_HOME/bin/dbstart -o ! -d $ORACLE_HOME ]
then
       echo "Oracle startup: cannot start"
       exit 1
fi

# depending on parameter -- startup, shutdown, restart
# of the instance and listener or usage display

case "$1" in
   start)
       # Oracle listener and instance startup
       echo -n "Starting Oracle: "
       su - $ORACLE_OWNR -c "$ORACLE_HOME/bin/lsnrctl start"
       su - $ORACLE_OWNR -c $ORACLE_HOME/bin/dbstart
       sleep 10
       su - $ORACLE_OWNR -c "$ORACLE_HOME/bin/emctl start dbconsole"
       touch /var/lock/subsys_oracle
       echo "OK"
       ;;
   stop)
       # Oracle listener and instance shutdown
       echo -n "Shutdown Oracle: "
       su - $ORACLE_OWNR -c "$ORACLE_HOME/bin/lsnrctl stop"
       su - $ORACLE_OWNR -c $ORACLE_HOME/bin/dbshut
       sleep 10
       su - $ORACLE_OWNR -c "$ORACLE_HOME/bin/emctl stop dbconsole"
       rm -f /var/lock/subsys_oracle
       echo "OK"
       ;;
   reload|restart)
       $0 stop
       $0 start
       ;;
   *)
       echo "Usage: $0 start|stop|restart|reload"
       exit 1
esac
exit 0

(én a listener és az instance mellé beletettem az Oracle Enterprise Manager elindítását is (emctl start dbconsole), mert a gépet olyanok fogják használni, akinek problémát okozhat a parancssorban való elindítása, én meg nem vagyok mindig ott, hogy fogjam a kezüket)

Ha ez kész, akkor gondoskodjunk róla, hogy megfelelő időben és helyen le is fusson:

update-rc.d oracle start 99 2 . stop 01 0 1 6 .

Miután ez kész, a grafikus felület meglehetősen ritkán kell. Ha kell, majd kézzel elindítjuk, automatikusan ne induljon el.

update-rc.d -f gdm remove

A következő napokban a rendszer tesztelése következik. A tesztelés célja, hogy megállapítsa, hogy a rendszer mennyire képes betölteni szerepét (megbízhatóság, teljesítmény, stb.).

Felhasznált írások:
Installing Oracle 10g R2 on Ubuntu Edgy
Installing Oracle 10g Enterprise Edition on Ubuntu 7.10 gutsy gibbon

Hozzászólások

Ha esetleg valami kimaradt, tippek, trükkök, javaslatok (nem olyan, hogy baz+, mér nem CentOS. RHEL, SLES, Fedora, Gentoo, kutyfüle) jöhetnek ide a hozzászólásba.

A képek Ubuntu 6.10 alatt készültek, 7.10 alatt ugyanez. Kipróbáltam a 64 bites verziót 64 bites Ubuntu-n, de az nem települ. Ha valakinek van tippje annak telepítésére, azt szívesen veszem. Hardy Heron-ra is fel lehet tenni. Gyakorlatilag csak kicsit kell módosítani az itt leírtakon.

--
trey @ gépház

"Kipróbáltam a 64 bites verziót 64 bites Ubuntu-n, de az nem települ."
Én ez alapján telepítettem magamnak 64-bites Oracle-t: http://www.oracle.com/technology/pub/articles/smiley_10gdb_install.html Igaz nem Ubuntura.

Amúgy ha az otn.oracle.com fórumján kérdezel, saját tapasztalatom alapján munkaidőben nagyon hamar 1-2 órán belül válaszolnak sokszor a fejlesztők, de ha Ők nem akkor a valamely supportos. Azért tartják be ezt az pár órát, mert a fizetett supportot preferálják míg az OTN-t "szabadidőben" nézegetik.

"Én ez alapján telepítettem magamnak 64-bites Oracle-t:"

A kérdés a "mire". Sajnos az Oracle 10g-nek "kamu" 64 bites a telepítője, kammantás az egész. Egy 32 bites .oui-t indít:

-rwxr-xr-x 1 oracle oinstall 163185 2005-07-02 19:07 .oui
oracle@linora:~/database/install$ file .oui
.oui: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

Ezért csak a "szupportált" rendszereken indul és fut le (mert azok össze vannak úgy gányolva 32 bites libekkel, hogy megy), vagy olyan rendszeren, amire felteszed ezeket a libeket. Én úgy gondoltam, hogy nem gányolok. Megpróbáltam egyébként, de telepítő egy ideig fut, de egy ponton ("linking" ha jól emlékszem) hibákat generál, mert kellenének a 32 bites glibc-devel file-ok. No ennyit nem ért nekem az egész.

Esetleg teljesítmény összehasonlítások érdekelnének arról, hogy a 32 bites és a 64 bites Oracle közt mennyi a differencia ugyanazon a vason. Ilyet nem nagyon találtam, kivéve ezt. Windows-on.

--
trey @ gépház

Nekem RHLE4 -re került fel, amit szándékosan a oracle miatt választottam. Ubuntut nem ismerem, ezért nem is merek belebonyolódni egy telepítésbe rajta, és tapasztalatom sincs ról.

Ugyan nem teszteltem az Oraclet külön-külön 32 és 64 bites OS-en, de felteszem a kérdést a fórumon neked, és ha jön értelmes válasz rá akkor berakom ide is.

Gyanítom hogy teljesítmény visszaesés tapasztalható a 4GByte-nál kevesebb memóriát fogyasztó adatbázisoknál, de nagyobb adatbázisok esetén a 32-bites teljesítménye fog jobban leesni.

"Gyanítom hogy teljesítmény visszaesés tapasztalható a 4GByte-nál kevesebb memóriát fogyasztó adatbázisoknál, de nagyobb adatbázisok esetén a 32-bites teljesítménye fog jobban leesni."

Én is így számoltam, de mivel ez egy tesztrendszer, feltételezem, hogy ez elég lesz. A tesztek, amik most következnek, igazolni vagy cáfolni fogják ezt a feltevést. Ha beválik, akkor megspórolok magamnak egy CentOS telepítést meg az rpm-mel (grrrr) való bohóckodást.

--
trey @ gépház

Bocs hogy így beleoffolok, tudom, hogy örök flame téma, de érdekelne, hogy számodra mi az, ami az rpm alapú disztrókban rossz, de a deb alapúakban jó. Elsősorban persze azokra a dolgokra gondolok amik összefüggenek a csomagkezelővel, csomagformátummal.

Már csak azért is, mert én használtam rpm és deb alapú disztrót is (bár utóbbit rövid ideig), és nem tudnék olyan hibát mondani az egyikben vagy a másikban, ami a csomagkezelővel vagy csomagformátummal kapcsolatos.

"Én is így számoltam, de mivel ez egy tesztrendszer, feltételezem, hogy ez elég lesz."

Én csak óvatosan jelzem, hogy az Oracle nagyon hamar ki tudja nőni a vasat. Lesz rajta más is pl. Data Warehousing tool (AWM) vagy csak az alap SQL?

Működik Oracle 10g egy VMS-en is, az ehez készített howto-mat csak végső esetben adom ki :)

Ezekről nem tudtam. Ha a keresésre előjöttek volna, akkor lehet, hogy nem állok neki. Bár szerintem akkor is lejegyeztem volna magamnak, s ha azt megteszem, akkor ide kitenni már nem munka. További "érdekessége" talán az lehet, hogy Gutsy alatt települt, így aki azt akarja tudni, hogy azzal megy-e, az tudja, ha rátalál a cikkre. Nem egyértelmű, mert pl. Hardy és újabb Linux disztrók alatt el sem indul a telepítő, kell egy workaround ( export LIBXCB_ALLOW_SLOPPY_LOCK=1 ).

Viszont az, hogy a HUP-on megjelenik valami, az majdnem biztos, hogy a Google-ben az első találatok közt van (magyar beállítások mellett):

google://Oracle 10g Ubuntu

Ez a cikk már a 6. helyen van :)

--
trey @ gépház

Pontosítok: A HUP-on egy _linket_ láttam, ami egy magyar nyelvű 11g install doksira mutatott, és ami nem különbözött lényegesen a 10g esettől. Nálam is Gutsyn fut a 11g, csak amikor a doksi készült, még nem volt Gutsy.

Természetesen jó, hogy a HUP-on ilyen leírásokat lehet találni.
--
CCC3

Talán csak képzelődöm, mert most nem találom az említett linket.

32 bites. 64 bites SuSE 9.1-re nem ment fel, a részletekre már nem emlékszem. Ezzel a mostanival biztosra akartam menni, azért eleve 32 bites Gutsyval kezdtem hozzá. Csak programfejlesztésre használom demó adatbázisokkal. A legegyszerűbb vas: 11 HUF-os lap, Intel Core 2 Duo CPU, 2G memória.

--
CCC3

Nem. Kevés a 4GB diszk terület, amit az XE nyújt. Ezt kérték a fejlesztők. Ha elég lett volna, akkor azt telepítettem volna. És fele annyi idő alatt végeztem volna. :) Bár, miután ezt a doksit megírtam magamnak, az éles "tesztrendszert" (nyilván nem ezekkel a paraméterekkel megy) 10-ed annyi idő alatt telepítettem, mint elsőre. A copy & paste ereje :))

--
trey @ gépház

Nagyon király, szép doksi. Köszönöm.

Köszönet a jol dokumentált telepítési utmutatóért !

Szep doksi. En utalok dokumentalni, meg annak tudataban is, hogy kesobb nagy szuksegem lenne ra. Pontosan ezert csodalom azokat az embereket, akik "szabadidejukben" ilyeneket keszitenek. En csak akkor dokumentalok, hogyha a projekt megkoveteli.

Egyebkent itt jegyeznem meg, hogy a SLES10 ingyen letoltheto es jar hozza egy 60 napig hasznalhato activacios kod, amivel 60 napig hozzajuthatsz a frissitesekehez. Ezt csak azert irom, mert SLES-en ugye alapbol tamogatott az oracle. Az aktivacios kod lejarta utan a termek tovabbra is hasznalhato, csak a frissitesi lehetosegrol kell lemondani.

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

Valoban.
A rendszer gondolom arrol szol, hogy az alatt a 60 nap alatt megtetszik a rendszer, utana donthetsz:
1, nem kell frissites -> ingyen van es gaz
2, kell frissites -> veszel sles-t
3, kell frissites -> nem veszel sles-t, hasznalsz pl. ubuntut

Es mivel mar ott fut rajta egy beallitott, "belakott" rendszer, ezert az ember utana hajlik arra hogy vesz hozza frissitest.

Az ubuntuval az a baj, hogy az soha nem lehet eles. Tehat pl. egy bankban soha nem fognak oracle-t telepiteni ubuntura, vagy debianra elesben, mert tiltja a policy.

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

jah, ismerem a SLES-t, tudom hogyan licencelődik.

"Es mivel mar ott fut rajta egy beallitott, "belakott" rendszer, ezert az ember utana hajlik arra hogy vesz hozza frissitest."

Ez a eval rendszerek "beetetése". :)

"Az ubuntuval az a baj, hogy az soha nem lehet eles."

Merthogy? Ez egy éles, házon belüli "teszt és devel" "szerver". :)) Egyébként konkrétan tudok olyan nem kis céget (szerencsére nem semmi közöm hozzá), ahol (ha jól emlékszem) a termelésirányítási rendszerük egy Windows XP-n futó Oracle-n megy. Van itt min csodálkozni kérem :)

"Tehat pl. egy bankban soha nem fognak oracle-t telepiteni ubuntura, vagy debianra elesben, mert tiltja a policy."

Természetesen éles helyre szupportált OS-t adunk minden esetben, ha az ügyfél azt hajlandó megfizetni. Azonban sok esetben marad az, hogy annyira árérzékeny egy projekt, hogy kénytelen vagy improvizálni. Ilyen esetben el lehet indulni egy olcsó megoldással. Ha az szépen működik, akkor mindenki happy. De ha esetleg azzal olyan problémák vannak (pl. szupport hiánya, stb.) amelyek egyértelműen visszavezethetők arra, hogy nem támogatott az OS, akkor lehet érvelni azzal, hogy "mi azt ajánlottuk elsőre, tetszett volna azt venni". Ilyen esetekben ált. meg is veszik a szupportált OS-t. A migráció költsége pedig az ügyfelet terheli, mert ő választotta az olcsóbb megoldást a kockázatok ismeretében.

--
trey @ gépház

Naja. En olyan szerencses helyzetben vagyok, hogy ahol nem sles fut, ott addig nem csinalunk semmit, amig fel nem huz az ugyfel egy sles-t, vagy ad egy gepet, ahova mi felhuzhatunk egyet. :)
Ugye mi csak a sles-t supportaljuk, igencsak megkonnyiti az eletet :)

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

Nem tudom ki-hogy van vele, de en servernek se suse-t se ubuntu-t nem szivesen teszek. Ubuntu kliensnek jo, de teljesen eles szervernek (gyk: amit felhasznalok millioi nyuznak nap nap utan) nem olyan jo. Ha gyorsan kell szerver, debian, ha raer, vagy fontos a security, akkor Hardened Gentoo vagy RHEL, ebben a sorrendben ;).

Fejlesztési szempontból nincsen különbség.

A 64 bit csak a szoftver 1-2 részére igaz, azokra, ahol ez komolyan számít. A többi maradt 32 bit.

Egyébként ez valóban gány, nem is értem miért nem volt képes az ora 64 bitre fordítani a cuccot. Elhiszem, hogy így kényelmesebb, meg olcsóbb, de van már elég 64 bites rendszer, hogy érdemes legyen egy kicsit kódolni-tesztelni. Az adatbázis teljesítménye egyébként az idő előrehaladtával radikálisan szokott romlani, legalább az em-ben levő tunning advisor tanácsait fogadjátok meg. Arról nem is beszélve, hogy nincs olyan adatbázis, amit egy kellően rossz sql tetszőlegesen vason le ne tudna ültetni.

Tipikus fejlesztő hibák:

- View -kat csinálunk (jó bonyolultat, hogy szép legyen) aztán mindent ezen keresztül kérdezünk le. (ez tipikusan a rossz adatbázis tervezésből szokott fakadni)
- adatbázismezőn dolgozó függvények a where részben (nehogy már szerencsétlen indexet tudjon használni.) Ennek tipikus formája:

...where
to_char(datum,'YYYYMMDD')='20080101'

helyette:
...where
datum=to_date('20080101')

de még jobb, ha a dátum egy dátum típusú bind variable-ben érkezik:

...where
datum=:b

(az csak akkor nem jó, ha a különböző dátumok nagyon más jellegű (mennyiségű) eredményt adnak)

adminisztrátori tipikus hibák:

- nincsenek statisztikák (ez a 10-g nél már automatikus elvileg, de nem árt ránézni. Az em-ben megtalálható a job, ami ezt végzi, és jól paraméterezhető)
- tábla és index ugyanabban a tablespace-ben, diszken van.
- I/O korlátolt alkalmazásnál rac-ot csinálunk, mert 2 gép biztos gyorsabb. (a rac elsősorban a megbízhatóság miatt jó, csak másodsorban a teljesítmény, és csak akkor, ha a rendszer eleve úgy van felépítve, hogy a rac tényleg előnyt jelentsen)

Mielőtt a feljlesztők kijelentik, hogy "az Oracle szar" érdemes kicsit az ora sql tunningban elmerülni, mert egy két apró változtatás a lekérdezésben 3-5 nagyságrend sebességkülönbséget jelent. Legjobb, ha fejlesztők is tudnak erről a témáról valamit.

(majd tíz éve ez a szakterületem, úgyhogy ha valami nem stimmel kérdezzetek.)

Az írás egyébként pont olyan részletes, amennyire kell. Jól sikerült darab. Hál' istennek ma már viszonylag egyszerű ora-t linux-ra telepíteni, próbáltad volna a 8i-t. Egy horror volt. (igaz ismerek olyat, aki ezt egy dds szalagról is képes volt elkövetni, annélkül, hogy felmásolta volna a telepítőt!)

"A 64 bit csak a szoftver 1-2 részére igaz, azokra, ahol ez komolyan számít. A többi maradt 32 bit."

Ezt én is így sejtettem.

"Egyébként ez valóban gány, nem is értem miért nem volt képes az ora 64 bitre fordítani a cuccot. Elhiszem, hogy így kényelmesebb, meg olcsóbb, de van már elég 64 bites rendszer, hogy érdemes legyen egy kicsit kódolni-tesztelni."

Ezért is nem folytam bele ebbe a 3/4 részben 32 bites 1/4 részben 64 bites rendszer összegányolásába. Valahogy viccesnek találtam, amikor rájöttem, hogy mi is a valóság :)

"(majd tíz éve ez a szakterületem, úgyhogy ha valami nem stimmel kérdezzetek.)"

Meglesz, mester :) Eddig 99%-ban MS SQL-ben nyomtuk, de úgy fest hogy ráerősítünk a Linux / Oracle, Linux / DB2 és Linux / egyéb RDBMS vonalra (mióta mondogatom...), így azt hiszem, hogy majd lesznek kérdéseim. :)

--
trey @ gépház

Tapasztalatom szerint linuxon valamivel jobb teljesítményt nyújt, de lehet, hogy egy windows guru ezt a különbséget el tudná tüntetni. Mindenesetre az oracle elkövetett pár érdekes húzást a windowsos portnál, úgyhogy én nem szeretem. Linuxhoz/unixhoz vagyok szokva, és nekem a windows kényelmetlen.

"Egyébként ez valóban gány, nem is értem miért nem volt képes az ora 64 bitre fordítani a cuccot. Elhiszem, hogy így kényelmesebb, meg olcsóbb, de van már elég 64 bites rendszer, hogy érdemes legyen egy kicsit kódolni-tesztelni."

Az Oracle fejlesztők nagy része már évek óta a 11g -n dolgozik, nyilván ezért nem akarják a 10-et már nagyon fejleszteni.

Akkor szerencséd volt...

Azért a glibc körüli kavarás elég érdekes volt. A "javítása" meg pláne.

Meg amikor hosszabbak kezdtek lenni a hdd device-ok nevei, és nem fért ki a df egy sorba, a telepítő közölte, hogy az üres diszken nincs hely... (a kód az egysoros df kimenetet tudta csak értelmezni. még szerencse, hogy volt kéznél java decompiler. Különben az életben nem jövök rá mi fáj neki. Metalinken hasonló bejegyzés sem volt)

Meg ha nem angol volt a locale, az oemapp emconsole el sem indult...

...

Azért, mert minden alkalmazás, és gép más, és mindegyikhez máshogyan kell tunningolni. A tunningolás nem csak az adatbázisparaméterek beállítását jelenti, az csak az első lépés. Nincs az mesterséges intelligencia (egyenlőre), amelyik meg tudná mondani, hogyan írd át az sql-ed, szervezd át az adatmodellt, hogy jó legyen. Ez a mai napig félig-meddig művészet. Arra haladunk, hogy egyre kevésbé legyen az, de messze még a cél...

Nekem Ubuntu 7.10 server-en ezt a hibát mutatta:

INFO: - Linking liborasdkbase

INFO: /opt/oracle/product/10gR2/bin/genorasdksh -base

INFO: $Id: genorasdksh.sh 02-mar-2005.16:22:46 mchengjr Exp $

INFO: Generating BASE ORASDK library...

INFO: Creating /opt/oracle/product/10gR2/lib/liborasdkbase.so.10.2

INFO: gcc: /usr/lib/libstdc++.so.5: No such file or directory

INFO: /opt/oracle/product/10gR2/bin/genorasdksh: Failed to link liborasdkbase.so.10.2

INFO: make: *** [liborasdkbase] Error 1

INFO: End output from spawned process.
INFO: ----------------------------------
INFO: Exception thrown from action: make

A megoldás ez volt rá:
apt-get install libstdc++5

Utána Retry gomb és minden príma