Emellett még használtuk az Oracle® 8 Server (az előzetes 8.0.5 változat a Linux 2.0.33 verziójához) CD-jét is, amely igazából nem feltétlenül szükséges, valamint a FreeBSD (a 4.3 RELEASE kiadása után nem sokkal levő) 4.3-STABLE változatát.

A telepítendő nyelvtől függően egyéb nyelvi támogatást tartalmazó CD használata is szükségessé válhat. Itt most csak a német és angol nyelveket használjuk, ezért elegendő az első CD. Csendben hozzátesszük, hogy mind a négy EXPORT CD száma megegyezik. Ugyanígy a három nyelvi CD-nek is megegyeznek a számai (ez eltér a 4.6B IDES kiadás CD számozásától). Az írás pillanatában a FreeBSD 4.5-STABLE (2002.03.20-i) változatát használjuk.

A következő hardverkonfigurációt használtuk: két 800 MHz-es Pentium® III processzor és a hozzájuk tartozó alaplap, egy Adaptec® 29160 Ultra160 SCSI-vezérlő (a 40/80 GB méretű DLT szalagos meghajtó és CD-meghajtó használatához) és egy Mylex® AcceleRAID™ RAID-vezérlő (2 csatorna, 6.00-1-00 verziójú firmware és 32 MB memória), amihez két 17 GB-os (tükrözött) merevlemez és négy 36 GB-os merevlemez (RAID 5) csatlakozik.

Itt a hardver egy Dell™ PowerEdge™ 2500 volt: kétprocesszoros alaplap, két darab 1000 MHz-es Pentium® III processzorral (fejenként 256 KB gyorsítótárral), 2 GB PC133-as ECC SDRAM memóriával, PERC/3 DC PCI RAID-vezérlővel (128 MB memória), valamint egy EIDE DVD-meghajtóval. A RAID-vezérlőre két, egyenként 18 GB méretű merevlemezt (tükrözve) és négy 36 GB méretű merevlemezt csatlakoztattunk (RAID 5-ben).

Az egyszerűség kedvéért az SAP® R/3® 46B és SAP® R/3® 46C SR2 telepítése során is ugyanazt a felosztást használtuk. Egyedül az eszközök nevei változtak, mivel a telepítés eltérő hardvereken történt (/dev/da) és /dev/amr, tehát ha az AMI MegaRAID® esetén a /dev/da0s1a helyett a /dev/amr0s1a eszközt láthatjuk):

Előre állítsuk be és inicializáljuk a két logikai meghajtót a Mylex® és a PERC/3 RAID-vezérlőkön. A hozzá tartozó szoftver a BIOS indításának fázisában hívható be.

A lemezek felosztása némileg eltér az SAP® által javasoltaktól, mivel az SAP® szerint az Oracle® könyvtárait (néhány másikkal együtt) külön-külön érdemes csatlakoztatni — mi most az egyszerűsítés kedvéért csak létrehoztuk ezeket.

Töltsük le a legfrissebb -STABLE forrásokat. Fordítsuk újra az összes forrást (make world) és a beállításainak elvégzése után a saját rendszermagunkat is. Itt ne felejtsük el megadni az SAP® R/3® és az Oracle® működéséhez szükséges paramétereket.

Elsőként a linux_base portot kell felraknunk (root felhasználóként):

Ha az Oracle®-t FreeBSD-re a 10.6. szakasz - Az Oracle® telepítéseban leírtak szerint akarjuk telepíteni, akkor szükségünk lesz a linuxos fejlesztőeszközökre is:

A linuxos fejlesztőkörnyezetet csak az SAP® R/3® 46B IDES telepítésénél raktuk fel. Nincs rá szükségünk, ha a FreeBSD rendszeren nem akarjuk újralinkelni az Oracle® adatbázist. Pontosan ez a helyzet, amikor egy Linux rendszerhez gyártott Oracle® készletet használunk.

Az R3SETUP elindításához PAM támogatásra is szükségünk lesz. Amikor először próbáltuk meg telepíteni a FreeBSD 4.3-STABLE változatára az SAP®-t, felraktuk a PAM-et és az összes hozzá tartozó csomagot, majd végül úgy bírtuk működésre, hogy kényszerítettük a PAM telepítését is. Az SAP® R/3® 4.6C SR2 esetén szintén sikerült önmagában felrakni a PAM RPM csomagját is, tehát úgy néz ki, hogy a függőségeit már nem kell telepíteni:

Az Oracle® 8.0.5 verziójához mellékelt intelligens ügynök futtatásához fel kell rakni a RedHat tcl-8.0.5-30.i386.rpm nevű Tcl csomagját is (máskülönben a az Oracle® telepítése közben szükséges újralinkelés nem fog működni). Vannak ugyan egyébként is gondok az Oracle® újralinkelésével, azonban ez linuxos probléma, nem pedig FreeBSD-s.

Hasznos lehet, ha felvesszük a linprocfs bejegyzést az /etc/fstab állományba. Ennek pontos részleteit a linprocfs(5) man oldalon találjuk meg. Másik fontos paraméter a kern.fallback_elf_brand=3, amelyet az /etc/sysctl.conf állományba kell beszúrnunk.

Egy egyszerűbb telepítéshez elég csupán a következő állományrendszereket elkészíteni:

Készítenünk kell még néhány linket is, különben az SAP® telepítője panaszkodni fogni az ellenőrzésük során:

Az egyik ilyen telepítés közben megjelenő hibaüzenet (a PRD rendszer és az SAP® R/3® 4.6C SR2 telepítése esetén):

Az SAP® R/3® rendszernek két felhasználóra és három csoportra van szüksége. Az igényelt felhasználók nevei az SAP® rendszer azonosítójától (System ID, SID) függenek, amely három betűből áll. Egyes ilyen rendszerazonosítók az SAP® számára vannak fenntartva. (Például a SAP és a NIX. Ezek teljes listáját az SAP® dokumentációjában találjuk meg.) Erre az IDES telepítéséhez az IDS, a 4.6C SR2 telepítésénél a PRD neveket adtuk, mivel ezeket a rendszereket éles használatra szánták. Ennélfogva a következő csoportokat hoztuk létre hozzájuk (a csoportok azonosítói ugyan eltérhetnek az általunk használtaktól):

Az Oracle® alapértelmezett telepítésénél csak a dba csoport jön létre. A dba csoportot oper csoportként is használhatjuk (bővebb információkért lásd az Oracle® és az SAP® dokumentációját).

Ezenkívül az alábbi felhasználókra van még szükségünk:

Az adduser(8) parancs használata során a következőkre lesz szükségünk egy „SAP® Administrator” létrehozásához (figyeljük a parancsértelmezőt (shell) és a felhasználói könyvtárat (home directory)):

Ugyanígy az „Oracle® Administrator” esetében:

A dba és oper csoportok használata során ne felejtsük el megadni az oper csoportot sem.

A könyvtárakat általában külön állományrendszerekként hozzák létre, de ez teljesen az igényeinken múlik. Mi most egyszerű könyvtárakként alakítottuk ki ezeket, ezért tulajdonképpen ugyanazon a RAID 5 tömbön találhatóak meg:

Ehhez először beállítjuk az egyes könyvtárak tulajdonosait és engedélyeit (root felhasználóként):

Másodsorban orasid felhasználóként hozzuk létre az /oracle/SID alkönyvtárait:

Az Oracle® 8.1.7 telepítésénél még további könyvtárakra is szükségünk lesz:

A harmadik lépésben létrehozzuk a sidadm felhasználóhoz tartozó könyvtárakat:

A SAP® R/3® működéséhez fel kell vennünk néhány olyan bejegyzést is az /etc/services állományba, amelyek a FreeBSD telepítése során nem jönnek létre. Így tehát írjuk be az alábbi sorokat (legalább a használni kívánt példány számához illő sorokat adjuk meg — ez jelen esetünkben most a 00. Természetesen az sem okoz gondot, ha a dp, gw, sp és ms esetén beírjuk az összes példánynak megfelelő portot 00-tól 99-ig). Amennyiben a SAProuter vagy az SAP® OSS használatára lenne szükségünk, akkor adjuk meg a SAProuter által lefoglalt 99-es példánynak megfelelő 3299-es portot a rendszerünkön:

Az SAP®-nek legalább két olyan nyelvre van szüksége, amely nem része az alap RedHat telepítéseknek. Az SAP® a saját FTP szervereiről elérhetővé tette az ehhez szükséges RPM csomagokat (amelyek viszont csak OSS típusú hozzáférés birtokában tölthetőek le). A 0171356 számú jegyzet tartalmazza a beszerzendő RPM-ek listáját.

Megcsinálhatjuk úgy is, hogy egyszerűen csak linkeket hozunk létre (például a de_DE és en_US könyvtárakra), habár ezt egy éles rendszer esetében semmiképpen sem ajánljuk (az IDES rendszerrel tapasztalataink szerint eddig még remekül működött). Az alábbi nyelvi beállítások fognak tehát nekünk kelleni:

Így hozzuk létre hozzájuk a linkeket:

A telepítés során az iméntiek hiánya gondokat okozhat. Ha folyamatosan figyelmen kívül hagyjuk az ezekből fakadó hibákat (vagyis a CENTRDB.R3S állományban a gondot okozó lépések STATUS értékét OK-ra állítjuk), akkor komolyabb erőfeszítések megtétele nélkül majd képtelenek leszünk bejelentkezni a frissen telepített SAP® rendszerünkbe.

Az SAP® R/3® rendszerek temérdek mennyiségű erőforrást igényelnek. Ennek kielégítésére az alábbi paramétereket adjuk hozzá a rendszermag beállításait tartalmazó állományhoz:

Az itt megadott minimum értékek az SAP® által kiadott dokumentációkból származnak. Mivel a Linux változathoz erről nincs külön leírás, ezért a (32 bites) HP-UX változat dokumentációi között érdemes ennek utánanézni. Mivel a 4.6C SR2 telepítéséhez használt rendszeren valamivel több fizikai memória állt rendelkezésünkre, ezért az osztott szegmensek méretét nagyobbra tudtuk megválasztani mind az SAP®, mind az Oracle® esetében, ami magyarázza a megosztható lapok nagyobb számát.

Sok CD-t kell a telepítés során mozgatni, tehát csatlakoztatni és leválasztani. Ha viszont elegendő meghajtóval rendelkezünk, akkor akár csatlakoztathatjuk egyszerre is az összeset. Vagy felmásolhatjuk a CD-k tartalmát a nekik megfelelő könyvtárakba:

ahol a cd-neve a következők valamelyike: KERNEL, RDBMS, EXPORT1, EXPORT2, EXPORT3, EXPORT4, EXPORT5 és EXPORT6 (4.6B/IDES), valamint KERNEL, RDBMS, DISK1, DISK2, DISK3, DISK4 és LANG (4.6C SR2). A csatlakoztatott CD-ken található állományok neveinek nagybetűseknek kell lenniük. Ha nem így lenne, akkor a csatlakoztatásnál adjuk meg a -g opciót. Így tehát a következő parancsokat kell kiadnunk:

Elsőként egy install nevű könyvtárat kell előkészítenünk:

Ezután futtassuk le a telepítőszkriptet, ami pedig bemásolja az install könyvtárba szinte az összes fontos állományt:

Az IDES (4.6B) változathoz egy teljes SAP® R/3® bemutató rendszer is tartozik, ezért a megszokott három CD helyett hat EXPORT típusú CD-ből áll. Itt a CENTRDB.R3S telepítősablon csak a szabvány központi példányt hozza létre (R/3® és az adatbázis), az IDES központi példányát már nem. Ezért az EXPORT1 könyvtárból ki kell másolnunk a CENTRDB.R3S állományt, különben az R3SETUP csak három EXPORT CD-t fog kérni.

Az újabb SAP® 4.6 SR2 kiadáshoz négy EXPORT CD tartozik. A telepítés folyamatát a CENTRAL.R3S állományban levő paraméterek vezérlik. A korábbi kiadásokkal ellentétben nincsenek külön sablonok az adatbázissal és a nélküle telepítendő központi példányok számára. Az SAP® az adatbázisok telepítésére külön sablont használ. Újrakezdéskor a telepítést ettől függetlenül elegendő az eredeti állománnyal újraindítani.

A telepítés közben és után az SAP®-nek a hostname paranccsal csak a gép saját nevét, nem pedig a teljes hálózati nevét kell megadnunk. Ilyenkor ezt vagy egyenként begépeljük, vagy létrehozunk rá egy álnevet az orasid és sidadm (valamint a megfelelő lépésekben a root) felhasználóknak: alias hostname='hostname -s'. Ezenkívül még az SAP® telepítésekor létrehozott mindkét felhasználó .profile és .login állományait is beállíthatjuk ennek megfelelően.

Ne felejtsük el jól beállítani az LD_LIBRARY_PATH környezeti változót:

A telepítés könyvtárában root felhasználóként indítsuk el az R3SETUP programot:

A szkript ezek után feltesz néhány kérdést (az alapértelmezett válaszok zárójelben, közvetlenül a megadottak után):

Ha a CD-ket nem különböző helyekre másoltuk, akkor az SAP® telepítője nem fogja megtalálni ezeket (a rajtuk levő LABEL.ASC segít neki az azonosításban) és kérni fogja a CD csatlakoztatását, illetve a csatlakozási pontjának megadását.

A CENTRDB.R3S sem minden esetben mentes a hibáktól. A tapasztalataink szerint az EXPORT4 címkéjű CD-t kérte újra, miközben a helyes kulcsokat jelezte ki (6_LOCATION, majd 7_LOCATION stb.), így egyszerűen csak lépjünk tovább az értékek meghagyásával.

Függetlenül az imént említett problémáktól, egészen az Oracle® adatbáziskezelő telepítéséig mindennek működnie kellene.

Állítsuk be jól az LD_LIBRARY_PATH környezeti változó értékét. Ez némileg eltér a 4.6B és az Oracle® 8.0.5 párosának beállításától:

A telepítés könyvtárából root felhasználóként indítsuk el az R3SETUP programot:

A szkript ezek után feltesz néhány kérdést (az alapértelmezett válaszok zárójelben, közvetlenül a megadottak után):

Az OSUSERDBSID_IND_ORA és OSUSERIDADM_IND_ORA lépésekben az orasid és sidadm felhasználók létrehozása hibákra futhat.

Függetlenül az említett problémáktól, az Oracle® adatbáziskezelő telepítéséig mindennek remekül kell működnie.

Az Oracle® 8.0.5 verziójának használata esetén néhány további függvénykönyvtár újralinkelésére is szükség lesz, mivel az Oracle® 8.0.5 még a régi glibc könyvtárral lett fordítva (RedHat 6.0), viszont a RedHat 6.1 már a glibc újabb verzióját használja. A linkelés működéséhez az alábbi csomagokat kell még telepítenünk:

A részleteket lásd az SAP® füzeteiben vagy az Oracle® Readme állományaiban. Amennyiben ez nem oldható meg, akkor az eredeti binárisok, esetleg az eredeti RedHat rendszerből származó újralinkelt binárisok is használhatóak (habár a telepítés pillanatában személyesen ezt nem tudtuk ellenőrizni).

Az intelligens ügynök lefordításához fel kell raknunk a RedHat saját Tcl csomagját. Ha ehhez nem tudjuk beszerezni a tcl-8.0.3-20.i386.rpm csomagot, akkor a RedHat 6.1 változatához készült tcl-8.0.5-30.i386.rpm is megteszi.

Az újralinkeléstől eltekintve a telepítés többi része szinte adja magát:

Az Oracle® On-Line Text Viewer kikapcsolásán (mivel az jelenleg Linux alatt sem érhető el) kívül mindegyik képernyőt hagyjuk jóvá az Enter billentyű lenyomásával. Az Oracle® ezután a rendelkezésre álló gcc, egcs vagy i386-redhat-linux-gcc helyett a i386-glibc20-linux-gcc használatával újra akarja linkelni magát.

Idő hiányában az Oracle® 8.0.5 PreProduction kiadásából emeltünk ki binárisokat, de az adatbáziskezelő rendszer felélesztésére tett első kísérleteink kudarcba fulladtak, és ezután a megfelelő RPM-ek összeszedése valódi rémálomnak bizonyult.

A telepítés nagyon könnyű. Csatlakoztassuk a CD-t, majd indítsuk el a telepítőt. Ezután meg kell adnunk az Oracle® felhasználói könyvtárát és a telepítő odamásolja az összes binárist. Habár a telepítés megkezdése előtt a korábbi kísérleteink nyomát nem tüntettük el.

Ezt követően az Oracle® adatbázisrendszer minden további gond nélkül elindítható.

Ezután az R3SETUP folytatható vagy újraindítható (attól függően, hogy a kilépést választottuk-e vagy sem). Az R3SETUP ekkor létrehozza az adatbázisban a táblákat és az R3load meghívásával feltölti ezeket adatokkal (a 46B IDES változat esetében az EXPORT1 - EXPORT6, a 46C esetében pedig a DISK1 - DISK4 lemezekről).

Amikor a feltöltés befejeződött (ami akár órákig is eltarthat), szükség lesz még néhány jelszó megadására is. A próbatelepítéseknél nyugodtan használhatjuk a jól ismert alapértelmezett jelszavakat (azonban mindenképpen változtassuk meg ezeket, ha egy kicsit is számít a biztonság!):

A 4.6B telepítése során még gondjaink akadtak a dipgntab használatával.

Így kell elindítani az orasid felhasználóval az Oracle® Listenert:

Ha máshogy próbálkozunk, akkor az ORA-12546 kódú hibát fogjuk kapni, mert a hálózati portok socketei nem rendelkeznek a szükséges engedélyekkel. Lásd a 072984-es SAP® füzet.

Ha nem Latin 1 kódolású nyelveket akarunk importálni az SAP® rendszerbe, akkor frissítenünk kell a többnyelvű nyelvi támogatáshoz (Multi National Language Support, MNLS) tartozó táblázatokat. Ezek bemutatását a 15023 és 45619 számú SAP® OSS füzetekben olvashatjuk. Minden más esetben az SAP® telepítésekor nyugodtan kihagyhatjuk.

Az SAP® R/3® licenckulcsát külön kell kérni. Fontos, mert a telepítéshez használatos ideiglenes licenc csak négy hétig érvényes. Először szerezzük meg a hardverkulcsot. Jelentkezzünk be az idsadm felhasználóval és adjuk ki a saplicense parancsot:

A saplicense paraméter nélkül meghívására válaszul opciókat listáz ki. A licenckulcsot megérkezése után így tudjuk élesíteni:

Ezután a következő értékeket kell megadni:

Hozzunk létre egy felhasználót a 000 kliensen belül (a csak rajta belül elvégezhető feladatokhoz, aki különbözik a sap* és ddic felhasználóktól). Felhasználónévként általában a wartung nevet választottuk (ami angolul a service névnek, avagy szolgáltatásnak felel meg). A sap_new és sap_all nevű profilok is kellenek. A biztonságosság kedvéért a kliens összes alapértelmezett felhasználójának (beleértve a sap* és ddic felhasználókat is) változtassuk meg a jelszavát.

A ddic és sap* felhasználóktól eltérő nevű felhasználóval a 000 kliensen belül legalább a következőket végezzük el:

Az iménti és az összes többi telepítés utáni lépések leírása teljes egészében megtalálható az SAP® telepítési útmutatóiban.

Az /oracle/IDS/dbs/initIDS.sap állomány tartalmazza a SAP® tartalék profilját. Itt többek közt a használni kívánt szalag méretét, a tömörítés típusát és hasonló paramétereket kell definiálni. A sapdba / brbackup futtatásához a következő értékeket változtattuk meg:

Magyarázat:

compress (tömörítés): HP DLT1 típusú szalagot használtunk, ami tud hardveres tömörítést.

archive_function (archiválási házirend): Ez adja meg, hogy alapértelmezés szerint mi történjen az Oracle® archivált naplóival: az új naplóállományok először a szalagra mentődnek, majd a már lementett naplók ismét mentésre kerülnek és végül törlődnek. Ezzel sok fejfájástól menekülünk meg, mivel ilyenkor az archiváló szalagok esetleges sérülése esetén is valószínűleg képesek leszünk visszaállítani az adatbázist.

cpio_flags (a cpio beállítása): A -B használata alapértelmezés, amivel a blokkok mérete 5120 byte-ra állítódik. A DLT típusú szalagokhoz a HP legalább 32 KB-os blokkméretet javasolt, ezért a --block-size=128 beállítással ezt 64 KB-ra növeltük. Szükségünk volt a --format=newc beállításra is, mivel 65535-nél több inode számunk van. Az utolsó beállítás a --quiet, amivel megakadályozzuk, hogy a cpio lementett blokkokat összefoglaló kijelzésére begerjedjen a brbackup.

cpio_in_flags (a cpio bemeneti beállításai): A szalagok visszatöltésénél használt beállítások. A formátumot automatikusan felismeri.

tape_size (szalagméret): Ezzel adjuk meg általában a szalag nyers kapacitását. Biztonsági okokból (hardveres tömörítést használunk) ez az érték a ténylegesnél valamivel kisebb.

tape_address (szalagos eszköz): a cpio által használható nem visszatekerhető eszköz.

tape_address_rew (visszatekerhető szalagos eszköz): A cpio által használható visszatekerhető eszköz.

Az SAP® alábbi paramétereit kell beállítani a telepítés után (IDES 46B, 1 GB memóriával):

0013026 SAP® füzet:

0157246 SAP® füzet:

Az R3SETUP hiba esetén leáll. Miután átnéztük a hibára utaló naplókat és elhárítottuk a hiba okát, újra el kell indítanunk az R3SETUP programot, majd a REPEAT opció kiválasztásával próbáljuk megismételni az R3SETUP által kifogásolt legutóbbi műveletet.

Az R3SETUP újraindításához egyszerűen adjuk meg a megfelelő R3S állományt:

a 4.6B verzió esetén, vagy a

a 4.6C verzió esetén, függetlenül attól, hogy a hiba a CENTRAL.R3S vagy DATABASE.R3S állományoknál keletkezett.

Ha az R3SETUP panaszkodik ebben a lépésben, akkor írjuk át az általa ekkor használt sablont (a 4.6B esetén ez a CENTRDB.R3S, illetve a 4.6C esetén ez a CENTRAL.R3S vagy a DATABASE.R3S). Keressük a [OSUSERSIDADM_IND_ORA] szöveget, vagy csak a STATUS=ERROR bejegyzést, majd írjuk be a következő értékeket:

Ezután indítsuk újra az R3SETUP programot.

Az R3SETUP ebben a lépésben is hajlamos panaszkodni. Az itt felbukkanó hiba hasonló az OSUSERSIDADM_IND_ORA lépésben jelentkezőhöz. Szerkesszük át az R3SETUP által ilyenkor használt sablont (4.6B verzió esetén ez a CENTRDB.R3S, illetve 4.6C verziónál a CENTRAL.R3S vagy DATABASE.R3S). Keressük meg a [OSUSERDBSID_IND_ORA] részt, vagy csak a STATUS=ERROR bejegyzést, majd írjuk át az ebben a szakaszban szereplő értéket így:

Indítsuk újra az R3SETUP programot.

A telepítés megkezdése előtt nem tiltottuk le az Oracle® On-Line Text Viewer felrakását. Habár Linux esetén ez nem használható, alapértelmezés szerint mégis ki van választva. Az Oracle® telepítő menüjében tiltsuk le ezt és nélküle kezdjük újra a telepítést.

Ha ilyen hibával kerülünk szembe, akkor hiányoznak a megfelelő nyelvi állományok. A 0171356 SAP® füzet tartalmazza a telepítendő RPM csomagok felsorolását (például a RedHat 6.1 esetén a saplocales-1.0-3 és saposcheck-1.0-1). Amennyiben figyelmen kívül hagyjuk az ilyen hibákat, és az R3SETUP minden kiakadásánál átírjuk (a CENTRDB.R3S állományban) az STATUS értékét az ERROR értékről az OK értékre és újraindítjuk, az SAP® nem állítódik be jól és nem tudunk a SAPgui alkalmazással rácsatlakozni a frissen telepített rendszerre még akkor sem, ha el tudtuk indítani. Amikor a régebbi linuxos SAPgui alkalmazással csatlakozunk, a következő üzeneteket kapjuk:

Ez a viselkedés annak köszönhető, hogy az SAP® R/3® nem képes jól összerendelni a nyelvi beállításokat, sőt, magát sem képes jól beállítani (hiányoznak némely bejegyzések az adatbázis egyes tábláiban). Az SAP®-hez úgy tudunk ilyenkor csatlakozni, ha a DEFAULT.PFL állományba felvesszük a következő bejegyzéseket (lásd 0043288 füzet):

Majd indítsuk újra az egész SAP® rendszert. Ezután már tudunk csatlakozni hozzá, még ha az országra jellemző nyelvi beállítások nem is működnek tökéletesen. Miután korrigáltuk az ország beállításait (és felraktuk a megfelelő nyelvi állományokat), távolítsuk el az iménti bejegyzéseket a DEFAULT.PFL állományból és indítsuk újra az SAP® rendszert.

Ez a hiba FreeBSD alatt az Oracle® 8.1.7 használata során következhet be. Akkor történik, amikor az Oracle® adatbázis nem volt képes rendesen inicializálni magát és összeomlott, aminek révén szemaforokat és memóriát hagyott megosztva a rendszerben. Így az adatbázis következő indításakor kapunk egy kövér ORA-00001 hibát.

Az ipcs -a paranccsal keressük meg ezeket, majd az ipcrm segítségével pedig számoljuk fel.

Ez a hiba az Oracle® 8.1.7 használatakor következhet be. Akkor kapjuk ezt a hibát, amikor prdadm felhasználóként a elindítjuk startsap szkriptet (például startsap_majestix_00).

Erre gyógyír lehet, ha ehelyette az adatbázis elindításához az oraprd felhasználóval adjuk ki az svrmgrl parancsot:

Az Oracle® Listener alkalmazását oraids felhasználóként az alábbi paranccsal indítsuk el:

Máskülönben ORA-12546 hibát kapunk, mivel a hálózati portokhoz tartozó socketek nem rendelkeznek a megfelelő engedélyekkel. Lásd 0072984 SAP® füzet.

Akkor fordul elő ilyen hiba, amikor a MAXDSIZ és DFLDSIZ értékeit 1 GB-nál (1024 x 1024 x 1024-nél) nagyobbra állítottuk. Mellé még kapunk egy Linux Error 12: Cannot allocate memory hibát is.

Erről alapvetően a 0130581 számú SAP® füzet ad tájékoztatást (az R3SETUP DIPGNTAB lépése hibára fut). Az IDES telepítése során az SAP® rendszer valamiért az „IDS” név helyett egy üres karakterláncot használ. Ez a könyvtárak elérésében kisebb gondokat okoz, mivel az elérési útvonaluk a SID-ből generálódik (ami ebben az esetben az IDS). Tehát a

helyett a következőt próbálja meg elérni:

A telepítés folytatásához létrehoztunk egy linket és egy másik könyvtárat:

Észrevettük, hogy a SAP® füzetekben (0029227 és 0008401) ugyanezt a viselkedést írják le. Az SAP® 4.6C telepítésénél azonban ilyen hibával nem találkoztunk.

Az SAP® 4.6C telepítése folyamán ez a hiba csupán egy korábban bekövetkezett másik hiba utóhatása volt. Itt át kell néznünk az összes érintett naplót és ki kell javítanunk a tényleges problémát.

Amennyiben a naplók átvizsgálása után csak ezt találjuk egyedüli hibának (lásd SAP® füzetek), állítsuk át (a CENTRDB.R3S állományban) a STATUS értékét az OK értékre, majd indítsuk újra az R3SETUP programot. A telepítés befejezése után hajtsuk végre az SE38 tranzakcióból az RSWBOINS riportot. A további RFCRSWBOINI és RFCRADDBDIF lépésekkel kapcsolatban lásd a 0162266 SAP® füzetet.

Itt az előbbihez hasonló feltételek élnek: mindenképpen ellenőrizzük a naplókban, hogy a hibát nem egy korábban keletkezett hiba okozta.

Ha tényleg csak az 0162266 SAP® füzetben leírtak érvényesek, akkor (a CENTRDB.R3S állományban) állítsuk a gondot okozó lépés STATUS értékét az ERROR értékről az OK értékre, és indítsuk újra az R3SETUP programot. A telepítés után pedig hajtsuk végre az SE38 tranzakciból az RADDBDIF riportot.

Ez a disp és work SAP® programok indítása során történhet meg. Az SAP® rendszert indító startsap szkriptről leválva indulnak el a többi SAP® program elindításáért felelős alfolyamatok. Ennek eredményeképpen a szkript maga nem fogja észrevenni a hibát.

Az SAP® programok elindulását az ps ax | grep SID paranccsal tudjuk ellenőrizni. Az eredményül kapott listában az összes aktív Oracle® és SAP® programnak szerepelnie kell. Ha ebből az tűnik ki, hogy bizonyos programok hiányoznak, vagy nem képesek kapcsolódni az SAP® rendszerhez, akkor az /usr/sap/SID/DVEBMGSnr/work/ könyvtárban nézzük át a hozzájuk tartozó naplóállományokat. Elsősorban a dev_ms és a dev_disp állományok fontosak számunkra.

A 31-es jelzés akkor keletkezik, ha az Oracle® és az SAP® által használt osztott memória mértéke meghaladja a rendszermag beállításai közt megadott értéket. Ezt tehát ennek növelésével lehet orvosolni:

A saposcol (4.6D verzió) programmal akad néhány probléma. Az SAP® rendszer az saposcol segítségével próbál adatokat gyűjteni a rendszer teljesítményéről. Mivel ez a program nem feltétlenül szükséges az SAP® rendszer működéséhez, ez a probléma nem tekinthető komolynak. A korábbi (4.6B) verziókban ugyan működik, de semmilyen adatot nem képes begyűjteni (mivel a legtöbb hívás, például a processzorhasználat függvénye, egyszerűen csak nullát ad vissza).