Felmerült az igény, hogy a Service Desk (USD), Desktop and Server Management (DSM) alkalmazásokat valamint az õket kiszolgáló SQL szervert egy-egy különálló gépre kell szétszedni, performanciális és üzemeltetési okok miatt. A rendszerek ennek lehetõségét biztosítják, csak ennek megfelelõen kell a rendszereket telepíteni.

A CA felügyeleti alkalmazásai alapvetõen egy közös menedzsment adatbázisba (MDB) dolgoznak, ezen keresztül tudják tartani a kapcsolatot is adatszinten egymással. Az adatbázist az elsõ rendszerfelügyeleti komponens telepítésekor hozzák létre, majd minden a továbbiakban telepítésre kerülõ alkalmazás ide jegyzi be saját hozzáférési adatait, csak a felhasználókat és a szerepköröket, maga az adatbázis az alkalmazások által közvetlenül nem kerül módosításra, annak önálló telepítõje van. Amennyiben az adott alkalmazás nem a lokális szerveren tárolja az adatbázisát, akkor elsõ lépésben az adatbázis szerveren kell az MDB generálását elvégezni, ezt Remote Components Install-nak hívják (az egyes termékek ettõl kicsit eltérõen is nevezhetik, nevezik). Amennyiben ez a telepítés elkészült, akkor a telepítés a tényleges alkalmazás szerveren folytatódik, s a telepítõ varázsló paraméterezésekor adjuk meg a már elõkészített MDB-t tartalmazó adatbázis szerver elérési adatait.

DSM átmozgatása

Nos ez idáig mind szép és jó, de azért a technika ördöge számos esetben megtréfálhat bennünket. Elsõ lépésben az volt a kérdés, miként lehet a DSM rendszer adatbázis kapcsolatát újrakonfigurálni a rendszer újratelepítése nélkül. A dokumentációkat átrágva rádöbbentünk, hogy errõl mélyen hallgatnak, és nincs olyan konkrét eljárás leírva mint az USD esetén. Megkérdeztük errõl a CA TCC-t és 1 hónap alatt sajnos Ők sem találtak semmilyen használható információt. Érdekes módon közben elõkerült egy régebbi verzióhoz készült dokunmentáció (TEC413416), mely az MDB backup/restore lehetõségeit írja le. Ebben van egy rész ami érdekes számunkra:

…
The new Domain Manager must have the same host name as the old one had
…

Ezek alapján sajnos belátható volt, hogybár akár külön is lehetne bontani az alkalmazás és az SQL szervert, de ezt csak akkor lehet megtenni, ha az adatbázis szerver neve a visszaállítást követõen ugyan az mint eredetileg volt. (Sajnos nekünk ez nem volt lehetséges, ergó futás elõrõl, uninstall/reinstall… )

MDB adatbázis létrehozási gond

Régi probléma, hogy az alkalmazások igencsak érzékenyek milyen Collation-al telepítjük az SQL szerverünket. A CA esetében régi ismert tény volt, hogy az Collation lényeges, hogy 1250-es code page alapú és Case Insensitive legyen.

Csütörtök óta küzdünk vele, hogy az osztott adatbázis szerveres megoldáshoz szükséges telepítéseket nem tudjuk elvégezni. Hosszas nyomozás során kiderült, hogy egy szimpla SQL ALTER utasításnál áll le, ugyanis az egyik mezõ nem létezik! A kezdeti ellenõrzések lefutását követõen a TCC-t is kérdezgettük mi lehet a dolog oka? Egyértelmû volt, hogy valami olyan “apróság”, amely a gyári – várhatóan angol nyelvi – környezetben nem jött elõ. Nem hittük, hogy erre kintrõl kapunk választ de bizakodtunk. Közben azért mi is vakartuk a fejünket és egyszer csak felmerült, hogy volt már ilyen gond az r11-es széria megjelenésekor.

Nosza ellenõrizzük le és még jobban megerõsödött a gyanúnk, a probléma várhatóan a Hungarian Collation. Nekifutottunk és az adatbázisunkon átállítottuk a Collation-t SQL_Latin1_General_CP1250_CI_AS-ra. Ismét nekifutottunk és láss csodát, mindjárt mûködött a dolog. A hiba oka ezek alapján egyértelmûen a Transact SQL scriptek “stilisztikájában” van. A programozóknak a cS, a cs és a CS teljesen egyenértékû, de amennyiben az SQL szerver Hungarian collation-ra van állítva, akkor ebbõl van ami ‘c’ és ‘s’ egymás után és van ami ‘cs’. Ez az angoloknak gyakorlatilag értehetetlen probléma, és nem is igazán akarják megérteni.

MDB átmozgatása (backup/restore) és a DSM telepítési gond

Amennyiben ezeken átjutottunk, a másik SQL szerveren lementett és most visszaállított adatbázisunkra alapozva megpróbálhatjuk az új szerverünkön telepíteni a DSM rendszert. Amint eljutunk odáig, hogy a telepítõ varázslónak megadjuk az MDB adatbázis elérését és az egész telepítõ megáll. Miért is?

1. Nem tudunk kapcsolódni az adatbázishoz, mondván rossz a ca_itrm felhasználó bejelentkezési jelszava. A ca_itrm user bár létezik a visszaállítás után, de ha tüzetesen megvizsgáljuk látni fogjuk, hogy az adatbázis-hoz létrehozott felhasználóhoz nincs meg a login név. A megoldáshoz töröljük a felhasználót és vegyük fel újból. Figyelem a megadott jelszóra szükségünk lesz a telepítés során!
2. Kapunk egy hibaüzenetet a telepítõtõl, hogy “az adatbázisban már létezik egy xxxx nevû domain, második nem telepíthetõ bele”. Ez az a hiba amivel nehéz mit kezdeni. Egyszerû megoldás, ha az MDB átmozgatása (restore) elõtt töröljük az alkalmazást a szerverrõl, és ekkor az uninstall folyamán az érintett bejegyzések eltávolításra kerülnek.

Folytatás

Most itt tartunk, lassan nekikezdhetünk az alkalmazások érdemi telepítésének, hisz az elõfeltételek már végre adottak.