we have a query which runs several times a dayreads from several tables in one database ("W"), and two tables in another database ("P") (both db's reside on the same server)the two tables in database "P" never had their indexes rebuilt or statistics updated, and were significantly fragmentedI purged some old information from another table in database "P" (about 50% worth), and shrank database "P" (to reclaim disk space which we were running out of)I rebuilt the indexes/updated statistics in "P" immediately afterward, and now weekly, via a maintenance plan (rebuild index task [original amount of free space], update statistics task [column stats only, initially at 10%, then 50% weekly])From that point forward the aforementioned query takes twice as long to runThoughts?FYI:the two tables in the query, and the table I purged, are subscribed tables in replication, the publisher being on another server in the same domainI dropped replication on the purged table, purged it on both the publisher and subscriber, and re-created replicarecreatedthe "replication support only" optionthe two tables in the query had replication active the whole time (purge of the third table, shrink, index rebuild, etc.) -- no information was flowing at that timedatabase "P" has not expanded since the shrinka comparison (via RedGate Compare) between the database pre-purge/shrink/index rebuild and present show no structural differences between the two tables used by the queryIs it possible that the plan the query was using prior to the index rebuild was running faster despite the fragmentation? I would think that any reduction in index fragmentation would be cause for improvement in query performance*** UPDATE (11-20-2012) -- it was determined that, on that day, I rebuilt indexes but NOT stats -- update stats came 2 weeks later and made no difference either way
↧
