2011-01-12 3 views
0

J'ai un serveur Web avec SQL 2008 l'exécution d'un SQL simulé 2005 db, et j'ai SQL 2005 db local pour un environnement de test. Cela m'oblige à utiliser des scripts pour sauvegarder/restaurer des données à tester, car les sauvegardes de serveur de 2008 ne sont pas restaurées sur un serveur 2005.SQL Log et TRANSACTIONS ACTIVE

Quand je lance cette requête SQL pour réduire la taille d'une table sur mon Web production SQL Server (2008)

DELETE FROM TickersDay 
WHERE (DATEDIFF(day, TickersDay.[date], GETDATE()) >= 8) 
GO 

Je reçois ce message:

Msg 9002, Level 17, State 4, Line 3 
The transaction log for database 'VTNET' is full. To find out why space in the log 
cannot be reused, see the log_reuse_wait_desc column in sys.databases 

Il arrive quand je publier des scripts aussi parfois.

Quand je lance cette commande SQL j'obtenir le résultat suivant:

SELECT [name], recovery_model_desc, log_reuse_wait_desc 
FROM sys.databases 

RÉSULTAT:

[name]  recovery_model_desc  log_reuse_wait_desc 

VTNET SIMPLE      ACTIVE_TRANSACTION 

Voici mes questions et problèmes:

  1. I get it .. J'ai une instruction de transaction nécessitant une commande de restauration

< si @@ trancount> 0 Rollback> .. mais j'ai 100 procédures stockées donc avant de le faire ....

  1. EN ATTENDANT ... Comment puis-je éliminer ce problème ?? J'ai essayé de réécrire et j'ai essayé de sauvegarder le Db ...

  2. Comme vous pouvez le voir, il est en mode SIMPLE ... Je n'ai aucune idée de comment sauvegarder un fichier LOG ONLY ... (n'ont pas trouvé comment faire) ...

Répondre

1

Vous pourriez être en mesure de contourner ce problème simplement en obtenant SQL pAS pour traiter toute la table en utilisant l'index uniquement sur les dates requises pour être supprimé Reformuler pour être l'indice amical

DELETE FROM TickersDay 
WHERE TickersDay.[date] <= DATEADD(day, -8, GETDATE()) 
GO 

Si vous exécutez ce assez souvent (au moins tous les jours), alors il n'a qu'à traiter 1/9ème ou moins par un index sur TickersDay ([Date]) au lieu d'avoir à aller à travers la table entière si vous utilisez DATEDIFF sur le terrain.

Si cela provoque encore ceci:

Le journal des transactions pour la base de données « VTNET » est plein

Vous avez vraiment besoin d'augmenter la taille journal parce que je soupçonne que ce n'est pas réglé à croissance automatique et n'est pas assez grand pour cette opération. Soit cela ou commencez à chercher à supprimer les suppressions (en supposant à nouveau que vous avez un index à la date, donc cela ne cible efficacement que les 100 lignes), par exemple.

DELETE TOP (100) FROM TickersDay 
WHERE TickersDay.[date] <= DATEADD(day, -8, GETDATE()) 
GO 

Vous pouvez en boucle (en @@ rowcount> 0) ou tout simplement planifier plus souvent en arrière-plan ruisselant supprimer.

+0

merci pour votre explication détaillée et réponses (multiples) ... pas sûr de ce qui a fonctionné mais j'ai augmenté la taille (et utilisé sans restriction) et utilisé votre requête et ça fonctionne super! Assez de transactions non engagées bs ... Je vais m'inquiéter à ce sujet plus tard .. – CraigJSte