Query bloccata.
Eugenio
query che per 4 anni ha sempre funzionato e all'improvviso, apparentemente
dopo la modifica di una tabella, aveva smesso di funzionare.
Lorenzo Benaglia e AlessandroD mi avevano dato una mano per la ricerca del
problema e vista la query mi avevano consigliato di semplificarla.
Seguito questo consiglio la query ha ripreso a funzionare.
Oggi ho deciso di esportare quella query in un altro database di una azienda
"sorella" e in quel databse la query non funziona più.
Premesso che SQLserver è la versione 7 con i medesimi aggiornamenti. Le
uniche differenze sono che SQLserver è installato su un server diverso, ma
con medesimo sistema operativo (NT4), e che la tabella che pensavo fosse la
causa del problema in questo data base non è stata modificata.
Qui di seguito potete vedere la query. La query non funziona se eseguita da
access, ne tantomeno se eseguita dal query analyzer.
***************************************************************
declare @Azienda as varchar(3), @Utente as varchar(20),
@DataDa as datetime, @DataA as datetime,
@AreaDa as varchar(3), @AreaA as
varchar(3),
@LineaDa as varchar(3), @LineaA as
varchar(3),
@TipoDa as varchar(3), @TipoA as
varchar(3),
@FamigliaDa as varchar(3), @FamigliaA as
varchar(3),
@ProdottoDa as varchar(20), @ProdottoA as
varchar(20),
@AgenteDa as varchar(4), @AgenteA as
varchar(4),
@NazioneDa as varchar(50), @NazioneA as
varchar(50),
@ZonaDa as Varchar(3), @ZonaA as
Varchar(3),
@ProvinciaDa as varchar(2), @ProvinciaA as
varchar(2),
@ClienteDa as Varchar(12), @ClienteA as
Varchar(12),
@DestinDa as varchar (5), @DestinA as
varchar (5),
@TipoDestinDa as varchar(1), @TipoDestinA
as varchar(1),
@FlagProdNoTarget as varchar(5),
@GrAcqDa as varchar(10), @GrAcqA as
varchar(10),
@TipoCliDa as varchar(3), @TipoCliA as
varchar(3),
@SettMercDa as varchar(3), @SettMercA as
varchar(3)
Set @Azienda = '900'
Set @Utente = 'Utente'
Set @DataDa = '2002-01-01'
Set @DataA = '2002-01-31'
Set @AreaDa = 'UNI'
Set @AreaA = 'UNI'
Set @LineaDa = ''
Set @LineaA = 'ZZZ'
Set @TipoDa = ''
Set @TipoA = 'ZZZ'
Set @FamigliaDa = ''
Set @FamigliaA = 'ZZZ'
Set @ProdottoDa = ''
Set @ProdottoA = 'ZZZZZZZZZZZZZZZZZZZZ'
Set @AgenteDa = '011'
Set @AgenteA = '011'
Set @NazioneDa = ''
Set @NazioneA = 'ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ'
Set @ZonaDa = ''
Set @ZonaA = 'ZZZ'
Set @ProvinciaDa = ''
Set @ProvinciaA = 'ZZ'
Set @ClienteDa = ''
Set @ClienteA = 'ZZZZZZZZZZZZ'
Set @DestinDa = ''
Set @DestinA = 'ZZZZZ'
Set @TipoDestinDa = ''
Set @TipoDestinA = 'Z'
Set @FlagProdNoTarget = 'Vero'
Set @GrAcqDa = ''
Set @GrAcqA = 'ZZZZZZZZZZ'
Set @TipoCliDa = ''
Set @TipoCliA = 'ZZZ'
Set @SettMercDa = ''
Set @SettMercA = 'ZZZ'
-- estrazione dati richiesti dall'utente da fatture
drop table #St_FattMensCli_Estraz
Select WSDFR.AreaCommerciale,
WSDFR.Agente,
WSDFR.NazDestin,
WSDFR.ZonaDestin,
WSDFR.ProvDestin,
WSDFR.Cliente,
WSDFR.DescrCliente,
WSDFR.GruppoAcq,
WSDFR.TipoCli,
WSDFR.SettMerc,
WSDFR.CDestin,
WSDFR.DescrDestin,
WSDFR.TipoDestin,
WSDFR.EsclStatis,
WSDFR.EsclTarget,
WSDFR.ValoreNetto,
WSDFR.TpDocum,
WSDFR.VCambioITL,
WSDFR.VCambioEUR,
WSDFR.MeseFatt,
WSDFR.Posizione
into #St_FattMensCli_Estraz
From W_St_DocFatt_Righe WSDFR with(nolock)
Where WSDFR.Dtdocum between @DataDa and @DataA and
WSDFR.AreaCommerciale between @AreaDa and @AreaA and
WSDFR.LineaProdotto between @LineaDa and @LineaA and
WSDFR.TipoProdotto between @TipoDa and @TipoA and
WSDFR.FamigliaProdotto between @FamigliaDa and @FamigliaA and
WSDFR.Prodotto between @ProdottoDa and @ProdottoA and
WSDFR.Agente between @AgenteDa and @AgenteA
drop table #St_FattMensCli_Estraz
La query funziona se vengono eliminate le seguenti righe
WSDFR.TipoProdotto between @TipoDa and @TipoA and
WSDFR.FamigliaProdotto between @FamigliaDa and @FamigliaA and
****************************************************************************
********
Credo di trovarmi in una situazione assurda.
Qualcuno mi può dare qualche informazione?
Grazie
Ciao
Eugenio
Andrea Montanari
"Eugenio" <Ci...@Eugenio.it> ha scritto nel messaggio
news:c8ijtm$c3q$1...@lacerta.tiscalinet.it...
>...
>...
probabilmente SQL Server ti ritorna anche un errore... che probabilmente
coincide con la possibilita' di effettuare un cast corretto dei valori nelle
2 operazione di comparazione...
se potesti postare anche il DDL della tabella "incriminata" sarebbe
probabilmente piu' semplice individuare il problema..
saluti
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtm http://italy.mvps.org
DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply
AlessandroD
news:c8ijtm$c3q$1...@lacerta.tiscalinet.it...
> Qui di seguito potete vedere la query. La query non funziona se eseguita
da
> access, ne tantomeno se eseguita dal query analyzer.
>
la clausola into #?
> [...]
> Where WSDFR.Dtdocum between @DataDa and @DataA and
> WSDFR.AreaCommerciale between @AreaDa and @AreaA and
> WSDFR.LineaProdotto between @LineaDa and @LineaA and
> WSDFR.TipoProdotto between @TipoDa and @TipoA and
> WSDFR.FamigliaProdotto between @FamigliaDa and @FamigliaA and
> WSDFR.Prodotto between @ProdottoDa and @ProdottoA and
> WSDFR.Agente between @AgenteDa and @AgenteA
>
> La query funziona se vengono eliminate le seguenti righe
>
> WSDFR.TipoProdotto between @TipoDa and @TipoA and
> WSDFR.FamigliaProdotto between @FamigliaDa and @FamigliaA and
>
>
> Credo di trovarmi in una situazione assurda.
> Qualcuno mi può dare qualche informazione?
>
Lourdes? :-)
Scusa per la battuta stupida, a parte contattare il PSS che magari potrebbe
spiegarti il perché vero del tuo problema, potresti provare a non usare il
between ma la coppia di operatori >= e <=.
Ma già che ci sei potresti postare anche lo script delle tabelle/viste
interessate dalla query?
In bocca al lupo,
Alessandro
AlessandroD
Ma perché lo usi? Rischi di avere dati relativi a fatture che non sono
consistenti se la tua query gira mentre qualcuno sta fatturando...
Ciao, Alessandro
Eugenio
> probabilmente SQL Server ti ritorna anche un errore... che probabilmente
> coincide con la possibilita' di effettuare un cast corretto dei valori
nelle
> 2 operazione di comparazione...
Non ritorna nessun errore. Semplicemente non termina.
> se potesti postare anche il DDL della tabella "incriminata" sarebbe
> probabilmente piu' semplice individuare il problema..
> saluti
La tabella incriminata non è stata modificata su questo database, quindi non
è più incriminata.
Comunque nell'altro database erano stati aggiunti solo tre campi bit che non
vengono presi in considerazione nè da questa query, nè dalla vista
"W_St_DocFatt_Righe" da cui seleziono i dati.
Grazie
Ciao
Eugenio
Eugenio
Ciao Alessandro, eccomi di nuovo.
> >
> Nel senso che ci impiega "una vita", anche considerando la sola select
senza
> la clausola into #?
>
Mentre scrivo è finalmente terminata la query. Ha impiegato 30 minuti.
Tolte quelle due righe impiega 9 secondi.
Il risultato non cambia se escludo la clausola into #.
La curiosità è che le righe da eliminare in realtà sono intercambiabili,
cioè posso eliminare due righe diverse e la query funziona. E' come se la
Where non potesse considerare più di cinque condizioni.
E' vero che il database di questa azienda è doppio del nostro, ma in fino a
due settimane fa impiegava 10 secondi.
> > [...]
> > Where WSDFR.Dtdocum between @DataDa and @DataA and
> > WSDFR.AreaCommerciale between @AreaDa and @AreaA and
> > WSDFR.LineaProdotto between @LineaDa and @LineaA and
> > WSDFR.TipoProdotto between @TipoDa and @TipoA and
> > WSDFR.FamigliaProdotto between @FamigliaDa and @FamigliaA and
> > WSDFR.Prodotto between @ProdottoDa and @ProdottoA and
> > WSDFR.Agente between @AgenteDa and @AgenteA
> >
> > La query funziona se vengono eliminate le seguenti righe
> >
> > WSDFR.TipoProdotto between @TipoDa and @TipoA and
> > WSDFR.FamigliaProdotto between @FamigliaDa and @FamigliaA and
> >
> >
> > Credo di trovarmi in una situazione assurda.
> > Qualcuno mi può dare qualche informazione?
> >
> Lourdes? :-)
No, porta sfiga!
Qualche hanno fa sono stato in Portogallo, e nel viaggio di ritorno ho fatto
Fatima, Santiago e Lourdes. Non è stato un anno fantastico, anzi.
> Scusa per la battuta stupida, a parte contattare il PSS che magari
potrebbe
> spiegarti il perché vero del tuo problema, potresti provare a non usare il
> between ma la coppia di operatori >= e <=.
Tra poco dovrò rinunciare anche alla where. Infatti il problema è lì.
PSS: mi trovo in un'altra situazione assurda. Il PSS vuole il grano prima di
prendere in considerazione la mia domanda e la proprietà non mi fornisce il
grano per porre la domanda. In sostanza dovrei usare i miei soldi, ma io
sono un dipendente. Inoltre la volta scorsa il problema si era risolto e
quindi per loro sono solo io un'incapace :-)) (eh, i capi!).
> Ma già che ci sei potresti postare anche lo script delle tabelle/viste
> interessate dalla query?
> In bocca al lupo,
> Alessandro
>
>
Questa è la prima vista
CREATE VIEW dbo.W_St_DocFatt_TestDoc
AS
SELECT (DATEPART (yyyy, PFT.DataFattura)) as AnnoFatt,
(DATEPART (mm, PFT.DataFattura)) as MeseFatt,
PFT.Tipodoc AS TpDocum,
PFT.NroFattura AS NrDocum,
PFT.DataFattura AS DtDocum,
TTD.Segno as SegnoDocum,
PFT.ClienteFornitore AS Cliente,
CUS.Descr AS DescrCliente,
CUS.Stato AS NazCliente,
CUS.ZONA AS ZonaCliente,
CUS.Provincia AS ProvCliente,
CUS.CAP AS CAPCliente,
isnull(CUS.Settmerc,'') as Settmerc,
isnull(CUS.TipoCli,'') as TipoCli,
isnull(CUS.gruppostat,'') as GruppoStat,
isnull(CUS.GruppoAcq,'') as GruppoAcq,
PFT.CodAgente AS Agente,
isnull(FTT.Valuta,PFT.Valuta) AS CValuta,
isnull(HC.Cambio, 1) AS VCambioITL,
isnull(HC.CambioEuro, 1936.27) AS VCambioEUR,
PFT.CausaleMaga as Causale
FROM P_FattureT PFT with (nolock)
INNER JOIN CUSTOME CUS with (nolock) ON
PFT.ClienteFornitore = CUS.Cod
INNER JOIN TB_TipologiaDoc TTD with (nolock) ON
PFT.TIPODOC = TTD.Tipo
LEFT OUTER JOIN FA_Totali_T FTT with (nolock) ON
PFT.NroFattura = FTT.NroFattura
INNER JOIN HCambi HC with (nolock) ON
PFT.Valuta=HC.Valuta and
PFT.Datafattura between HC.Dagiorno and HC.Agiorno
WHERE PFT.TipoIvaCliente <> 'F0'
GROUP BY PFT.Tipodoc,TTD.Segno,
PFT.NroFattura,PFT.DataFattura,
PFT.ClienteFornitore, CUS.Descr,
CUS.Codcee, CUS.Stato, CUS.ZONA,
CUS.Provincia, CUS.CAP,
isnull(CUS.Settmerc,''),
isnull(CUS.TipoCli,''),
isnull(CUS.gruppostat,''),
isnull(CUS.GruppoAcq,'') ,
PFT.CodAgente,
isnull(FTT.Valuta, PFT.Valuta),
HC.Cambio,
HC.CambioEuro,
PFT.CausaleMaga
La vista precedente è necessaria per generare la lista successiva che è
quella utilizzata dalla query
CREATE VIEW dbo.W_St_DocFatt_Righe
AS
SELECT
WDFT.AnnoFatt,
WDFT.MeseFatt,
WDFT.TpDocum,
WDFT.NrDocum,
WDFT.DtDocum,
isnull(PFR.TipoDDT,WDFT.TpDocum) AS TpDDT,
isnull(PFR.NroBolla,WDFT.NrDocum) AS NrDDT,
isnull(PFR.DataBolla,WDFT.DtDocum) AS DtDDT,
WDFT.Cliente,
WDFT.DescrCliente,
WDFT.GruppoAcq,
WDFT.SettMerc,
WDFT.TipoCli,
isnull(PFR.Codind, '00') AS CDestin,
isnull(AIET.Ragsoccons,'') AS DescrDestin,
isnull(AIET.Nazionecons,'') AS NazDestin,
isnull(AIET.Zona,'') AS ZonaDestin,
isnull(AIET.PROVINCIA,'') AS ProvDestin,
isnull(AIET.Capcons,'') AS CapDestin,
isnull(UCD.TipoDestinatario,'') AS TipoDestin,
isnull(PFR.CodAgente,WDFT.Agente) as Agente,
PFR.AGENTE3 AS Procacciatore,
PFR.Agente2 AS CapoArea,
PFR.Posizione,
PFR.Cod AS Prodotto,
(isnull(PFR.Quantita,0)*PFR.Segno) as Quantita,
(isnull(PFR.Prezzo,0)*PFR.Segno) as Prezzo,
isnull( PFR.Sconto1,0) as Sc1,
isnull( PFR.Sconto2,0) as Sc2,
isnull( PFR.Sconto3,0) as Sc3,
isnull( PFR.Sconto4,0) as Sc4,
isnull( PFR.Sconto5,0) as Sc5,
isnull( PFR.Sconto6,0) as ScMC,
isnull( PFR.Sconto7,0) as ScIN1,
isnull( PFR.Sconto8,0) as ScIn2,
WDFT.VCambioITL,
WDFT.VCambioEUR,
(PFR.ValoreNetto) as ValoreNetto,
UPP.AreaCommerciale,
UPP.LineaProdotto,
UPP.TipoProdotto,
UPP.FamigliaProdotto,
PFR.ProvvAge1,
PFR.ProvvAge2,
PFR.ProvvAge3,
PFR.CodIva,
PFR.Deposito as Magazzino,
WDFT.Causale,
convert(varchar(1),PFR.EsclStatis) as EsclStatis ,
convert(varchar(1),PFR.EsclTarget) as EsclTarget
FROM P_FattureR PFR with (nolock)
INNER JOIN W_St_DocFatt_TestDoc WDFT with (nolock) ON
PFR.NroFattura = WDFT.NrDocum
INNER JOIN AN_INDCON_Ed_T AIET with (nolock) ON
WDFT.Cliente = AIET.Cliente AND
PFR.CodInd = AIET.Nunind
INNER JOIN UniCommDestin UCD with (nolock) ON
AIET.Cliente = UCD.Cliente AND
AIET.Nunind = UCD.Nunind
INNER JOIN P_prodotti PP with (nolock) ON
PFR.Cod = PP.Cod
INNER JOIN UniP_Prodotti UPP with (nolock) ON
PP.Cod = UPP.Cod
WHERE PFR.CodIva <> 'F0'
Mi ripeto: nei miei 20 anni d'esperienza non mi sono mai trovato in una
situazione del genere. Ci voleva proprio Microsoft.
Grazie Alessandro
Ciao
Eugenio
Eugenio
Vero, ma senza vanno in deadlock le altre applicazioni, fatturazione
compresa.
La durata dell'elaborazione di tutta la SP (di cui questa query è parte) è
sicuramente superariore al minuto.
Non per ripetermi, ma gestione dei blocchi di SQL server è una meraviglia
:-))))
Grazie
Ciao
Eugenio
AlessandroD
>
> Ciao Alessandro, eccomi di nuovo.
>
> > >
> > Nel senso che ci impiega "una vita", anche considerando la sola select
> senza
> > la clausola into #?
> >
>
> Mentre scrivo è finalmente terminata la query. Ha impiegato 30 minuti.
> Tolte quelle due righe impiega 9 secondi.
>
Così per confrontate che differenze ci possono essere nei due casi?
Non ho detto che il confronto sia facile da fare, ma avendo i due piani a
disposizione puoi sicuramente cercare di capirci qualcosa di più.
> Il risultato non cambia se escludo la clausola into #.
> La curiosità è che le righe da eliminare in realtà sono intercambiabili,
> cioè posso eliminare due righe diverse e la query funziona. E' come se la
> Where non potesse considerare più di cinque condizioni.
> E' vero che il database di questa azienda è doppio del nostro, ma in fino
a
> due settimane fa impiegava 10 secondi.
>
Ma, secondo me per qualche motivo è cambiata la distribuzione dei dati e SQL
non è capace di azzeccare un piano di eseguzione appropriato.
Sai perché te lo dico? Giusto l'inizio della settimana mi sono trovato in
una condizione simile alla tua. Stessa query che ha girato in tempi
accettabili, in un DB ci impiega 6 minuti! Soluzione? Ho riscritto la query
spaccandola in più parti, ora gira negli stessi tempi in tutti i DB.
Ripeto, da ignorante secondo me a volte SQL Server canna la generazione del
piano di eseguzione e si "incarta"...
Ed è anche vero che, almeno per SQL 2000, esistono delle fix documentate che
servono per correggere "stalli" durante l'eseguzione di query che presentano
determinate caratteristiche, ovvio che le query in questione sono complesse.
Quindi non escludo che in certe circostanze si possa essere in presenza di
bachi o imperfezioni correggibili con un sp, e per SQL dovrebbe arrivare a
fine anno. Se riesco vedo di mettermi via gli ambienti dove ho riscontrato
questi comportamenti per me anomali, in modo da riverificare il tutto post
applicazione del sp.
Per quelle che sono le mie capacità vedrò di dare un occhio alle tue viste
per vedere se c'è qualcosa che "stona". Ma se intanto ti trovi nella
condizione di postare anche la struttura delle tabelle sarebbe ancora
meglio.
Per via del PSS, peccato che i tuoi capi non abbiano la sensibilità
necessaria per capire la condizione che ti trovi ad affrontare, ma, come si
dice, chi non sa fare comanda, quindi in un certo senso è anche naturale che
il loro (dei tuoi capi) comportamento sia questo...
Ciao, Alessandro
Eugenio
> >
> Vero che hai attivato la visualizzazione del piano di eseguzione?
> Così per confrontate che differenze ci possono essere nei due casi?
> Non ho detto che il confronto sia facile da fare, ma avendo i due piani a
> disposizione puoi sicuramente cercare di capirci qualcosa di più.
>
Confesso che il piano di esecuzione l'ho usato così poche volte dal '99,
cioè da quando uso SQL7, perchè non ne ho mai avuto bisogno e anche perchè
non ne ho mai ricavato informazioni utili, probabilmente anche per
ignoranza.
> Ma, secondo me per qualche motivo è cambiata la distribuzione dei dati e
SQL
> non è capace di azzeccare un piano di eseguzione appropriato.
> Sai perché te lo dico? Giusto l'inizio della settimana mi sono trovato in
> una condizione simile alla tua. Stessa query che ha girato in tempi
> accettabili, in un DB ci impiega 6 minuti! Soluzione? Ho riscritto la
query
> spaccandola in più parti, ora gira negli stessi tempi in tutti i DB.
La query in questione è già stata riscritta due settimane fa. Il fatto è che
su un server funziona sull'altro no.
Inoltre all'inizio ho parlato di aziende sorelle, in realtà l'azienda in
questione è quella che ha ceduto l'attività a quella nella quale lavoro ora
e i dati da allora non sono cambiati. Sono passati 2 anni. Il database è
quello di due anni fa.
> Ripeto, da ignorante secondo me a volte SQL Server canna la generazione
del
> piano di eseguzione e si "incarta"...
> Ed è anche vero che, almeno per SQL 2000, esistono delle fix documentate
che
> servono per correggere "stalli" durante l'eseguzione di query che
presentano
> determinate caratteristiche, ovvio che le query in questione sono
complesse.
> Quindi non escludo che in certe circostanze si possa essere in presenza di
> bachi o imperfezioni correggibili con un sp, e per SQL dovrebbe arrivare a
> fine anno. Se riesco vedo di mettermi via gli ambienti dove ho riscontrato
> questi comportamenti per me anomali, in modo da riverificare il tutto post
> applicazione del sp.
>
> Per quelle che sono le mie capacità vedrò di dare un occhio alle tue viste
> per vedere se c'è qualcosa che "stona". Ma se intanto ti trovi nella
> condizione di postare anche la struttura delle tabelle sarebbe ancora
> meglio.
Non vorrei portati via più tempo di quello che mi hai già concesso. Inviare
la struttura di quelle tabelle non ti darebbe nessuna informazione
interessante e quindi mi sembra inutile. Posso solo dire che alcune di
queste hanno numerose colonne (quelle delle fatture), ma credo che tante
aziende abbiano tabelle con tante colonne
Quello che mi fa impazzire è non riuscire a trovare il guasto. E' come
andare dal meccanico, smontare tutto il motore, e non trovare la parte
guasta. Impossibile!!!
E quel che più sconcerta che su entrambi i servers accade la stessa cosa nel
medesimo periodo. Sembra che le SP abbiano la scadenza.
> Per via del PSS, peccato che i tuoi capi non abbiano la sensibilità
> necessaria per capire la condizione che ti trovi ad affrontare, ma, come
si
> dice, chi non sa fare comanda, quindi in un certo senso è anche naturale
che
> il loro (dei tuoi capi) comportamento sia questo...
> Ciao, Alessandro
Eh, già! Il problema è che secondo loro sono io che non so fare, perchè come
mi dico: il mio amico mia detto... bla, bla, bla.
Beh, è la situazione classica della maggior parte delle piccole aziende
italiane.
Italiaaaa,Italiaaaaa...
:-))
Grazie Alessandro
Ciao
Eugenio