Rendi SQL Server più veloce nella manipolazione dei dati - disattiva la registrazione delle transazioni?

Question

Uso SQL Server 2005 come archivio dati per un sacco di dati su cui lavoro analitico. Questo non è un database transazionale in quanto non lo sto colpendo con aggiornamenti o acquisendo dati in tempo reale. Ottengo qualche concerto di dati dai miei clienti, li carico in SQL Server e faccio una serie di manipolazioni. Prendo quindi alcuni di questi dati e li inserisco in R, dove faccio la maggior parte delle mie analisi. Quindi spingo un po 'di dati in tabelle in SQL Server e forse faccio un join o due.

Ho un bel po 'di tempo con i log di SQL Server che diventano grandi e presumo che ci voglia un po' di overhead per crearli. Come posso configurare SQL Server in modo che venga eseguito con poca o nessuna registrazione? Se le cose si corrompono, sono felice di iniziare dall'inizio. Qualche idea su come rendere tutto più veloce?

BTW, non c'è bisogno di dirmi come ridurre i registri, lo sto già facendo. Ma vorrei che non dovessi fare i log in primo luogo. Sto solo utilizzando il DB per ospitare i dati perché è troppo grande per adattarsi alla memoria in R.

Dovrei utilizzare un DB più semplice del server Sql? Sentiti libero di dirmi che sto uccidendo una formica con un martello. Ma per favore raccomandate un martello di dimensioni più appropriate. :)

Answer 1

Come configurare SQL Server in modo che venga eseguito con registrazione minima o nulla? I

Non credo che si possa.

Tuttavia, se si configura il database (ciascun database su un server può essere diverso) per i backup semplici il file di registro non crescerà finché non lo si esegue il backup. Questo viene fatto impostando la modalità di ripristino su "semplice".

Con semplici backup il registro viene utilizzato solo per conservare lo stato delle transazioni fino a quando non vengono completamente scritte nel database principale.

Answer 2

È possibile ridurre al minimo il consumo del registro nel server SQL modificando il modello di recupero del database in modo semplice per visualizzare questo link. Dal momento che non hai a che fare con la concorrenza e le transazioni hai considerato Microsoft Access?

Answer 3

per ridurre al minimo la registrazione utilizzare il modello di recupero semplice e svolgere il lavoro in lotti.

Answer 4

Un modo per evitare la registrazione quando si lavora con insiemi di dati di grandi dimensioni, sta usando SELECT/INTO. Creerà una nuova tabella ma nessuno di questi verrà registrato.

ci sono alcune cose da tenere d'occhio in questo modo:

• colonne calcolate diventano colonne di dati regolari dovrebbe essere stabilita anche

di indicizzazione e di identità colonne Se fatto correttamente può salvare non solo lo spazio ma il tempo di elaborazione.

L'alternativa è qualcosa di simile a quello che sto facendo in questo momento, come un esempio:

UPDATE [MyTable] 
SET [Message] = REPLACE([Message], N'Content_Type', N'Content-Type') 

funziona bene, ma aggiorna l'intera tabella creando una serie enorme di transazione, invece si può fare:

DECLARE @IDs TABLE ([id] int) 
DECLARE @Batch TABLE ([id] int) 

INSERT INTO @IDs ([ID]) SELECT [ID] FROM [MyTable] 

WHILE EXISTS (SELECT TOP 1 [ID] FROM @IDs) 
BEGIN 
    INSERT INTO @Batch ([ID]) SELECT TOP 1000 [Id] FROM @IDS 

    UPDATE [MyTable] 
    SET [Message] = REPLACE([Message], N'Content_Type', N'Content-Type') 
    WHERE [Id] IN (SELECT [Id] FROM @Batch) 

    DELETE @IDs WHERE [Id] IN (SELECT [Id] FROM @Batch) 
    DELETE @Batch 
END 

Questo aggiorna la tabella 1.000 righe alla volta mantenendo le dimensioni della transazione verso il basso.

Answer 5

Non renderete il vostro SQL Server quasi più veloce disattivando la registrazione delle transazioni, ma le dimensioni del registro possono essere ridotte andando alla modalità di recupero con registrazione semplice o in blocco, come già suggerito da altri.

La mia opinione su questo è che non si dovrebbe mai girare la modalità di recupero completo tranne in casi speciali come il tuo quando non è assolutamente necessario.

Il motivo principale per questo è che il registro delle transazioni in pieno recupero può essere l'unica speranza di ripristino in caso di accidentalmente eseguito UPDATE, DELETE o TRUNCATE in cui non si dispone di backup o tutti i dati non sono nei backup.

Ci sono diversi thread su questo argomento in cui il log delle transazioni di lettura era l'ultima speranza per il ripristino.

How can I rollback an UPDATE query in SQL server 2005?

How to undo a delete operation in SQL Server 2005?

Ancora una volta, nel tuo caso specifico questo probabilmente non è un problema, ma la mia ipotesi è che può essere utile ad altri.

Answer 6

c# codice utilizzando EntityFramework per configurare il database come Richards risposta descrive:

using (var dbInstance = new YourEntityFrameworkDB_Context()) 
{ 
    var sqlConfigConn = dbInstance.Database.Connection as SqlConnection; 
    sqlConfigConn.Open(); 

    using (var sqlCmd = new SqlCommand()) 
    { 
     sqlCmd.Connection = sqlConfigConn as SqlConnection; 
     sqlCmd.CommandText = String.Format("ALTER DATABASE model SET RECOVERY SIMPLE"); 
     var result = sqlCmd.ExecuteNonQuery(); 
    } 
    sqlConfigConn.Close(); 
} 

e di verificare se fosse successo solo iniziare Management Studio ed eseguire:

EDIT Feb 2018:

MSDN descrizione abo ut il modello di recupero

╔══════════╦══════════════════════╦══════════════════════════════════════════╗ 
║ Recovery ║ Description  ║  Recover to a point in time?   ║ 
║ model ║      ║           ║ 
╠══════════╬══════════════════════╬══════════════════════════════════════════╣ 
║ Simple ║ No log backups  ║ Can recover only to the end of a backup. ║ 
║   ║      ║           ║ 
║ Full  ║ Requires log backups ║ Can recover to a specific point in time, ║ 
║   ║      ║ assuming that your backups are complete ║ 
║   ║      ║ up to that point in time.    ║ 
║   ║      ║           ║ 
║ Bulk  ║ Requires log backups ║ Can recover to the end of any backup. ║ 
║ logged ║      ║           ║ 
╚══════════╩══════════════════════╩══════════════════════════════════════════╝