Select to view content in your preferred language

How to determine layer size (in KB or MB) raster and vector

921
3
11-04-2010 08:05 AM
IvanSantiago
Deactivated User
Hello all:

What is the sde command to fid out how much space takes any layer in the sde GDB?

I tried the stored procedure sp_space used in SQL Server 2008 but the size of the raster table didn't seem correct (size too small).

Any help will be appreciated
Ivan Santiago
San Juan, PR
0 Kudos
3 Replies
RobertHu
Emerging Contributor
Hi Ivan,

The "real" info of raster dataset or catalog stores in <schema>.SDE_blk_# table. Check the sde_raster_columns table to find out what # is associated to the raster dataset your are interested in, then you know which BLK table contains the raster info (pixles). See the link for the raster dataset structure,

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Raster_dataset_and_raster_catalog_stor...

I mornally just use the SSMS's report functions to get the size of a table.

Thanks!
0 Kudos
VinceAngelo
Esri Esteemed Contributor
There is no ArcSDE command to report storage of database objects.  Instead you must
use database tools to determine this information.

sp_space_used will report the storage of a table for SQL-Server, but you need to identify
the correct associated table (in the form SDE_blk_{n}, where {n} is the rastercolumn_id
value from sde.SDE_raster_columns table for the table_name associated with the raster).
There are other tables (and indexes) as well, but the BLK table generally holds 99% of
the overall allocation.  Vector storage determination is trickier, since the three primary
tables are more nearly equal (except when you have thousands of vertices per feature),
and versioning makes the problem more complex (two more tables, which may be either
small or large, depending on your versioing state tree).  The 'sdetable -o describe_reg'
command will identify the tables which participate with a business table in storage
of spatial data, but you may then need to determine the indexes of each table.

Finally, you need to consider high water marks, since storage isn't generally released
after a delete operation (on the assumption [by the RDBMS] that the table will grow
again anyway).  Other databases also incorporate "extent" (or "chunk") management
overhead so that even a 10Kb LOB might use hundreds of Mb.  Then there's block
overhead on the disk drive,...  All in all, it's a rather complex issue.

- V
0 Kudos
IvanSantiago
Deactivated User
🙂 Thanks Vince and Robert.

Very much appreciated, though no easy solution, except for rasters.

Ivan Santiago
San Juan, PR
0 Kudos