I've had an overnight job fail two days running with the below error. I'm not sure where to start looking to track down the issue. Any suggestions would be greatly appreciated! The step that is failing is truncating and importing a number of tables from one database to another. The database it is importing it from is on a different server and accessed through a linked server. Thanks. Could not locate statistics '_WA_Sys_00000052_79FD19BE' in the system catalogs. [SQLSTATE 42000] (Error 2767) DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] (Error 2528) DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] (Error 2528). The step failed **Updated with additional details after comments/answers to original question (15/6/2017):** Thomas - thanks for the response - I also thought it could be the permissions issue after reading [this](
http://www.benjaminnevarez.com/2011/05/optimizer-statistics-on-linked-servers/) article by Benjamin Nevarez, but the job is running on a 2014 server so don't think it's that issue. The job had been running fine until Monday. There were changes in schema to the source table over the weekend so I assume it's linked to that. The data is coming from a readonly copy of the database on a secondary node in an alwayson cluster - but that has always been the case. The job isn't running a DBCC command - it just deletes from the target table and select * from the source table into the target. The SQL code to do that is dynamic SQL as it loops through importing a number of tables in a number of databases. The index it states it cannot find does exist in the source database when I run this code: SELECT * FROM sys.stats s JOIN sys.stats_columns sc ON sc.object_id = s.object_id AND sc.stats_id = s.stats_id JOIN sys.columns c ON c.object_id = sc.object_id AND c.column_id = sc.column_id WHERE OBJECTPROPERTY(s.object_id, 'IsUserTable') = 1 AND s.name = '_WA_Sys_00000052_79FD19BE'; Yesterday I updated the statistics on that table to see if that makes any difference. The import is running at the moment so I'll see what happens. **Update 2** Updating the statistics on the table solved the issue. I'm none the wiser as to why it happened though.
If those statistics are on the remote server, then it's possible that you (well, your remote / linked server connection credentials) haven't got the right / sufficient privileges and permissions on the remote database. If the remote server is running SQL2012RTM or earlier, then your remote account will need to be in one of the db_ddladmin / db_owner / sysadmin groups. (SQL2012SP1 fixed this problem.)