salve,
spyto wrote:
Hai ragione ho scritto veramente da cane, ma dovevo vedere diverse cose e mi sono distratto 
succede, non ti preoccupare
In pratica quello che si potrebbe fare come primo step per sbloccare la situazione e pulire il DB visto che vi sono molti record non cancellati, ovvero loro inseriscono dati, li processano e poi li storicizzano. Ma nel momento che il dato viene passato allo storico l'originale rimane nella tabella principale e si creano record inutili.
ok, in questo caso potresti beneissimo, sempre che l'applicativo lo gradisca, eliminare come hai indicato le righe gia' aggregate/storicizzate..
Altra cosa vi sono query con SELECT *, ma li dipende dall'applicativo, vediamo se riesco a risalire a chi l'ha fatto per chiedere
spiegazioni in merito.
molto bene
Sul server hanno montato il DB e anche SharePoint SQL, ma il vero problema nasce proprio dal fatto che questi signori si sono dimenticati di manutenere il DB.
non penso tocchi a loro.. solitamente queste sono incombenze che spettano alo staff IT interno o, nella "peggiore delle ipotesi" e cioe' nei casi in cui tutto "dipenda dall'applicativo gestionale" (e non da SharePoint, ovviamente), all'applicativo stesso, che dovrebbe includere delle funzionalita' amministrative...
Ad oggi siamo arrivati a queste conclusioni:
1. DB Molto grande a causa di file temporanei, log e altro mai deletati e lasciati li a diventare sempre piu' mastodontici. Stiamo parlando di un file di log con 4 milioni di record mai letto da nessuno.
stiamo sicuramente parlando di un modello di recovery "full" impostato per le basi dati in argomento, e, in questo caso, sarebbe consigliabile un backup del log delle transazioni, ovviamente seguito da un backup completo... visto che ci sei, consiglierei anche di valutare la creazione di un piano di backup che consenta di agevolare situazioni di disaster recovery che, da quanto dici, non mi pare sia stato implementato..
valuterei la possibilita' di definire chiaramente le responsabilita' amministrative sul sistema in generale, cosi' da documentare le rispettive responsabilita' in toto..
2. La macchina su cui e' montato il DB e' mal settata swappa sempre e la CPU la si ritrova quasi sempre al 100% con programmi inutili che ci girano sopra.
segare ...
3. Le query hanno un tempo medio che va dai 5 sec per le piu piccole, ai 40-50 sec per le piu grandi.
4. Le query sono mal costruite perche' per ogni click fatto dall'utente tirano su quasi tutta l'anagarfica degli utenti richiedendo sempre i stessi dati, in questo modo per inserire un ordine di produzione si arriva a toccare 1 ora.
questa e' sicuramente una modifica da richiedere a chi ha sviluppato l'applicativo..
5. Non ci sono indici sul DB.
questa e' piu' che sicuramente una modifica da richiedere SUBITO a chi ha sviluppato l'applicativo..
6. A causa di tutti i difetti sopra elencati alcune query mandano il Time Out l'applicativo facendo ripetere la stessa operazione all'utente 5-8 volte.
questa e' sicuramente una modifica da richiedere a chi ha sviluppato l'applicativo..
7. Riscontriamo che ogni DB ha una media di 30-40 Functions.
tendenzialmente, nulla da eccepire... ovviamente andrebbe valutato in loco..
8. Riscontriamo che il DB dei Log non viene aperto e viene visualizzato un errore di Time Out.
il log non viene "aperto" da nessuno se non da SQL Server stesso... cosa sicuramente e' necessaria e' la definizione di una corretta politica di backup al fine di limitare i danni derivanti da disastri accidentali..
9. La dimensione complessiva del DB e' di 54 GB.
tendenzialmente, nulla da eccepire... puo' avere senso
saluti
