L'objet "maTable" est introuvable

**Mickael2604** · 20/05/2010, 17h25

Bonjour à tous,

Voila mon souci :
J'ai crée une procédure stockée qui entre des valeurs dans une table ( estimationRemplissage). JE l'execute en administrateur, aucun souci, cela marche.
Je crée un utilisateur, je lui donne les permissions de select et insert sur estimationRemplissage => commande réussi. Mais quand j'execute la procédure avec l'utilisateur, il me met

L'objet "estimationRemplissage" est introuvable, car il n'existe pas ou vous ne disposez pas d'autorisations nécessaire.
Dans ma procédure, je fais un truncate sur estimationRemplissage, cela vient peut etre de cela ? Mais je n'ai pas trouvé les autorisations pour truncate..

Merci pour votre aide.
@+

PS : J'utilise SQL server 2008

**SQLpro** · 20/05/2010, 17h47

Effectivement TRUNCATE n'étant pas une opération de mise à jour, vous ne pouvez en affecter le privilèges directement.
Évitez d'utiliser TRUNCATE dans les développement, c'est une hérésie et ne devrait être utilisé que par le DBA !
Regardez l'aide en ligne sur les privilèges requis pour lancer un TRUNCATE :
"
L'autorisation minimale requise est ALTER sur table_name. Les autorisations TRUNCATE TABLE sont octroyées par défaut au propriétaire de la table, aux membres du rôle serveur fixe sysadmin et des rôles de base de données fixes db_owner et db_ddladmin....
"

A +

**Mickael2604** · 20/05/2010, 17h49

Comment éviter truncate alors ?

**SQLpro** · 20/05/2010, 18h00

En faisant DELETE !!!! ca c'est du SQL !

A +

**Mickael2604** · 20/05/2010, 18h00

Quelle est alors la différence entre delete et truncate ?

**elsuket** · 21/05/2010, 07h15

Bonjour,

Voici la liste des différences entre ces deux instructions.

@++

**kagemaru** · 21/05/2010, 09h58

bonjour

=> En conséquence, les données supprimées par un DELETE sont restaurables; les données "supprimées" par un TRUNCATE ne le sont pas.

Je ne suis pas d'accord. En quoi les données supprimées par un truncate ne sont pas restaurables ? Que se passe-t-il si on interrompt un truncate en cours de route ? Un rollback est effectué et les pages réallouées.
Que se passe-t-il si un truncate est utilisé dans une transaction ? Si la transaction échoue, le truncate est annulé.

Donc pour les bases en envoi de journal (log shpping), c'est pareil, les truncate sont traités comme les autres ordres.
Comme tu l'indiques, le truncate écrit les pages supprimées dans le journal. SQL Server peut donc les ramener si besoin et rejouer ce truncate en cas de restauration.

ps : Je voulais laisser ce commentaire sur ton blog mais je n'arrive pas (vous devez être identifié.....blahblah)

**SQLpro** · 21/05/2010, 10h46

Vous vous méprenez totalement et ne savez pas lire l'aide en ligne :
"
Supprime toutes les lignes d'une table sans enregistrer les suppressions de ligne individuelles dans le journal. L'instruction TRUNCATE TABLE est semblable à l'instruction DELETE sans la clause WHERE. Cependant, l'instruction TRUNCATE TABLE est plus rapide et utilise moins de ressources système et de ressources du journal des transactions.
"

Autrement dit on ne journalise pas les données, on journalise que telle et telle page a été vidé et c'est tout alors que le DELETE journalise toutes les données de toutes les lignes supprimées.
On ne peut donc pas faire de reprise de données après un TRUNCATE. En effet, le JT ne reprenant pas les valeurs une restauration a un point dans le temps ne montrera pas les données supprimées par TRUNCATE.
En cela l'instruction TRUNCATE est extrêmement dangereuse et ne devrait être réservé qu'aux DBA !

A +

**kagemaru** · 21/05/2010, 12h09

Alors faudrait-il expliciter dans ce cas

=> En conséquence, les données supprimées par un DELETE sont restaurables; les données "supprimées" par un TRUNCATE ne le sont pas.

mais egalement ceci :

On ne peut donc pas faire de reprise de données après un TRUNCATE. En effet, le JT ne reprenant pas les valeurs une restauration a un point dans le temps ne montrera pas les données supprimées par TRUNCATE.

Donnez-moi un exemple, je ne comprends pas.

Comme je le comprends : la commande truncate écrit les désallocation de pages de données dans le journal. Ces pages de données sont verrouillées jusqu'à ce que le truncate aboutisse. Si vous faites un backup log après un truncate, la commande truncate est dans le journal bien sûr, sans les données mais avec les références des pages désallouées. Donc si je restaure ma base dans un point dans le temps avant le truncate, mes pages de données seront là. Si je restaure après le moment du truncate, elles ne seront plus là.

Un TRUNCATE est annulable. Il peut être utilisé dans une base configurée pour l'envoi de journal. Pour vider une table volumineuse avant traitement, je privilègerais cette commande et je pense que que c'est dans ce contexte que Mickael2604 l'utilise. C'était principalement ce que je voulais préciser.

En cela l'instruction TRUNCATE est extrêmement dangereuse et ne devrait être réservé qu'aux DBA !

Oui, comme toute commande, il faut bien connaître ses effets avant de l'utiliser.

**SQLpro** · 21/05/2010, 13h06

Envoyé par kagemaru

Si vous faites un backup log après un truncate, la commande truncate est dans le journal bien sûr, sans les données mais avec les références des pages désallouées. Donc si je restaure ma base dans un point dans le temps avant le truncate, mes pages de données seront là.

Non, car il y a toutes les chances qu'elles aient été réallouées à d'autres écritures peu de temps après le TRUNCATE. Donc impossible quelque soit le mode de journalisation FULL, BULK LOGGED ou SIMPLE.

Inspirez vous de ce début de démo pour vous en convaincre !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
CREATE DATABASE DB
GO
 
USE DB;
GO
 
CREATE TABLE T (C INT)
GO
 
INSERT INTO T VALUES (0) 
GO 1000
 
CHECKPOINT
GO
 
BACKUP DATABASE DB
TO DISK = 'C:\DATABASE\DB_BACKUP'
GO
 
TRUNCATE TABLE T;
GO
 
INSERT INTO T VALUES (1) 
GO
 
CHECKPOINT
GO
 
BACKUP LOG DB
TO DISK = 'C:\DATABASE\DB_BACKUP_L1'
GO
 
RESTORE DATABASE DB2
FROM   DISK = 'C:\DATABASE\DB_BACKUP'
WITH MOVE 'DB' TO 'C:\DATABASE\F1',
     MOVE 'DB_log' TO 'C:\DATABASE\F2',
     NORECOVERY;
 
 
RESTORE LOG DB2
FROM   DISK = 'C:\DATABASE\DB_BACKUP_L1'
WITH RECOVERY;
 
USE DB2;
GO
 
SELECT *
FROM   T;
 
C
-----------
1

A +

**kagemaru** · 21/05/2010, 13h43

Non, car il y a toutes les chances qu'elles aient été réallouées à d'autres écritures peu de temps après le TRUNCATE. Donc impossible quelque soit le mode de journalisation FULL, BULK LOGGED ou SIMPLE.

Vous ne lisez pas correctement ma phrase :

...un point dans le temps avant le truncate....

Dans votre exemple, pour coller avec ce que j'avance, il fallait ajouter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
RESTORE LOG DB2
FROM   DISK = 'C:\DATABASE\DB_BACKUP_L1'
WITH RECOVERY, STOPAT='le datetime peu avant le TRUNCATE';

Vous voyez bien que les données sont toujours là puisque le TRUNCATE n'a pas encore eu lieu en quelque sorte. Mais tout le monde s'en doute bien. Ceci serait de même avec un DELETE FROM T.

Et encore une fois, un truncate dans une transaction est annulable. Nous sommes bien d'accord sur le fait que les donnèes supprimées n'apparaîtront pas dans le journal mais tant que le truncate n'est pas validé, tout peux redevenir comme au départ.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE T (C INT)
GO
 
INSERT INTO T VALUES (0) 
GO 1000
 
BEGIN TRAN
GO
 
TRUNCATE TABLE T;
GO
 
ROLLBACK TRAN
GO
 
SELECT COUNT(*) FROM T
GO

Tout cela pour dire que la phrase ".....les données "supprimées" par un TRUNCATE ne sont pas restaurables " ne me semble pas correcte et contribue à la mauvaise compréhension sur les effets de la commande TRUNCATE. Désolé pour le troll !

**Mickael2604** · 21/05/2010, 14h56

Désolé de vous interrompre, j'ai une autre petite question :

Je fais un set @pourcent = (@qte / @capacite) * 100;

@qte et @capacite sont déclaré en int et @pourcent en float
j'ai testé @qte et @capacite et elles valent 500 et 600 pour un exemple. Cependant le résultat de @pourcent me retourne 0, je ne comprends pas.

Merci de votre aide.

**elsuket** · 21/05/2010, 19h45

Mickael2604,

La division d'un entier par un entier retourne toujours un entier.
Donc il vous faut choisir les types decimal (la norme) ou numeric pour réaliser votre division, au moins sur une de ces deux variables, le plus propre étant les deux.
Évitez le type de données FLOAT qui est imprécis et vous conduira à des erreurs.

Kagemaru,

Et encore une fois, un truncate dans une transaction est annulable

Oui, mais pas si vous êtes dans une autre session ou dans le cas d'un RESTORE sans point dans le temps.
Je vais tester à un point dans le temps.

Nous sommes bien d'accord sur le fait que les donnèes supprimées n'apparaîtront pas dans le journal mais tant que le truncate n'est pas validé, tout peux redevenir comme au départ.

C'est tout à fait exact.

Tout cela pour dire que la phrase ".....les données "supprimées" par un TRUNCATE ne sont pas restaurables " ne me semble pas correcte et contribue à la mauvaise compréhension sur les effets de la commande TRUNCATE. Désolé pour le troll !

Aucun problème, c'est vrai que j'ai fait un raccourci.
Mais là encore il suffit que la page soit réutilisée ...

Je préciserai mon billet demain; merci de l'avoir relevé

@++

**dbaffaleuf** · 25/05/2010, 16h06

Allez je m'incruste héhé

Envoyé par kagemaru

Tout cela pour dire que la phrase ".....les données "supprimées" par un TRUNCATE ne sont pas restaurables " ne me semble pas correcte et contribue à la mauvaise compréhension sur les effets de la commande TRUNCATE. Désolé pour le troll !

Je suis d'accord avec Manu. Il y a beaucoup trop d'ambiguïté dans les traductions de docs techniques, notamment sur cette question de transactions non loggées.
- On peut rollbacker un truncate table
- SQL Server ne peut pas réutiliser les pages désallouées par le TRUNCATE tant que la transaction qui le contrôle n'est pas validée car elle maintient des verrous exclusifs sur les pages de la table.
- Un restore log with stopatmark par exemple permet de récupérer les données avant le TRUNCATE.

David B.

L'objet "maTable" est introuvable

Administration SQL Server

Partager

Partager