Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur TIMEOUT sur DELETE

TIMEOUT sur DELETE

4 réponses
Avatar
SOW Olivier
Bonjour,

J'utilise SQL2K SP3a. Voici mon soucis,
Je possedes une base qui contient une table avec plus de 2 millions de
tuples.
Cette table est utilisée pour enregistrer des evenements provenant de
plusieurs sources.
Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
garde que les evenements des 30 derniers jours).
Ce qui correspond a quelque chose comme 60 000 tuples.
Etant donné que le serveur est déja chargé par d'autres applications,
je me retrouve avec des TimeOut à chaque fois.

Quel moyen puis-je mettre en place pour optimiser le DELETE ?

voici comment se compose ma table
Table Log {
Log_IDLOG GUID /*Identifiant de l'evenement*/
Log_IDVoix GUID /*Identifiant de la source sur laquelle
l'evenement a eu lieu*/
Log_DateEventMS Float /*Date en milliseconde (time_t) de
l'evenement*/
... (autres champs non interressant)
}
un index est présent sur la colonne Log_IDVoix
requete effectuée:
DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate

Je ne sais pas trop vers quel chemin me tourné:
- amelioration des index ?
- optimisation par des commandes T-SQL

Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
identifié un tuple et de se servir de la combinaison
Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent intervenir à
la mem milliseconde pour une meme source) en ajoutant peut etre un index
complex sur se couple. Qu'en pensez vous ?

Merci pour toute l'aide que vous pourrez m'apporter.
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
VUILLERMET Jacques
Le DELETE est une opération loguée, donc longue.

Si une transaction ou une restauration à une date précise ne sont demandées,
alors cela vaut peut-être le coup de faire :

SELECT *
INTO #Tmp
FROM Log
WHERE Log_DateEventMS ... --filtrage des 60 000 enr.

TRUNCATE TABLE Log --très rapide car pas loggué

INSERT INTO Log (...)
SELECT ...
FROM #Tmp

DROP TABLE #Tmp

On peut même penser à basculer les 60 000 enr. dans une table LogA (non
temporaire), on supprime la table Log, puis on renomme LogA en Log puis on
recrée l'index (encore plus rapide que l'exemple car les 60 000 enr. ne sont
manipulés qu'une seule fois).

L'objectif est d'éviter de faire un DELETE sur 1 140 000 enr.

Jacques.

"SOW Olivier" a écrit dans le message de news:

Bonjour,

J'utilise SQL2K SP3a. Voici mon soucis,
Je possedes une base qui contient une table avec plus de 2 millions de
tuples.
Cette table est utilisée pour enregistrer des evenements provenant de
plusieurs sources.
Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
garde que les evenements des 30 derniers jours).
Ce qui correspond a quelque chose comme 60 000 tuples.
Etant donné que le serveur est déja chargé par d'autres applications,
je me retrouve avec des TimeOut à chaque fois.

Quel moyen puis-je mettre en place pour optimiser le DELETE ?

voici comment se compose ma table
Table Log {
Log_IDLOG GUID /*Identifiant de l'evenement*/
Log_IDVoix GUID /*Identifiant de la source sur


laquelle
l'evenement a eu lieu*/
Log_DateEventMS Float /*Date en milliseconde (time_t) de
l'evenement*/
... (autres champs non interressant)
}
un index est présent sur la colonne Log_IDVoix
requete effectuée:
DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate

Je ne sais pas trop vers quel chemin me tourné:
- amelioration des index ?
- optimisation par des commandes T-SQL

Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
identifié un tuple et de se servir de la combinaison
Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent intervenir


à
la mem milliseconde pour une meme source) en ajoutant peut etre un index
complex sur se couple. Qu'en pensez vous ?

Merci pour toute l'aide que vous pourrez m'apporter.




Avatar
SOW Olivier
merci pour l'info
sauf que j'ai d'autre process qui ajoute des tuples dans la table
n'y a t-il pas moyen d'éviter de logguer a ce moment la
il me semblait avoir vu un equivalent dans ORACLE, je vais rechercher la
commande, mais je voudrais
savoir s'il y a un equivalent.
je crois avoir vu ca dans le cas d'un DUMP de données (a moins que je ne
confonde avec les triggers)

Es ce que le fait de passer par une SP, me permettrais d'avoir accés a plus
d'operateur poru faire
ce genre de chose ?

merci encore pour votre aide



"VUILLERMET Jacques" a écrit dans le message de
news:
|
| Le DELETE est une opération loguée, donc longue.
|
| Si une transaction ou une restauration à une date précise ne sont
demandées,
| alors cela vaut peut-être le coup de faire :
|
| SELECT *
| INTO #Tmp
| FROM Log
| WHERE Log_DateEventMS ... --filtrage des 60 000 enr.
|
| TRUNCATE TABLE Log --très rapide car pas loggué
|
| INSERT INTO Log (...)
| SELECT ...
| FROM #Tmp
|
| DROP TABLE #Tmp
|
| On peut même penser à basculer les 60 000 enr. dans une table LogA (non
| temporaire), on supprime la table Log, puis on renomme LogA en Log puis on
| recrée l'index (encore plus rapide que l'exemple car les 60 000 enr. ne
sont
| manipulés qu'une seule fois).
|
| L'objectif est d'éviter de faire un DELETE sur 1 140 000 enr.
|
| Jacques.
|
| "SOW Olivier" a écrit dans le message de news:
|
| > Bonjour,
| >
| > J'utilise SQL2K SP3a. Voici mon soucis,
| > Je possedes une base qui contient une table avec plus de 2 millions de
| > tuples.
| > Cette table est utilisée pour enregistrer des evenements provenant de
| > plusieurs sources.
| > Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
| > garde que les evenements des 30 derniers jours).
| > Ce qui correspond a quelque chose comme 60 000 tuples.
| > Etant donné que le serveur est déja chargé par d'autres applications,
| > je me retrouve avec des TimeOut à chaque fois.
| >
| > Quel moyen puis-je mettre en place pour optimiser le DELETE ?
| >
| > voici comment se compose ma table
| > Table Log {
| > Log_IDLOG GUID /*Identifiant de l'evenement*/
| > Log_IDVoix GUID /*Identifiant de la source sur
| laquelle
| > l'evenement a eu lieu*/
| > Log_DateEventMS Float /*Date en milliseconde (time_t) de
| > l'evenement*/
| > ... (autres champs non interressant)
| > }
| > un index est présent sur la colonne Log_IDVoix
| > requete effectuée:
| > DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate
| >
| > Je ne sais pas trop vers quel chemin me tourné:
| > - amelioration des index ?
| > - optimisation par des commandes T-SQL
| >
| > Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
| > identifié un tuple et de se servir de la combinaison
| > Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent
intervenir
| à
| > la mem milliseconde pour une meme source) en ajoutant peut etre un index
| > complex sur se couple. Qu'en pensez vous ?
| >
| > Merci pour toute l'aide que vous pourrez m'apporter.
| >
| >
|
|
Avatar
VUILLERMET Jacques
Le DELETE est une opération loguée, donc longue.

Si une transaction ou une restauration à une date précise ne sont demandées,
alors cela vaut peut-être le coup de faire :

SELECT *
INTO #Tmp
FROM Log
WHERE Log_DateEventMS ... --filtrage des 60 000 enr.

TRUNCATE TABLE Log --très rapide car pas loggué

INSERT INTO Log (...)
SELECT ...
FROM #Tmp

DROP TABLE #Tmp

On peut même penser à basculer les 60 000 enr. dans une table LogA (non
temporaire), on supprime la table Log, puis on renomme LogA en Log puis on
recrée l'index (encore plus rapide que l'exemple car les 60 000 enr. ne sont
manipulés qu'une seule fois).

L'objectif est d'éviter de faire un DELETE sur 1 140 000 enr.

Jacques.

"SOW Olivier" a écrit dans le message de news:

Bonjour,

J'utilise SQL2K SP3a. Voici mon soucis,
Je possedes une base qui contient une table avec plus de 2 millions de
tuples.
Cette table est utilisée pour enregistrer des evenements provenant de
plusieurs sources.
Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
garde que les evenements des 30 derniers jours).
Ce qui correspond a quelque chose comme 60 000 tuples.
Etant donné que le serveur est déja chargé par d'autres applications,
je me retrouve avec des TimeOut à chaque fois.

Quel moyen puis-je mettre en place pour optimiser le DELETE ?

voici comment se compose ma table
Table Log {
Log_IDLOG GUID /*Identifiant de l'evenement*/
Log_IDVoix GUID /*Identifiant de la source sur


laquelle
l'evenement a eu lieu*/
Log_DateEventMS Float /*Date en milliseconde (time_t) de
l'evenement*/
... (autres champs non interressant)
}
un index est présent sur la colonne Log_IDVoix
requete effectuée:
DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate

Je ne sais pas trop vers quel chemin me tourné:
- amelioration des index ?
- optimisation par des commandes T-SQL

Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
identifié un tuple et de se servir de la combinaison
Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent intervenir


à
la mem milliseconde pour une meme source) en ajoutant peut etre un index
complex sur se couple. Qu'en pensez vous ?

Merci pour toute l'aide que vous pourrez m'apporter.






"SOW Olivier" a écrit dans le message de news:

Bonjour,

J'utilise SQL2K SP3a. Voici mon soucis,
Je possedes une base qui contient une table avec plus de 2 millions de
tuples.
Cette table est utilisée pour enregistrer des evenements provenant de
plusieurs sources.
Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
garde que les evenements des 30 derniers jours).
Ce qui correspond a quelque chose comme 60 000 tuples.
Etant donné que le serveur est déja chargé par d'autres applications,
je me retrouve avec des TimeOut à chaque fois.

Quel moyen puis-je mettre en place pour optimiser le DELETE ?

voici comment se compose ma table
Table Log {
Log_IDLOG GUID /*Identifiant de l'evenement*/
Log_IDVoix GUID /*Identifiant de la source sur


laquelle
l'evenement a eu lieu*/
Log_DateEventMS Float /*Date en milliseconde (time_t) de
l'evenement*/
... (autres champs non interressant)
}
un index est présent sur la colonne Log_IDVoix
requete effectuée:
DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate

Je ne sais pas trop vers quel chemin me tourné:
- amelioration des index ?
- optimisation par des commandes T-SQL

Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
identifié un tuple et de se servir de la combinaison
Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent intervenir


à
la mem milliseconde pour une meme source) en ajoutant peut etre un index
complex sur se couple. Qu'en pensez vous ?

Merci pour toute l'aide que vous pourrez m'apporter.




Avatar
SOW Olivier
seul petit soucis, d'autre processus accede a la dite table en meme temps.
:(
n'y a t-il pas moyen de faire la meme chose que TRUNCATE (pas d'utilisation
du journal) mais avec une condition WHERE


"VUILLERMET Jacques" a écrit dans le message de
news:uk%23bgL$
|
| Le DELETE est une opération loguée, donc longue.
|
| Si une transaction ou une restauration à une date précise ne sont
demandées,
| alors cela vaut peut-être le coup de faire :
|
| SELECT *
| INTO #Tmp
| FROM Log
| WHERE Log_DateEventMS ... --filtrage des 60 000 enr.
|
| TRUNCATE TABLE Log --très rapide car pas loggué
|
| INSERT INTO Log (...)
| SELECT ...
| FROM #Tmp
|
| DROP TABLE #Tmp
|
| On peut même penser à basculer les 60 000 enr. dans une table LogA (non
| temporaire), on supprime la table Log, puis on renomme LogA en Log puis on
| recrée l'index (encore plus rapide que l'exemple car les 60 000 enr. ne
sont
| manipulés qu'une seule fois).
|
| L'objectif est d'éviter de faire un DELETE sur 1 140 000 enr.
|
| Jacques.
|
| "SOW Olivier" a écrit dans le message de news:
|
| > Bonjour,
| >
| > J'utilise SQL2K SP3a. Voici mon soucis,
| > Je possedes une base qui contient une table avec plus de 2 millions de
| > tuples.
| > Cette table est utilisée pour enregistrer des evenements provenant de
| > plusieurs sources.
| > Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
| > garde que les evenements des 30 derniers jours).
| > Ce qui correspond a quelque chose comme 60 000 tuples.
| > Etant donné que le serveur est déja chargé par d'autres applications,
| > je me retrouve avec des TimeOut à chaque fois.
| >
| > Quel moyen puis-je mettre en place pour optimiser le DELETE ?
| >
| > voici comment se compose ma table
| > Table Log {
| > Log_IDLOG GUID /*Identifiant de l'evenement*/
| > Log_IDVoix GUID /*Identifiant de la source sur
| laquelle
| > l'evenement a eu lieu*/
| > Log_DateEventMS Float /*Date en milliseconde (time_t) de
| > l'evenement*/
| > ... (autres champs non interressant)
| > }
| > un index est présent sur la colonne Log_IDVoix
| > requete effectuée:
| > DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate
| >
| > Je ne sais pas trop vers quel chemin me tourné:
| > - amelioration des index ?
| > - optimisation par des commandes T-SQL
| >
| > Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
| > identifié un tuple et de se servir de la combinaison
| > Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent
intervenir
| à
| > la mem milliseconde pour une meme source) en ajoutant peut etre un index
| > complex sur se couple. Qu'en pensez vous ?
| >
| > Merci pour toute l'aide que vous pourrez m'apporter.
| >
| >
|
|
| "SOW Olivier" a écrit dans le message de news:
|
| > Bonjour,
| >
| > J'utilise SQL2K SP3a. Voici mon soucis,
| > Je possedes une base qui contient une table avec plus de 2 millions de
| > tuples.
| > Cette table est utilisée pour enregistrer des evenements provenant de
| > plusieurs sources.
| > Tous les soirs à minuit je procéde automatiquement a une rotation (je ne
| > garde que les evenements des 30 derniers jours).
| > Ce qui correspond a quelque chose comme 60 000 tuples.
| > Etant donné que le serveur est déja chargé par d'autres applications,
| > je me retrouve avec des TimeOut à chaque fois.
| >
| > Quel moyen puis-je mettre en place pour optimiser le DELETE ?
| >
| > voici comment se compose ma table
| > Table Log {
| > Log_IDLOG GUID /*Identifiant de l'evenement*/
| > Log_IDVoix GUID /*Identifiant de la source sur
| laquelle
| > l'evenement a eu lieu*/
| > Log_DateEventMS Float /*Date en milliseconde (time_t) de
| > l'evenement*/
| > ... (autres champs non interressant)
| > }
| > un index est présent sur la colonne Log_IDVoix
| > requete effectuée:
| > DELETE FROM Log WHERE Log_IDVoix='{monGuid}' AND Log_DateEventMS<=MaDate
| >
| > Je ne sais pas trop vers quel chemin me tourné:
| > - amelioration des index ?
| > - optimisation par des commandes T-SQL
| >
| > Il est question peut etre de supprimer le champs Log_IDLOG qui sers a
| > identifié un tuple et de se servir de la combinaison
| > Log_IDVoix+Log_DateEventMS à la place (2 evenements ne peuvent
intervenir
| à
| > la mem milliseconde pour une meme source) en ajoutant peut etre un index
| > complex sur se couple. Qu'en pensez vous ?
| >
| > Merci pour toute l'aide que vous pourrez m'apporter.
| >
| >
|
|