Fabricio Araujo's questions

Arriscando perguntar algo idiota, mas não obtido facilmente pelo Google-fu, mas como consultar o id do banco de dados (e outras informações) do objeto base de um sinônimo?

O sinônimo em questão é remoto (aponta para uma tabela em outro banco de dados no mesmo servidor). O objeto base em si não é fixo: é a mesma tabela em diferentes bancos de dados a cada execução do procedimento.

Eu gostaria de um método não específico (exemplo: não quero depender da análise da base_object_namecoluna em sys.synonyms), mas entenderei se me disserem que essa é a única opção.

E como isso levanta a questão: a simultaneidade não é um problema, apenas um cliente chamará esse procedimento.

Em uma tabela de rastreamento gerada pelo Profiler, tentei determinar a origem de um bloqueio usando a coluna ObjectID2 associada a sys.allocation_units.

Os resultados não são bons. Identifica muitas tabelas que NÃO estão na query que gerou o trace.

Alguém sabe o que significa essa coluna? Meu Google-fu falhou comigo hoje.

A consulta base que usei para encontrar o objeto (a final não tem a au.*, p.* parte):

select object_name(p.object_id) AS name, tt.RowNumber, au.*, p.* 
from 
  Trc_Tables_20131210 tt
  INNER JOIN sys.allocation_units au
    ON tt.ObjectID2 = au.allocation_unit_id  AND tt.ObjectID = 0
  INNER JOIN sys.partitions p
    ON au.container_id = p.hobt_id

WHERE au.type IN (1,3) AND tt.EventClass = 24

EDIT: A saúde do sistema é uma boa indicação de estudo. Mas, por enquanto, tenho que me restringir a uma tabela de rastreamento do SQL Profiler para estudar os bloqueios da consulta, pois não tenho acesso fácil ao servidor de produção do cliente.
Sobre o trace: o principal evento no trace é o Lock:Acquired.

Bem, é um cenário hipotético, mas o que estou tentando entender é o caminho a seguir de um log post-morten (digamos, um rastreamento do SQL Server Profiler) para identificar o código em uma situação de ORM. Para não ser muito vago, considere um cenário como este:

• SQLServer 2008
• Entity Framework como um ORM

Então, nesse cenário, qual é o caminho comum para um DBA (que também é um desenvolvedor VB.Net) fazer do log para diagnosticar qual código (neste caso, consultas Linq) estão criando o problema? Nesse caso, o aplicativo está ok, mas está afetando o tempo de resposta de outros aplicativos usando o mesmo banco de dados/servidor.

Isso seria absurdamente diferente de um processo Java+Hiberate?

EDIT: quero entender o caminho do rastreamento para a metaconsulta culpada. Se o aplicativo tiver SQL, isso significa que uma sessão "Localizar nos arquivos" (talvez com algum regex, em casos extremos) pode reduzir os alvos da tarefa de inspeção a algumas dezenas de suspeitos em vez de décimos ou até centenas de arquivos de origem. Usando um ORM, como chegar a esse estágio usando um ORM (neste caso: EF)?