Newsgroup: it.comp.software.database
Titolo: Oracle 8.1.7.3 vs 8.1.7.0

Ho fatto un upgrade alla 8.1.7.3 e mi escono occasionalmente degli
errori che prima non si verificavano.
Da una analisi che ho fatto mi sembra che possano essere causati
indirettamente da alcune query con campi > 32 caratteri (intendo, con
qualche funzione decode() o altro che complessivamente supera questo
limite)
Per ora sto risolvendo (o meglio, cercando di risolvere perche' i
problemi sussistono) mettendo alias per i nomi dei campi.
Il problema in genere e' che la successiva select mi rida' un
NO_DATA_FOUND
Avete qualche idea?
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com

...
Guardando meglio mi sembra che il problema sia dovuto alla replica (il
master e' 8.1.7.0); sembra che durante l'aggiornamento delle tabelle
nello slave 8.1.7.3 le tabelle vengano viste vuote (e quindi mi da' i
no data found)
Mi sembra di avere letto che con versioni diverse a volte invece del
fast fa un full refresh, ma non ho trovato niente di specifico per
queste versioni
sapete niente?


Ciao Alessandro,
non ho controllato ma solitamente conviene avere almeno le stesse 
versioni del database.
Provo a cercare qlcs in più e ti dico!
Se ottieni un errore mi puoi dire quale e in che occasione?
A presto,
Simone
 

 Se ottieni un errore mi puoi dire quale e in che occasione?
L'errore e' un NO_DATA_FOUND nelle select che utilizzano la tabella di
cui in quel momento sto facendo la replica. Come, appunto, se nella
tabella in quel momento non ci fossero records.


Ciao Alessandro,
uhm errore strano.
Cercando anche su metalink non ho trovato grandi cose!
Come hai impostato la query di replica?
La tabella master presenta dei record?
Dammi qualche dettaglio in più plz!
Ciaooo,
Simone

...

Sembra che il problema sia questa materialized view...
Nota che si basa a sua volta su degli snapshots (non so se voglia dire
qualcosa)
Ma e' normale che con un REFRESH COMPLETE mi faccia "sparire" i dati
per qualche istante? mi hanno detto che prima fa un truncate (ed a
questo punto la tabella viene vista vuota) prima di ripopolarla
CREATE MATERIALIZED VIEW app_trasmi_sub_tel
STORAGE (INITIAL 128K NEXT 128K MINEXTENTS 1 MAXEXTENTS UNLIMITED
PCTINCREASE 0)
TABLESPACE users
REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE + 1 /500
AS SELECT DISTINCT
	atcr.cod_app, atr.desc_app,
	crst.cod_subtelaio, st.desc_subtelaio, 'N' materiale,
	DECODE(MAX(DECODE(crst.stato, 'D', 1, 'L', 0) * DECODE(atcr.stato,
'D', 1, 'L', 0)), 0, 'L', 1, 'D') stato,
	MAX(crst.num_sub_occ_sub) num_sub_occ_sub, MAX(crst.num_subverticali)
num_subverticali, 1 num_slot_rif
FROM
	app_trasmi_cod_ra atcr,
	cod_ra_subtel crst,
	apparati_trasmi atr,
	subtelaio st
WHERE
	atcr.cod_ra = crst.cod_ra and
	atr.cod_app = atcr.cod_app and
	st.cod_subtelaio = crst.cod_subtelaio
GROUP BY
	atcr.cod_app,
	atr.desc_app,
	crst.cod_subtelaio,
	st.desc_subtelaio,
	materiale
UNION SELECT
	atst.cod_app, atst.desc_app, atst.cod_subtelaio, atst.desc_subtelaio,
atst.materiale,
	atst.stato, atst.num_sub_occ_sub, atst.num_subverticali,
atst.num_slot_rif
FROM
	t_app_trasmi_sub_tel atst
WHERE NOT EXISTS
	(
		SELECT	atcr1.cod_app, crst1.cod_subtelaio
		FROM	app_trasmi_cod_ra atcr1, cod_ra_subtel crst1
		WHERE	atcr1.cod_ra = crst1.cod_ra
		AND	atcr1.cod_app = atst.cod_app
		AND	crst1.cod_subtelaio = atst.cod_subtelaio
	)
/
CREATE INDEX idx_atst_cod_app_cod_subt ON app_trasmi_sub_tel (cod_app,
cod_subtelaio)
STORAGE (INITIAL 64K NEXT 64K PCTINCREASE 0 MINEXTENTS 1 MAXEXTENTS
UNLIMITED)
TABLESPACE idx NOLOGGING
/

 REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE + 1 /500
[cut]
ma quanto tempo ci mette a fare la query ?
e quanto fa sysdate + 1/500 ?
magari è solo questo.
.
--------------------------------
Inviato via 
http://usenet.libero.it

Ciao Alessandro,
il refresh complete vuol dire che la tua mv deve essere svuotata e
ripopolata completamente!
Strano che ti permetta di accedere ai dati mentre fa il refresh, solitamente
dovrebbe eseguire un lock sugli oggetti in replica!
A presto,
Simone