(hogy ne hulyuljon meg most itt a HTML, a kacsacsorok helyett ertelemszeruen [] van).
Ugye minden JavaPlugIn-re uninstall volt korabban. Most jon a letoltes, lejon a 1.3.1_02, installalom, megadom a bongeszot. Mindezek utan a kovetkezo hibaablak jelenik meg:
Fejlec: "Java (TM) Plug-in 1.4 Fatal Error" (1.4 ??? Ez honnan?)
Szoveg: "Java Plug-in 1.3.1_01 cannot be located because values in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.3.1_01 is not found or is no longer valid."
En pedig mindent takaritottam a geprol (volt rajta 1.4-es JDK is), ezek szerint megsem. Hol a hiba, mit kell meg likvidalni???
hat ez az, hogy van egy olyan adatbazisunk aminel mukodott az hogy a 817-es szerverbol 805-os klienssel csinalt dumpot megette a 805-os szerver. Csakhogy a most exportalando schema exportjakor a 805-os export kiadad a blob-os tablaknal, ha jol emlekszem "invalid column name" felkialatassal. Ez az ami megfoghatatlan nekem.
UJABB kerdes: ha egy export/import kozben abba a dologba szaladok bele, hogy az import oldalon a characterset-et nem tudja konvertalni (vagy mifene), akkor ezzel lehete valamilyen trukkel segiteni? Valamilyen nls opcio, vagy nls fileok bemasolasa az oracle konyvtar ala, vagy ilyesmi?
Nem azon múlik, hogy másik verzió fícsöreit használtad-e, vagy nem, hanem az, hogy az exp/imp progi kompatibilis-e az adatbázis DD-vel. Ha 8.1.7-ből szeretnél 8.0.5-be adatokat átvinni, akkor a 8.1.7-ből a 8.0.5 exportjával kell kiírni a dumpot.
Amit mi nem mertünk/akartunk megcsinálni: a 8.1.6-os _éles_ adatbázison kellet volna lefuttatni a 8.1.7-es catexp.sql-t. Ezután elméletileg a 8.1.7-es export már összeillik a "feljavított" 8.1.6-os adatszótárral.
Egyszerűbb volt felrakni egy "üres" klienst.
Ha tévedek, valaki javítson ki, ne maradjon itt a marhaság! ;-)
Milyen oprendszeren? Mert unixokon minden gond nelkul. Elmeletben windowson is megy, de a gyakorlatban tenyleg lehet neha problema a registry miatt. Ha csak fejlesztoi gep, akkor nyugodtan telepitsetek.
A 816-os import nem tudja olvasni a 817-es export altal keszitett dumpot! Ez altalanosan igaz, a regebbi import nem tudja olvasni az ujabb verzioju export altal keszitett dumpot. Forditva mukodik. Megoldas: 817-es adatbazisbol sqlnet-en keresztul 816-is exportal csinalni a dumpot.
nos, ezek rossz tapasztalatok...
Az a szkript futtatas mi is lenne? A google-n olvasgatva tobb inkompatibilitasi problema kapcsan is emlegettek "szkript futtatast". Van valami szkript amivel kompatibilitasszintet lehetne esetleg beallitani?
Az en adatbazisom, amit most visszaszeretnek importlani 8.0.5-be, a kovetkezo utat jarta be:
- export 8.0.5-bol adatokkal
- import 8.1.7-be adatokkal
- plusz adatok benyomasa 8.1.7-be
- export 8.1.7-bol
- import 8.0.5-be, ES NEM megy
semmilyen speciseget nem hasznal, ami a 805-os verzioban ne lett volna benne.
Kar, nagyon kar.
nem válaszolok, csak belepofázok... ;-)
Van egy fejl. szerverünk, 8.1.7.4 db-vel. Az egyik éles adatbázis miatt fel kellett rakni egy 8.1.6-os klienst is, mert a .7-es export alapból nem megy a .6-al, az éles db-be meg nem akarjuk a szükséges szkriptet futtatni.
Szóval általában nem volt gond a két klienssel, de a héten súlyosan összekavarodtak. Hiába választottuk a .7-es home-ot, a db listener a .6-os kliens könyvtárába akart logot írni. Egy op. rendszer környezeti változó is tartalmazta az akt. home-ot, ami még a 6-os volt. Grrrr.
A hajam égnek áll, miért nem lehet ezt is egységesen kezelni.
Ugyanez a téma az NLS_LANG paraméterrel. Össze kéne számolni, home-onként hány ilyen bejegyzés van... :(
azt gondolom hogy igen, de azert megkerdezem, hatha van mar valakinek konkret tapastzalata ezzel:
lehet egymas melle telepiteni egy gpre egy 805-os es egy 816-os Oracle szervert? Sajna fejlesztesi okokbol kifolyolag kellene.
Plusz: az tapasztaltam hogy 817-es adatbazis dumpjat 805-be nem lehet beolvasni (a blob mezok megorjitettek). De vajon 817-es dumpot 816-os oracle megeszi??? (Mert nekem csak 816 van) Ne a feltelepites utan deruljon ki hogy megsem...
Éljen a lustaság felkiáltással még nem néztem át a doksikat. ;-)
Vajon van valami extra követelmény egy olyan adatbázissal szemben amelyben rman katalógust és az OEM repository-t szeretném tárolni?
Mindezt 9.2.x.x verzió alatt.
Mivel az adatbazisainkban kozvetlenul ertekesitheto adatok vannak, tenyleg nem latok megoldast arra, hogy en is bele tudjak tekinteni az adatbazisokba. (Raadasul van eleg dolgom enelkul is, eleg gaz lenne, ha a masfel evvel ezelott fejlesztett cuccaimat is ilyen szinten kene nyomon kovetnem folyamatosan.)
Tudom, hogy a "forróbb intézményekben szigor" van, csak nem tudom, hogy az mire megoldás?
Egy tisztességes jogosultsági rendszerrel és némi audit-tal csodásan meg lehetne oldani. (álmodik a nyomor) :))
Lehet, hogy bizonyos esetekben (pl. most) még nálam is lassúbb vagy? :-))))))
Minő véletlen, pont tegnap bukkantam fel erre :-))
( kéretik nem lebuktatni... ;-) )
Nahh..igen.
A dba és fejlesztő "kaszt" elég érdekes számomra.
Láttam már olyan DBA-nak nevezett egyént, aki a create user és create tablespace parancsokat ismerte és néha tudta bökdösni az EM grafikus felületét. Fejlesztőben pedíg olyat, aki a select count(*) from dual szintjén van.
Szóval nehéz általánosságban beszélni arról, hogy ki milyen jó vagy sem. :)))
En csak olyat lattam, aki elso pillantasra normalisnak tunt. :)
(Akkor derult ki, hogy valami nem stimmel, amikor elmeselte, hogyan cincalta darabokra az oracle jdbc driveret, hogy belehegesszen valami javitast/modositast. Viszont o tudta a legbrutalisabb kavet fozni a cegnel, erdemes volt vele joban lenni.)
Sietek leszogezni: fejlesztok kozott sokkal sulyosabb eseteket is talaltam, de nem tudom, hogy ez altalanos jelenseg-e, vagy csak egyszeruen keves dba-t ismerek :)
Erre én csak annyit jegyeznék meg, hogy attól még, hogy éles rendszer fut még létezhetnek olyan role-ok, amivel nyugodtan matathatnál az adatbázisban, megfelelő előírások alapján.
(szerintem)
Egyébként én is azt vallom, hogy a fejlezstőknek több dolgot maguknak kellene megcsinálni, mint amennyit sokszor valóban megcsinálnak.
Én DBA-ként dolgozom és saját tapasztalból mondom ezt, főleg abból kiindulva, hogy van némi fejlesztői tapasztalatom is.
Akkor maradjunk annyiban, hogy nem irigyellek... :)
(Azért a tesztkörnyezetnek full meg kéne egyeznie az élessel)
(Csak nem a matávnak fejlesztetek? Ott vannak így beszorítva kollégáim)
Marcsak azert sem kovethetem figyelemmel, hiszen miutan az alkalmazasom kikerult az eles szerverekre, az eles adatokba en nem kaphatok betekintest, az eles adatbazisszervert nem erhetem el semmilyen modon.
Akar igazad lehetne, csakhogy: ahol a dba nem 10 kilometerrel odebb csucsult, hanem a szomszed asztalnal, es lehetett vele rendesen kommunikalni, ott midnez flottul mukodott.
(A masik esetben meg azt sem tudhatom, hogy milyen adatbazisszerverek vannak, ezek kozul melyikre fog kikerulni, amit irtam. Ha meg blokkmeretet vagy egyeb init parametereket kerek, elkuldenek a fenebe, hogy az az o dolguk. Ebben speciel persze igazuk is van, tenyleg az o dolguk.)
Sztem nekünk (fejlesztőknek) kell okosabbnak és engedékenyebbnek lennünk. Egy dba mégiscsak az IT-n dolgozik, azok meg - cégmérettől függetlenül - jónéhány isteni attribútumot is magukon tudnak. :)))
