2010-02-12 7 views
0

Je vais avoir un problème en cours d'exécution de cette requête:Problème d'exécution instruction DELETE sur le serveur lié dans SQL Server 2008

DELETE FROM [IRPROD]..[BUDGET_USER].[GL_EXP] 
WHERE FISCAL_YEAR = 2010 

IRPROD est un serveur lié à une base de données Oracle 10g. Il est lié à l'aide du fournisseur Oracle OleDB. Il y a ~ 79000 enregistrements qui doivent être supprimés. En cours d'exécution de cette requête, il supprime 54. L'exécuter à nouveau me donne ce message d'erreur.

Msg 7399, Level 16, State 1, Line 1 
The OLE DB provider "OraOLEDB.Oracle" for linked server "IRPROD" reported an error. The provider reported an unexpected catastrophic failure. 
Msg 7330, Level 16, State 2, Line 1 
Cannot fetch a row from OLE DB provider "OraOLEDB.Oracle" for linked server "IRPROD". 

De toute évidence, "l'échec catastrophique" est quelque chose de mauvais. Mais la chose étrange est que je peux exécuter des instructions SELECT et INSERT toute la journée et ça fonctionne bien. J'ai les permissions pour supprimer les lignes. En outre, si je lier la table via Access, je peux supprimer les enregistrements.

Des idées?

+0

Suggestion pour aider au diagnostic: Essayez d'ajouter une condition dans la clause where par exemple WHERE FISCAL_YEAR = 2010 AND some_other_column mjv

+0

Bonne idée. J'ai couru une autre requête qui aurait supprimé 8 lignes mais il est revenu et a dit "0 lignes affectées". Ce qui est drôle, c'est que ça prend autant de temps pour revenir avec un résultat (1:15). Il n'y a plus d'index ni de clé sur cette table. Cela pourrait-il l'affecter? –

+0

@Clint C'est vraiment étrange (0 lignes affectées plutôt que 8). Je suppose que vous avez vérifié que les 8 lignes n'étaient effectivement pas supprimées. Sur la durée constante de la requête normale/attendue: sans index, la sélection des lignes à supprimer implique un balayage de table de sortes, ce qui, si la table est importante, prendrait un temps relativement long et prendrait plus ou moins le même montant (différence uniquement à cause de la mise en cache, etc.). Je suppose que la requête de sélection utilisée pour vérifier les lignes, les diagnostics, etc. est la même que pour un spectacle, mais pour 'DELETE' remplacé par' SELECT * ' – mjv

Répondre

0

Ok, cela s'est avéré être une solution facile avec une explication compliquée.

Le premier problème était un pilote Oracle obsolète. Nous utilisions le fournisseur de la version 9, donc j'ai mis à jour le fournisseur 10g fourni par notre boutique OIT. Il s'avère que celui qu'ils ont a un bug. Je l'ai donc désinstallé et installé le fournisseur 10g d'Oracle qui est mis à jour pour corriger le bug. Deuxièmement, j'ai changé le champ 'fiscal_year' du type varchar2 en un type de nombre. Si vous envoyez une instruction DELETE avec un WHERE (ou peut-être une clause conditionnelle, je vérifie seulement WHERE) qui se compare à un champ de test, SQL Server doit effectuer un scan distant sur la table, qui récupère les données et doit by-one supprime chaque ligne. Si vous envoyez une instruction DELETE avec un WHERE qui est numérique, SQL Server peut transmettre la requête directement à la base de données distante sans effectuer d'analyse à distance.

J'espère que cela aide quelqu'un. J'ai trouvé cela par essais et erreurs et des morceaux de l'Internet. Merci pour tout ce qui a aidé sur cette question.

1

Fournisseur OleDB et base de données Bug 5043675: La configuration d'un serveur lié fonctionne correctement pour lire les données mais la mise à jour ou la suppression des données échoue avec l'erreur.

utiliser les patches 5043675, 6637236

Vous pouvez les télécharger à partir Oracle Support.

+0

J'ai upvoted votre réponse parce que cela faisait partie du problème. En outre, il est utile de fournir des liens dans vos réponses, cela le rend beaucoup plus facile pour le lecteur final. –

Questions connexes