[ASE 12.5.3] - DBCC & Type Code : 100028 [Résolu]

[lsone]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
dbcc checkstorage (mutubatch)
go
dbcc checkverify (mutubatch)
go
dbcc checkcatalog (mutubatch)
go
USE dbccdb
go
sp_dbcc_summaryreport
go
sp_dbcc_faultreport 'short', mutubatch
go

J'obtiens le Type Code : 100028 sur plusieurs tables

Code :

1
2
3
4
5
6
7
8
 
 
TABLE Name                     INDEX       Type Code   Description                                        Page Number 
----------                     ----------- ----------- -----------                                        ----------- 
sysobjects                               0      100028 page misplaced                                              48 
sysobjects                               1      100028 page misplaced                                            1025 
sysobjects                               2      100028 page misplaced                                            1048 
etc ....

Dans le Troubleshooting and Error Messages Guide, 100028 :

Code :

1
2
3
4
5
6
 
 
A page of the object was found IN a location other than WHERE allocations are currently allowed
Activate Trace Flag 2513 AND run:
dbcc indexalloc, dbcc tablealloc, OR dbcc checkalloc
Similar TO 2558 Error

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
USE master
go
 
sp_dboption mutubatch,"single user", true
 
USE mutubatch
go
 
checkpoint
go
 
-- To turn on trace flag 2513, follow these commands:
dbcc traceon (2513)
go
 
dbcc tablealloc (sysobjects, full, fix)
go

J'obtiens :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
 *************************************************************** 
 TABLE: sysobjects		OBJID = 1 
 INDID=1	 FIRST=49	 ROOT=1040	 SORT=1 
 	DATA level: 1.  113 DATA pages allocated AND 15 Extents allocated. 
 	Indid	  : 1.  1 INDEX pages allocated AND 2 Extents allocated. 
 INDID=2	 FIRST=1056	 ROOT=1058	 SORT=1 
 	Indid	  : 2.  24 INDEX pages allocated AND 4 Extents allocated. 
 TOTAL # of extents = 21 
 Alloc page 0 (# of extent=3 used pages=24 ref pages=24) 
 Alloc page 256 (# of extent=1 used pages=8 ref pages=8) 
 Alloc page 512 (# of extent=3 used pages=24 ref pages=24) 
 Alloc page 768 (# of extent=2 used pages=16 ref pages=16) 
 Alloc page 1024 (# of extent=6 used pages=28 ref pages=28) 
 Alloc page 204800 (# of extent=5 used pages=39 ref pages=39) 
 Alloc page 205056 (# of extent=1 used pages=3 ref pages=3) 
 Total (# of extent=21 used pages=142 ref pages=142) in this database 
 DBCC execution completed. IF DBCC printed error messages, contact a user WITH System Administrator (SA) role. 
 Extent NOT within segment: Object 1, indid 0 includes extents ON allocation page 0 which IS NOT IN segment 0. 
 Extent NOT within segment: Object 1, indid 0 includes extents ON allocation page 256 which IS NOT IN segment 0. 
 Extent NOT within segment: Object 1, indid 0 includes extents ON allocation page 512 which IS NOT IN segment 0. 
 Extent NOT within segment: Object 1, indid 0 includes extents ON allocation page 768 which IS NOT IN segment 0. 
 Extent NOT within segment: Object 1, indid 1 includes extents ON allocation page 1024 which IS NOT IN segment 0. 
Extent NOT within segment: Object 1, indid 2 includes extents ON allocation page 1024 which IS NOT IN segment 0.

Par contre là je commence par être perdu.

Quelqu'un peut m'éclairer ?

[jeeps64]

Bonjour

dbcc checkstorage remonte une erreur 100028
Comme tu l'as vu, elle peux etre "corrigée" par un "dbcc tablealloc"
Le fait de lancer la commande suivante doit donc corriger le probleme :
dbcc traceon (2513)
go
dbcc tablealloc (sysobjects, full, fix)
go

Pour info, le traceflag 2513 permet au dbcc tablealloc de remonter l'erreur 2558 qui n'ai pas remontée normalement par tablealloc.

Pour verifier si la table sysobjects est "réparée", il te suffit de relancer un "dbcc checkstorage(mutubatch)" puis un sp_dbcc_faultreport


Je ne sais pas si ca reponde a ta/tes question(s)

jeeps64

[jeeps64]

oups, mauvaise traduction du traceflag 2513


voici l'explication du traceflags 2513 :

2513
Instructs dbcc checkalloc, tablealloc and indexalloc to check for whether foreign objects are stranded on a particular segment within a database.

Qui est beaucoup plus coherent avec ton probleme

[mpeppler]

Envoyé par lsone

Code :

Le segment 0 est le segment "system" - et l'objet 1 est évidemment une table système.
Il semble que le segment 0 a été supprimé dans le premier fragment (via sp_dropsegment, peut-être). Il faudrait voir le contenu de master..sysusages pour cette base pour en savoir un peu plus.

Michael

[lsone]

Envoyé par mpeppler

Le segment 0 est le segment "system" - et l'objet 1 est évidemment une table système.
Il semble que le segment 0 a été supprimé dans le premier fragment (via sp_dropsegment, peut-être). Il faudrait voir le contenu de master..sysusages pour cette base pour en savoir un peu plus.
Michael

Voilà voilà ....

Code :

1
2
3
 
 
SELECT dbid, segmap, lstart, size, vstart, unreservedpgs FROM sysusages WHERE dbid=db_id('mutubatch') ORDER BY segmap

Code :

1
2
3
4
5
6
7
 
dbid        segmap      lstart      size        vstart      unreservedpgs 
----------- ----------- ----------- ----------- ----------- ------------- 
         11           3      204800      819200   134217728        814367 
         11           4           0      102400   150994944         63476 
         11           4      102400      102400   151097344        102000 
         11           4     1024000      256000   151199744        255000

[mpeppler]

Effectivement, le premier fragment (lstart = 0) a un segmap de 4, cad que c'est un fragment log only. Les fragments de cette base a du être manipulée puisque normalement le premier fragment n'est jamais un log only...

Je ne sais pas si cela peut poser des problèmes, mais je ne le pense pas.

Michael

[lsone]

Envoyé par mpeppler

Effectivement, le premier fragment (lstart = 0) a un segmap de 4, cad que c'est un fragment log only. Les fragments de cette base a du être manipulée puisque normalement le premier fragment n'est jamais un log only...

Je ne sais pas si cela peut poser des problèmes, mais je ne le pense pas.

Michael

En faisant un sp_helpdb, je constate que cette base a parmis les statuts : "mixed log and d "

Cette base est utilisée par des script shell/transact SQL, elle contient des tables qui sont utilisés par des bcp out pour des éditions, mise en forme awk etc ... Ce qui signifie que la base peut être recréée sans difficultés.

Quels conseils pourriez vous me donner ?
Par exemple : Reconstruction complète de la base en séparant correctement log et data, etc ...

[mpeppler]

Si cette base est flaggée "mixed log and data" alors c'est que les fragments log et data (qui sont en fait séparés) sont sur le même dévice physique.
Ce n'est pas un vrai problème, surtout s'il s'agit d'une base qui est en mode "truncate log on checkpoint".

Ceci étant il serait peut-être plus "propre" de reconstruire la base, même si c'est simplement pour éviter les messages d'erreurs/warnings du DBCC CHECKSTORAGE...

Il est probablement aussi possible d'aller manipuler le segmap directement dans master..sysusages, mais je conseillerais plutôt la reconstruction si elle n'entraine pas trop de désagréments.

Michael

[lsone]

Envoyé par mpeppler

Si cette base est flaggée "mixed log and data" alors c'est que les fragments log et data (qui sont en fait séparés) sont sur le même dévice physique.
Ce n'est pas un vrai problème, surtout s'il s'agit d'une base qui est en mode "truncate log on checkpoint".

Ceci étant il serait peut-être plus "propre" de reconstruire la base, même si c'est simplement pour éviter les messages d'erreurs/warnings du DBCC CHECKSTORAGE...

Il est probablement aussi possible d'aller manipuler le segmap directement dans master..sysusages, mais je conseillerais plutôt la reconstruction si elle n'entraine pas trop de désagréments.

Michael

Je pense reconstruire cette base. Merci pour tous ces renseignements.