Mike,
Was the database that contains the procedure loaded from a full dump plus one or more transaction log dumps shortly before the error started occurring? I think this might actually be one of those old bugs Mark found, CR 378137. I've made a few adjustments to let engineering know it is still an issue in current versions.
The specifics of the bug is that normally after a database is loaded, all procedures in it are marked for re-resolution (mapping names in the source code to database and object ids). However, it turns out that procedures created since the full dump was taken (i.e. procedures that are re-created by the load tran command) do not get marked for re-resolution in the same way. This can lead to the 2809 errors when executing a procedure with cross-database object references after restoring from the full dump + tran logs into a database that has a different dbid than the source of the dump.
-bret
Here is a full reproduction script:
use master
go
drop database db1
go
drop database db2
go
create database db1 on default log on default with override
go
create database db2 on default log on default with override
go
use tempdb
go
drop table t1
go
create table t1 (c1 int)
go
use db2
go
dump database db2 to "/work/db2.dmp"
go
create proc p1 as update tempdb..t1 set c1 = 30
go
dump tran db2 to "/work/db2.tran"
go
load database db1 from "/work/db2.dmp"
go
load tran db1 from "/work/db2.tran"
go
online database db1
go
use db1
go
exec p1
go