Na vis tiek reikia spręsti problemą, kodėl instancas nusikeikia, kad nėra vietos. Šiaip jei problema tik su didele užklausa, galima bandyti stebėti, kaip keičiasi instanco būsena vykdant tą užklausą. Enterprise managerio konsolėj yra priemonių SQLo analizei, gal padėtų... Šiaip dar bandyčiau padidinti REDO logų dydžius (kokie jie dabar?) ir dar gal kelis damesti, kad būtų tarkim 5-6 logai po 50-100MB? O kaip su REDO logais - ar jie grupėse po vieną? Jei po vieną, tai vėlgi ant kito fizinio disko bandyčiau dubliuojančius REDO logus paleisti ir prijungti prie grupių. Dar gal verta pažiūrėti ar su UNDO table space viskas gerai ir patikrinti rollback segmentus. Toxis@ze_yvil_place wrote: > Ka dariau: > scandiska > na fsiakiji dar ir defrangemtuoju (neklausk kam:) > alter system archive log stop;alter system archive log start;alter system switch logfile; > permechiau udumpa i e:\udump su ALTER SYSTEM SET user_dump_dest = 'e:\udump\' SCOPE=both; > lygiai tas pats...Kolkas negaliu su nomountu kurt, bo rytais ypach didelis akrovimas.Po visu archivelog start/stop etc. jis pradejo formuot uzh shiek tiek daugiau nei menesi, bet tik pasieki riba,kai jam kazhkas negerai - jis vel nebeformuoja net uzh savaite... Jis querina duombaze ir toks vaizdas, kadsako.. 'ah fuckit, i'm going home' - atsijungia nuo oraclo, meta tau i veida errora ir shypsosi durnu veidu(hm... gal tikrai reikia baigt dviguba espresso ant tushchio skrandzhio pilt:)Idomu tas, kad kitos ataskaitos, ne tokios dideles imties formuojasi su dainele, be jokiu kaprizu.. chia gi..turiu durna itarima, kad kazhkaip sugebejau trigerint softo ir oraklo bugus vienu apsisukimu:)"Ness" <aggb_nutrinam@inbox.lt> wrote in message news:h0m05l$cgt$1@trimpas.omnitel.net... >> aaaa, nereikes switch, cia ne redo logai :) >> >>> Switch logfile (gali pakartot iki loginimas persoks i ta nauja) ir tada >>> leidi uzklausa. Nereikes ora stabdyti. >>> >>> tai ataskaitom gali NOLOGGING naudot ;) >>> >>> >>> >>> "Toxis" <toxis@spam's_yvil_takas.lt> wrote in message >>> news:h0lrn9$73b$1@trimpas.omnitel.net... >>>> beda ir yra tame, kad duombaze gyva 24/7, kiekvienas shutdownas turi but >>>> ish anksto suderintas, nustumiamas ir perstumiamas:) >>>> reiks gal vakare kai mazhesnis uzhkrovimas pabandyt su noarchivelog'u... >>>> tiesa jei gali veikt _tik_ noarchivelog rezhime - tai ne isheitis, nes ta >>>> uzhklausa yraviena ish generuojamu ataskaitu... idomu tai, kad vienam >>>> site'e generuojasi normaliai, kitam generuojasi uzh beveik metus, o >>>> trechiam, shitam, kur blogiausia - uzh 7 dienas jau pradeda luzht... >>>> >>>> anyway, dekui abiems, bandysiu! >>>> "Vytas :)" <nera@mailo.lt> wrote in message >>>> news:h0lorf$2i6$1@trimpas.omnitel.net... >>>> Jo, jei DB nedirba 24x7, tai nedarbo metu gali pamėginti paleisti db su >>>> noarchivelog (tik prieš keisdamas pasidaryk pilną DB kopiją dėl viso >>>> pikto :) ), ir kaip Ness patarė, pamėgink patestuoti taip. >>>> >>>> Ness wrote: >>>>>> ARC0: Archive destination LOG_ARCHIVE_DEST_2 made inactive: exceeded >>>>>> quota >>>>> negali irasyti archivlogo. Ar netruksta vietos? Padidink kvota. Jei DB >>>>> nekritine - gali persijungti i NOARCHIVELOG rezima ir bandyt ta didele >>>>> uzklausa. >>>>> Esant galimybei praleisk scandisk. >>>>> >>>>> >>>>> >>> >>