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 |
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 |
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 |
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.
Az "inventory" helyének és a könyvtár írására jogosult csoportnaknak (korábban létrehoztuk) megadása
Telepítés típusának kiválasztása
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)
A telepítő kérdéseinek megválaszolása után készen állunk a telepítésre
Mivel nem "superuser"-ként csináltuk a telepítést, két scriptet kell futtatnunk "root" felhasználóként:
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.
A "dbstart" egy (afaik) termékbug miatt elsőre problémás, de könnyen segíthetünk rajta
Szerkesszük meg a "dbstart"-ot
Cseréljük ki a hardcoded "/ade/vikrkuma_new/oracle"-t
A $ORACLE_HOME értékére, azaz "/opt/oracle/product/10gR2"-ra. Az indítás ezután már nem problémás.
A webes felületen beléphetünk az OEM-be, azaz az Oracle Enterprise Manager-be
Aholis rácsodálkozhatunk az Oracle adatbáziskezelőnk működésére
É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 |
|
(é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
- A hozzászóláshoz be kell jelentkezni
- 9124 megtekintés
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
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
"É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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Offtopik. Ha a téma érdekel, nyiss a fórumban topikot.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"É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 :)
- A hozzászóláshoz be kell jelentkezni
Nem, csak SQL. Ha a vasat kinövi, akkor teszek alá nagyobbat. Akkor meg lehet indokolni. :)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Több hasonló doksi forog közkézen, láttam már ilyet itt a HUP-on, és van egy itt is. Nagyjából ugyanígy telepedik a 11g. Érdemes volna írni a kliens installálásról is.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"Nálam is Gutsyn fut a 11g, csak amikor a doksi készült, még nem volt Gutsy."
32 bites? Érdekelne, hogy milyen vas, milyen terheléssel, mire használod és hogy mennyire vagy vele megelégedve. Persze hacsak nem titkos :)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Tehát akkor jól számítottam arra, hogy ez fejlesztésre és tesztelésre megfelelő lesz? Fejlesztési szempontból van valami differencia ha 32 vagy 64 bites rendszerre fejlesztesz? Tippelem, nincs.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nincs.
Kell-e 64 bit desktopra? A desktopom 64-bites, hogy észrevegyem, ha valami baj volna a programjaimmal 64 biten. Az Oracle szerver 32 bites, csak hogy működjön. Az Oracle problémái nem érdekelenek közelebbről.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
"Ez a cikk már a 6. helyen van :)"
nem rosszindulatusagbol, de erdemes megjegyezni h a 'magyar' googlel
- A hozzászóláshoz be kell jelentkezni
Gondolom a "(magyar beállítások mellett):" megjegyzést "véletlenül" hagytad figyelmen kívül.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
:D
nagyon tagoltan irsz:P
szerK: de h valami normalisat is irjak: feljebb lenne az angol google be is ha valaki leforditana :)
- A hozzászóláshoz be kell jelentkezni
A lehetoseg adott.
- A hozzászóláshoz be kell jelentkezni
Úgy gondolom, hogy nem kell grafikus felületet telepíteni. Én úgy szoktam volt csinálni, hogy az sshd-nek engedélyezem az X11 forwarding-ot (az Oracle telepítés idejére), majd egy grafikus felülettel rendelkezõ géprõl ssh -X, és mehet a telepítés.
- A hozzászóláshoz be kell jelentkezni
Igen, ez szebb egy megoldás. Sajnos itt olyanok kapták a gépet, akiknek "kelleni fog" a graf felület.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem lett volna elég a XE kiadás? Abból van hivatalos deb csomag:
deb http://oss.oracle.com/debian unstable main non-free
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Nagyon király, szép doksi. Köszönöm.
- A hozzászóláshoz be kell jelentkezni
Köszönet a jol dokumentált telepítési utmutatóért !
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egy servernel eleg gaz a no update - akkor is, ha csak tesztserver.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 ;).
- A hozzászóláshoz be kell jelentkezni
Definiáld a "nem olyan jó"-t. Számos Ubuntu szerverem van éles üzemben probléma nélkül. Helyi hálón üzemelnek, felhasználók nyúzzák nap mint nap. Hosszú hónapok óta.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nálam konkrétan lassan két éve futnak ubuntuk szerverként, soha, semmilyen gond nem volt velük. Az egyik webszerverként nyúzódik, napi sokezer user nyúzza. Oszt mégis megy.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"(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!)"
Akkor inkabb tole kerdeznenk :)
- A hozzászóláshoz be kell jelentkezni
Érdemes. Nem keveset tud. Bár most veritas cluster-ben utazik.
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
Ha meg kell WinServ/Oracle "tanácsoló" akkor kérdezz engem. :))
Tervbe van véve egy Oracle 11g Linuxra telepítése, de még előtte konzultálok Én is néhány supportossal.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Az lehet, viszont az iparban meg még csak ezután kezdenek megjelenni a 11g rendszerek. (egy nagy rendszer upgrade-je nem szokott triviális lenni.)
- A hozzászóláshoz be kell jelentkezni
SuSE 7.0-re raktam Oracle 8i-t, nem emlékszem, hogy horror lett volna.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
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...
...
- A hozzászóláshoz be kell jelentkezni
kicsitoff: sok olyan cikket lehet latni ahol "mittudomen tunning", miert nem jon default "tunningolva"?
- A hozzászóláshoz be kell jelentkezni
Jon. Ugy hivjak, hogy unbreakable linux :)
--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Ment a könyvjelzők közé, thx! ;)
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Egy kis önreklám: Oracle 11g R1 install Ubuntu 6.06.1-re, ha valakinek 11g kellene.
:)
- A hozzászóláshoz be kell jelentkezni
Network Timeout
The server at deejayy.hu is taking too long to respond.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni