Oracle, oracle, csak a baj van veled... 2. felvonás - avagy ORA-12547

Felment az Oracle, megvolt a mentés/visszaállítás kör is, szépen megy a standard. De. Csináltam egy másik gépet, ugyanazzal az Oracle verzióval, ugyanazzal a DB-kreáló scripttel és visszatöltött adatbázissal.
Lokálisan sqlplus user meg  sqlplus user@\"host.domain:1521/sid.db.domain\" működik, listener statusz (a host meg a sid kivételével) ugyanazt mutatja, mint az első gépen,viszont mig az elsőnek telepített szerverre távolról lehet kapcsolódni, úgy az újabbra nem, mert szép kövér ORA-12547-tel zavar el a búsba.

A két telepítés között emlékeim szerint annyi a különbség,hogy az elsőnél a sid az valami "abc", a másodiknál meg "efg.db.domain" lett.

Selinux permissive módban, a comagok eljutnak a listenerig, mert a listener logban ott van a nyoma - méghozzá olyan nyoma, mint a másik gépen, ahol sikerül bejelentkezni.

 

( NevemTeve | 2020. 03. 27., p – 05:13 )

Szerkesztve: 2020. 03. 27., p – 05:16

Ha jól csalódom, a listener írkál egy 'kedves naplóm' szerű log-fájlt (network/log/listener. log vagy hasonló).

Kliensoldalon tnsnames.ora használatával vagy anélkül ugyanaz a jelenség?

A listener logja (valami xml egyébként) gyakorlatilag úgyanúgy néz ki mindkét gépen, de megnézem, van-e másik. Kliens jelenleg egy 18.5-ös instant kliens, illetve Toad, nem tnsnames.ora, hanem direkt kapcsolattal. Amelyik szervernél nics database domain beállítva, ott működik a távoli login, ahol van, ott nem. Sajna 10 verzióval ezelőtt volt komolyabban közöm az orákulumhoz, és khm. megkoptak az emlékek :-/
 

( azs | 2020. 03. 27., p – 09:42 )

Az oracle bináris ($ORACLE_HIME/bin/oracle) jogosultságai rendben?

Nálam (Ora linux):

-rwsr-s--x 1 oracle oinstall 199650985 Jan  4  2019 oracle

( nydn | 2020. 03. 27., p – 11:28 )

Szerkesztve: 2020. 03. 27., p – 11:29

Szinte biztos, hogy nem jól állítottad be a listener-t (listener.ora és sqlnet.ora fájlok környékén nézelődj)

Next-next-finish volt mindkét esetben, az egyiknél a sid-nek foo, a másiknál moo.bar.baz lett bevésve, de megnézem, miben különbözik a két gép - egyébként egyiken sincs sem listener.ora sem sqlnet.ora.

A "*.ora" fájlok közül az spfileSID.ora tér el, de ez természetes. Ahol van db_domain, ott nem megy a távoli login :(

A listener.log sem mutat releváns eltérést a két szerveren, sőt ha lokálisan megyek user@host:port/servcice módon, akkor a listener logja gyakorlatilag ugyanúgy néz ki, mint amikor távolról érkezik a kapcsolódás, de az egyiknél beenged, a másiknál meg a bőbeszédű és részletes, jól definiált ORA-12547 jön vissza a kliensen -a miről értelmes érdemi megoldási javaslatok nagyjából a vajákosság szintjén érhetőek el.

Nincs semmi ilyen extra - egyénként ez egy irdatlan púp a hátunkra - bár lehet, hogy a fejlezstő kiválasztásánál az volt az elv, hogy milyen RDBMS _nincs_ még :-/ Az meg hab a tortán, hogy úgy indult, hogy Oracle XE elég lesz - aztán marhára nem lett elég, kifejezetten a qrva nagyra duzzadó (és sajnos tényleg kell ekkora...) temp táblatér miatt. Ilyen az, amikor az üzemeltetés az utolsó, aki megtudja, mit vesznek meg... Egyébként a vége az lesz, hogy a a meglévő, működő gépet leállítom a 3.14csbe, leklónozom, lecserélem a hostnevet, ip-címet, aztán nyaljanak sót... Bár lehet, hogy ennek a fostorony orákulumnak ez is meg fogja viselni a gethes gyomrát.

( zeller | 2020. 03. 29., v – 19:46 )

Szerkesztve: 2020. 03. 29., v – 19:54

expdp indulandusz-tódulandusz a jól működő szerveren, ha sikeresen lemegy, akkor a problémásat legyalulom a búsba - szerencsére a DB-kreáló scriptet már sikerült értelmes formában (értsd: nem egy docx fájlba jól/rosszul beszurkált részletek sorozataként) összelapátolni, úgyhogy megy az egész kupac a devnullba, és orákulum újrahúzás, új DB, új minden (database domain nélkül), majd pedig az adatok visszalapátolása következik. Ha már ilyen baromira jól dokumentált, rengeteg online elérhető információval és segítséggel bíró (ja, nem) fostoronyra sikerült alapozni az n+1234. egyedi rendszert.

Ja, és persze a fejlesztő előírása alapján: NLS_LANG=HUNGARIAN_HUNGARY.EE8MSWIN1250, csak hogy el ne felejtsem, milyen volt a világ a múlt évezredben...

(A 'Hungarian' azért jó, mert így a valós hibaüzenetek helyett a fordító[ember] félreértéseit kapjuk. Az EE8MSWIN1250 meg akkor fontos, ha olyan karakter is van benne, ami különbözik ISO8859-2-ben és Windows-1250-ben (szerencsére a magyar ékezetes betűk nem ilyenek). Persze ha már ekkor a baj, akkor talán érdemes UTF8-ra váltani. Vagy az 'unistr'-t használni, ha csak kevés ilyen karakter van.)

Ez csak a fejlesztő sql-jeinek (ősfeltöltés mindenféle stringeket tartalmazó táblákba pl.) a betöltésekor kell, mert volt már abból probléma, hogy egy magyarázat/egy listaelem "érdekesen jelent meg". Lehetne iconv/recode tornázás előtte, de tornázzon ezzel az, akinek hét anyja van (de leginkább a fejlesztőnek kéne normális formátumban adnia az sql-jeit...).

A hibaüzenetek kérdése szerencsére mindegy - ebben azért jó az oracle azzal, hogy hibakódot ad, aztán mellé rakja a beállított nyelvű ferdítést/fordítást.