there is a medium-large db, high i/o. several large staging tables (for etl, very wide) were created with clustered pk varchar(40) (different story why, it was a design tool that did that). etl runs every 2 min in production or faster on these tables. there is also a pump that pushes the data from it on different server/servers (their infrastructure is not described the very best up to date way). we think we know all in and out data streams, does not mean there are no surprises so (services and what else that is not a job on a sql server instance).
so, fragmentation is high on these tables, and it ends up high after defrag rather fast, use of this particular pk as the order of the data is simply wrong, they neither come into that table this way, neither are queried this way, a wizard like tool created lots of clustered pk by default, that's why it ended up like this.
thoughts about getting rid of it in production:
most of etl uses nolock so it is likely most of it will not blow up and the main etl we can shut down for a time to create a better maintenance window. because we do not know for sure all the etl or other processes that may touch the object I'm tinkling
create unique not null just like what pk has (because fixing out duplicate keys in this case is not exactly trivial)
drop pk
create not clustered pk
drop unique not null .
at this point we do not have accurate space allocation on table level for this vldb. dmv's numbers seem to be quite a lot off. for what we know tables may be 1tb or more, so it will take some time to run this.
does anyone try to do some estimates how long may this kind of work using some server io, cpu etc data? i have a copy in dev environment, server is weaker, a lot. not sure if i could extrapolate the number more or less accurately, but if there is a good formula to do it please share.
thanks.