r_content_size vs r_full_content_size

Both live on dm_sysobject (and therefore dm_document). They describe the primary content length in bytes. They are not the same type, and they are not always in sync with the content object.

Types and the 2 GB ceiling

Attribute Type Use
r_content_size integer (32-bit signed) Legacy. Max value 2147483647 bytes, about 2 GiB. Larger primary content cannot be stored accurately here.
r_full_content_size double Same meaning without that ceiling. Use this for any size, quota, or download-planning query.

Under 2 GiB the two numbers are usually equal. That is not a reason to keep using the integer field. New DQL should read r_full_content_size only.

select r_object_id, object_name, r_content_size, r_full_content_size
from dm_document
where r_object_id = '09xxxxxxx'

Not the Windows file size

Explorer’s “Size” and “Size on disk” are filesystem numbers (allocation units, and sometimes extra streams). Content Server stores the bytes it ingested into the content store. A few KB of difference is normal. Do not treat r_content_size as “Windows size plus padding,” and do not use either attribute as a bit-for-bit match to a client file dialog.

When the sysobject lies

The size attributes on dm_sysobject are a cache of the primary dmr_content row. They can be empty or stale when:

For the length Content Server actually has, join the content object. Primary content is i_contents_id:

select d.r_object_id, d.object_name, d.r_full_content_size, c.full_content_size
from dm_document d, dmr_content c
where d.i_contents_id = c.r_object_id
and d.r_object_id = '09xxxxxxx'

Every content row hung off the document, including renditions:

select full_format, content_size, full_content_size
from dmr_content
where any parent_id = id('09xxxxxxx')

dmr_content has the same split: content_size is the 32-bit field, full_content_size is the double. Prefer the double.

Summing for disk planning

Sum r_full_content_size on the objects you will actually pull. This example is CURRENT documents created in the last year. It does not include old versions ((ALL)) or renditions (those need the dmr_content query above).

select sum(r_full_content_size)
from dm_document
where datediff(day, r_creation_date, date(today)) <= 365

IDs in examples are 09xxxxxxx: 09 is the dm_document type tag. The rest is x because those digits include the docbase id.