Salve,
avere il db in simple recovery model (con un peso dati veramente effimero, circa 46mb???) ed un log di 3 GB, indica in effetti che c'e' un'intensissima attivita' di IUD... cio' comporta ovviamente catene di iscrizioni nel tlog e, con una catena cosi' lunga, mi viene anche da pensare a transazioni molto lunghe e/o mal strutturate, visto che ad ogni commit, tendenzialmente in simple recovery si andrebbero a liberare i virtual log precedenti all'interno del file di log...
se uno shrink riesce a diminuire di "cosi' poco" (relativamente allo spazio dati, 46 MB????), e poco dopo torna a 3GB, tendenzialmente cio' indica che questa e' la dimensione minima richiesta dall'alta e frammentata attivita' IUD... ma mi e' particolare il rapporto tra le dimensioni delle data pages ed il t-log...
guarderei anche
https://dallasdbas.com/why-is-my-sql-log-file-huge e
https://www.techrepublic.com/blog/the-enterprise-cloud/help-my-sql-server-log-file-is-too-big/, "just in case", anche se le potenziali cause in questa lista le vedo solo per "lunga coda transazionale", "problemi di disco"
anche
https://stackoverflow.com/questions/38590066/log-file-is-growing-with-simple-recovery-mode riporta le medesime indicazioni...
quindi, come gia' @oregon, per favore verifica il recovery model, che sia a simple (e nel caso non lo sia effettua un bel backup del log per troncare i virtual log), poi, probabilmente, va guardato il codice applicativo che esegue queste massive operazioni IUD...
ah... e non puoi escludere una tabella particolare dalle iscrizioni nel tlog relativamente alle attivita' IUD che la coinvolgano.
salutoni romagnoli
--
Andrea