5

Is there a way in catalog or arcpy to determine the amount of hard drive space a SDE feature class takes up on disk?

In catalog the 'size' column is blank and Esri help states:

The size, modification date, and read/write columns apply to several file-based objects, such as maps and shapefiles. No values will appear in these columns for data stored in a database or file-based objects that don't support retrieving that information from the file system.

As for arcpy, I have not see a property of any Describe object that can call size or read/write for that matter. The answer question How to get size of file geodatabase feature class on disk? provides the solution for a file GDB, but how can it be done for SDE feature classes?

Improve this question
2
  • After seeing it wasn’t that simple, I opted not to look for the actual size on disk. At the end of the day all I really had to have was a relative size of each feature class. I ended up just using looping through the feature classes and getting the number of features and the number of fields. That gave me enough information on which ones were probably the larger files. The size on disk would be nice to have just like I would like get read/write dates, but that is for anther SE question.
    – Rex
    Commented Dec 5, 2014 at 22:13
  • Really appreciate the simplicity of Sir Swears-a-lot's solution here. I started down the path of checking the databases using SQL Server Mgmt Studio, but I wasn't sure exactly how to derive that info. With the help of your sp_spaceused suggestion, I was able to query each of the databases and get the size info (via EXEC sp_spaceused). Super slick. In this instance, I didn't need the sizes of specific tables (features), but now I know how should I ever need it. Thanks!
    – T Schulzke
    Commented Jul 31, 2020 at 14:20

2 Answers 2

Reset to default
7

I'm a dba rather than a GIS guy, so I hope this is useful.

I respect the comments from the other users that getting this info from a db can be difficult or misleading, however assuming you have sql query access you should be able to work this out for most if not all db implementations.

What database are you using? I assume a feature would translate to a single row in a table. Are you looking for an average? The total for the table, or kb for a specific row?

Assuming sql server: sp_spaceused tablename will give you kb's used, rows, used space and unused. So you can work out total and average.

If you can identify a specific row you could select that into a #temp table and run sp_spaceused on that.

A table will use a minimum of 1 page or 8kb. So if your feature is less than that it might be harder to calculate. I guess you could insert the same row n times and then divide by n.

Can you tell us more about what you are trying to achieve and/or why?

Improve this answer
6

No, there is no standard way to determine this information, even with respect to a single RDBMS implementation. Even when you poll the database for the storage of a table, that might not correspond to the actual disk use (due to blocking factors, high water mark, etc).

Improve this answer
4
  • And also dead rows yet to be removed by the next compress. Because a feature class occupies many physical files on the database storage media even though it's seen as one feature class... I don't think there's a valid measure for size on disc; From the Esri point of view SDE talks to the database in transactions (add/delete row, create table..) that does not necessarily mean it can go that deep into the database structure.
    – Michael Stimson
    Commented Dec 4, 2014 at 22:45
  • 1
    Of course they could go that deep, if the RDBMS allowed, but ODBC, the basic model for database access on which the original API was designed, didn't have a getStorageSizeOnDisk, and there really hasn't been any reason to add one since.
    – Vince
    Commented Dec 5, 2014 at 0:26
  • And then it would have to be implemented across all supported databases (Oracle (versions), Oracle Spatial (versions), SQL Server, PostgreSQL...) dare say that there are more than enough things to keep the developers at Esri too busy to implement this property on an interface. That said, there's nothing stopping the user from contacting the database directly and getting the size from there.
    – Michael Stimson
    Commented Dec 5, 2014 at 1:37
  • 1
    And Informix, and DB2, and those NoSQL DBs,... It's a persnickety bit of coding, and all for values of low confidence and dubious value.
    – Vince
    Commented Dec 5, 2014 at 3:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.