Discussion :

[Ptit_Dje]

Bonjour,

Soit le script de création de table de test suivant:

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
 
create table varchar2nvarchar
(
id int identity (1,1) not null,
value varchar(255),
nvalue nvarchar(255)
)
 
 
insert into varchar2nvarchar (value)
select 'abc'
union
select 'def'
union
select 'ghi'
union
select 'jkl'
union
select 'mno'
union
select 'pqr'
union
select 'stu'
union
select 'vwx'
union
select 'yz'
GO
 
insert into varchar2nvarchar (value)
select top 1000000 a.value + b.value
from varchar2nvarchar a cross join varchar2nvarchar b
GO 3

Ensuite l'execution de la commande:

Code :

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

1
2
 
alter table varchar2nvarchar alter column value nvarchar(255)

Mon fichier journal grossis jusque 1500MB.
Je n'arrive pas à expliquer une telle croissance pour un si petit nombre de rows (qui représente 35MB de données).

Comment peut on expliquer une telle croissance ?
Est ce que le grossissement du fichier log est une fonction linéaire?
Est ce qu'un tel changement (alter table ... alter column...) va generer plus de "logs" en fonction de la taille totale d'une row ou est ce uniquement dépendant de taille de la colonne ?

[mikedavem]

Bonjour,

Ce comportement est tout à fait normal.

La taille du fichier des transactions dépend du volume de transaction.

D'après votre script vous insérez 1008190 lignes dans votre table.
Votre fichier de transaction va grossir une première fois.

Ensuite vous faites un ALTER TABLE ALTER COLUMN... Sqlserver va refaire un passage sur l'ensemble de votre table (donc les 1008190 lignes) et logger une nouvelle fois dans le fichier des transactions.

++

[Ptit_Dje]

Merci pour ta réponse.
Je comprend bien le raisonnement derrière, je suis par contre surpris de l'espace nécessaire pour réaliser l'opération.

[SQLpro]

Dans le JT vous avez les valeurs avant modif et après modif. Or pour modifier une seule colonne, SQL Server supprime la table, mais avant il créée une table pseudo temporaires, puis recrée la table et enfin supprime la table pseudo temporaire. Ce que vous voyez doit donc être approximativement un peu supérieur à 4 fois la taille de la table. Comptez en sus tous les index (deux fois : suppression puis recréation) et les méta données manipulées...

C'est d'ailleurs fortement déconseillé de changer le type des données d'une table en production !

Il y a un script plus fin que j'ai donné ici : http://sqlpro.developpez.com/cours/s...partie2#L7.6.1

a +

[Ptit_Dje]

Merci Frédéric pour ta réponse détaillée.

Dans le cadre de cette recherche j'ai aussi découvert le document ci-joint.
Je trouve cette analyse intéressante et tenais à la partager.

Thcuss,
Dje