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...

Visto che come al solito nessuno si ricorda niente e non si trova manco un foglio che faccia da storico. Quello che posso ipotizzare come hai detto te e' che sia stato dato in mano la gestione del DB alla societa' che ha fatto l'applicativo e poi causa chiusura del contratto nessuno si e' preoccupato per verificare la situazione.
Il nostro staff ha in carico il server e si occupa della gestione di quest'ultimo dal punto di vista HW, quindi ci siamo persi un pezzo di staff ;)

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..

Si probabilmente i log hanno la loro utilita' in caso di disaster recovery. In questa situazione abbiamo due cluster che in caso di guasto del Server1 viene subito attivato il Server2. Allo stato attuale anche detta situazione e' mal gestita perche' sul Server2 troviamo un DB di pochi KB.

Da un analisi piu' approfondita (ovvero mi sono spulciato tutto il DB) ho trovato qualche indice ma sono pochissimi in lina di max 1 su 20 tabelle

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..

Mi ero espresso male, ho il DB dei LOG con 6 milioni di record e non riesco manco ad aprilo per vedere cosa ce dentro, infatti uso SELECT TOP :)


Una domanda, usando Profiler vedo che ci sono query ad esempio che hanno una Duration di 20 sec, mentre il tempo di Cpu e' di 10 sec, perche' ce questo grande divario di tempo?

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...

Visto che come al solito nessuno si ricorda niente e non si trova manco un foglio che faccia da storico. Quello che posso ipotizzare come hai detto te e' che sia stato dato in mano la gestione del DB alla societa' che ha fatto l'applicativo e poi causa chiusura del contratto nessuno si e' preoccupato per verificare la situazione.
Il nostro staff ha in carico il server e si occupa della gestione di quest'ultimo dal punto di vista HW, quindi ci siamo persi un pezzo di staff ;)

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..

Si probabilmente i log hanno la loro utilita' in caso di disaster recovery. In questa situazione abbiamo due cluster che in caso di guasto del Server1 viene subito attivato il Server2. Allo stato attuale anche detta situazione e' mal gestita perche' sul Server2 troviamo un DB di pochi KB.

Da un analisi piu' approfondita (ovvero mi sono spulciato tutto il DB) ho trovato qualche indice ma sono pochissimi in lina di max 1 su 20 tabelle

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..

Mi ero espresso male, ho il DB dei LOG con 6 milioni di record e non riesco manco ad aprilo per vedere cosa ce dentro, infatti uso SELECT TOP :)


Una domanda, usando Profiler vedo che ci sono query ad esempio che hanno una Duration di 20 sec, mentre il tempo di Cpu e' di 10 sec, perche' ce questo grande divario di tempo?