Re: Problema su lettura tabella in multiutenza

Fair87 ha scritto:
> Alessandro Cara ha scritto:
>> Fair87 ha scritto:
>>> Alessandro Cara ha scritto:
>>>> Fair87 ha scritto:
>>>>> Ciao a tutti, una domanda: come si può 'snellire' la sola lettura di una
tabellona su cui devo fare delle ricerche (è un catalogo....) in multiutenza? La
tabella è la base di una form richiamata da codice con una variabile d'ambiente
che passa la stringa SQL e la form è già in sola lettura (snapshot) solo che le
ricerche contemporanee sono mooooolto lente....consigli?
>>>>>
>>>> Perdonami ma non e' chiaro.
>>>> La ricerca su una stazione sola e' veloce?
>>>> Cos'e' la tabellona? (Volumi)
>>>> Che ricerche devi fare?
>>>> La query ha delle "IN"?
>>>> --
>>>> ac
>>> Scusa Alessandro, chiarisco: ho un catalogo in cui fare ricerche, composite
(titolo, autore, editore, anno di pubblicazione....) dove posso ricercare per
iniziale o per contenuto su tutti i campi. La tabella contiene circa 500000
righe, ogni riga circa 30 campi. In una LAN, una ricerca media per contenuto in
campi compositi richiede circa 10 sec, per iniziali circa 2. Se però attivo un
altro client (utilizzo XpUnlimited) anche la ricerca per iniziali (contemporanea
su 2 client) in un campo solo richiede + di 30/35 secondi. La clausola SQL è
senza IN, ed è impostata sulla tabella archivio, + outer join sulle tabelle di
decodifica. Per il filtro metto tutto nell'espressione WHERE, concatenando i
vari campi della form di ricerca. Ovviamente il WHERE può coinvolgere tutte le
tabelle dell'espressione SQL. Spero di aver chiarito un po' le cose....
>>> Intanto grazie!!
>>>
>> come direbbero gli americani "is a real pain in the ass".
>> A quanto dici ci sono 2 punti particolarmente critici
>> 1) La ricerca su tutti i campi, che immagino non sono tutti indexati
>> 2) Le join
>>
>> Non ho una soluzione pronta in tasca e credo bisogna cominciare a 
>> definire dove e' il "reale" problema
>> 1)
>> Sarebbe il caso di mettere su la tabella di "explain", che purtroppo non 
>> mi ricordo esattamente come attivare (forse c'e' qualcosa sul sito di 
>> Baraldi), per capire quali sono le strategie di accesso del DB.
>> 2)
>> Eliminare le join per capire quale incidenza hanno
>> 3)
>> Se non presenti, mettere su gli indici per le ricerche piu' frequenti
>> 3)
>> Se ci sono delle "or" sui criteri verificare se queste portano alla 
>> esclusione della lettura per indici e trovare un "workaround" (i.e. uso 
>> di union). Fermo restando che ricerche per like, mi sembra, portano 
>> nella maggioranza dei casi ad accesso per "tablescan".
>> 4) XPUnlimited e' quella roba che "surroga" il terminal server? Se e' 
>> cosi' diventa un fattore da osservare attentamente poiche' puo' essere 
>> un collo di bottiglia non indifferente
>> 5)
>> Sarebbe comunque il caso che ci fai vedere lo "skeleton" della query
>> 6)
>> Se non si riesce a trovare una "terapia" corretta, usare il bisturi e 
>> passare ad un DBMS piu' "DBMS"
>> --
>> ac
>>
>>
>>
>>
> Dunque: tutti i campi in cui posso ricercare sono indicizzati (infatti prima
nn si muoveva neanche in locale!!). 
Muy bien
XpUnlimited è una tecnologia TerminalServer, ma dovrebbe essere + 
leggera (in teoria....).
Maybe. Quando faccio qualsiasi cosa metto sempre le due colonne 
costi/ricavi. Il Terminal server e' una idea brillante ma dalla parte 
costi va scritto "carico della macchina server". Questo spiega il 
rallentamento multiutenza, avevo un "?" e quando hai citato xpunlimited 
e' stato risolto
  Sto anche provando l'accesso in multiutenza classico (un FE x ogni 
client) x vedere se c'è differenza.....
Ovviamente anche questo ha un costo, credo abbastanza elevato, visto i 
volumi della tabella "principe"

> Ho implementato anche il db su SQL server 2005 express (ma x ora solo in
locale) tramite ODBC e, ovviamente, le prestazioni sono un 'pochino'
diverse......tranne alcuna, ma sicuramente dovute alla mia scarsa conoscenza di
SQL server e l'architettura errata del db magari... La query te la posto....è
una ricerca abbastanza pesante x il sistema...niente OR solo AND. Intanto
grazie.....
excellent
> 
> *********INIZIO
> SELECT LIBRI_BASE.EAN, LIBRI_BASE.COD_ALT, LIBRI_BASE.AUTORE,
LIBRI_BASE.TITOLO, LIBRI_BASE.SUB_TITOLO, LIBRI_BASE.GIACENZA,
LIBRI_BASE.COLLANA, LIBRI_BASE.COLLANA_N, LIBRI_BASE.PREZZO, LIBRI_BASE.DISP_DA,
LIBRI_BASE.DISP_INT, LIBRI_BASE.DISP_CLESP, LIBRI_BASE.SCUOLA,
LIBRI_BASE.SPESE_FISSE, LIBRI_BASE.COLLOCAZIONE, LIBRI_BASE.ESCLUSO_CARD_COSMO,
LIBRI_BASE.ANNO_ED, LIBRI_BASE.ANNOTAZIONI, LIBRI_BASE.CURATORE,
LIBRI_BASE.ESCLUSO, LIBRI_BASE.VOLUME, EDITORI.RAG_SOC_E, TIPO_SCU.DESCRIZIO
FROM (LIBRI_BASE INNER JOIN EDITORI ON LIBRI_BASE.EDITORE = EDITORI.COD_EDIT)
INNER JOIN TIPO_SCU ON LIBRI_BASE.SCUOLA = TIPO_SCU.TIPO_SCU WHERE TITOLO LIKE
'*mare*' AND TITOLO LIKE '*legno*';
> **********FINE
> 
> Senza le join è tutto + veloce...ma ho solo i codici degli editori,
allegati.....e nn le descrizioni....avevo anche pensato di fare un db
'piatto'....ma proprio nn mi piace.......
uhmm....ho cercato di immaginare la applicazione.
La questione delle descrizioni, forse, potrebbe essere circumnavigata.
Immagino che le due tabelle di relazione non siano enormi e po' essere 
pensabile farla fare a dei controlli cbx (magari "locked").
Temo che una parte del problema, oltre le join, possa essere addebitato 
a quelle like nel criterio. Riesci a verificare la loro pesantezza?
Di li sara' difficile uscire a meno di "inventarsi" una cosa tipo "soundex".

> 
> Rigrazie...
>