Workspaces are special tables in dbccdb that store intermediate results of the dbcc checkstorage operation. Workspaces differ from worktables in that they:
Are preallocated contiguously to improve I/O performance
Are persistent
Do not reside in the tempdb database
When you create dbccdb, two workspaces are created automatically. They are preallocated as follows:
Scan workspace – contains a row for each page of the target database. The allocation is approximately 1 percent of the database size. Each row consists of a single binary(18) column.
Text workspace – contains a row for each table in the target database that contains text or image columns. The size of this table depends on the design of the target database, but it is usually significantly smaller than the scan workspace. Each row consists of a single binary(22) column.
If either allocation is larger than needed by dbcc checkstorage, the operation uses only what is required. The allocation does not change. If the text workspace allocation is too small, dbcc checkstorage reports this, recommends a new size, and continues checking; however, not all text chains are checked. If the scan workspace allocation is too small, the dbcc checkstorage operation fails immediately.
You must have at least one scan and one text workspace, but you may create as many as you need. While in use, the workspaces are locked so that only one dbcc checkstorage operation can use them at any given time. You can execute concurrent dbcc checkstorage operations by supplying each one with a separate scan and text workspace.
For more information on creating workspaces, see the System Administration Guide and the Adaptive Server Reference Manual.
Ideally, you should access workspaces only through dbcc checkstorage, but this is not a requirement. dbcc checkstorage exclusively locks the workspaces it uses, and the content of the workspaces is regenerated with each execution of dbcc checkstorage. The workspaces do not contain any secure data.
While the contents of the workspaces are accessible
through SQL, no interpretation of the binary values is available.
Access through SQL might return data from different dbcc checks
mixed together. The presence of a row in these tables does not ensure
that it contains valid data. dbcc tracks valid
rows only during execution. That information is lost when the operation
completes.
Most of the update activity in dbccdb is performed in the text and scan workspaces. The workspaces are preallocated, and only one dbcc checkstorage operation can use the workspaces at any given time, so the workspaces are less susceptible to corruption than most user tables. Corruption in a workspace can cause the dbcc checkstorage operation to fail or behave erratically. If this happens, drop and re-create the corrupt workspace.
Checks of databases using different workspaces can proceed simultaneously, but the performance of each operation might be degraded as it competes for disk throughput.
To delete a workspace, in dbccdb, enter:
drop table workspace_name
