Olá Pessoal,

Continuando os cursos do Paul Randal na PluralSight, muitas ideias de posts vão surgindo e com o tempo permitindo, colocarei aqui no Blog.

Hoje vou falar de duas funções não documentadas que nunca tinha ouvido falar: %%PHYSLOC%% e fn_PhysLocCracker.

Criei uma tabela e populei com mil registros para a realização dos testes:

CREATE TABLE TesteLocalizacaoRegistros(
Cod INT IDENTITY,
Data DATETIME DEFAULT(GETDATE()),
Texto CHAR(1000) DEFAULT(‘FABRICIO LIMA CONSULTORIA SQL SERVER’))

INSERT INTO TesteLocalizacaoRegistros DEFAULT VALUES
GO 1000

A função %%PHYSLOC%% mostra de uma forma não entendível para nós meros mortais, a localização física de cada registro de uma tabela. A utilização dela é muito simples conforme abaixo:

 

Como podem ver, essa função sozinha não nos ajudaria em nada. Entretanto, algum camarada dos DBAs SQL Server também criou uma função chamada fn_PhysLocCracker que traduz essa informação para o nosso dialeto SQL Server.

 

Como é possível perceber na figura acima, as linhas com a coluna Cod de 1 à 7 da minha tabela estão na página 177, as linhas de 8 à 14 estão na página 179 e etc…

Até hoje, a forma onde eu via essa informação era através do comando DBCC PAGE. Segue abaixo um print do Slot 0 da página 177:

 

Essa informação pode ser útil de várias maneiras no nosso dia a dia.

Um exemplo de como essa informação pode nos ajudar é na investigação de uma corrupção, que é um dos problemas que mais me assustam em um banco de dados.

Imagina que você passou a receber o erro de uma página corrompida. Até hoje eu utilizava o comando DBCC PAGE para descobrir o que tinha dentro dessa página.

Caso essa página corrompida seja uma página de dados, com a informação do objeto dono da página em mãos, podemos com apenas um SELECT simples descobrir as informações envolvidas na corrupção.

Caso não seja possível realizar esse select na página corrompida (não fiz esse teste com uma corrupção de verdade), conseguimos através de um backup da base tentar buscar essa informação.

Para testar isso, fiz um restore da minha base de dados chamada ConsultoriaSQLServer em uma base chamada ConsultoriaSQLServer_Report, exemplo que muitos ambientes já possuem com bases D-1 sendo restauradas diariamente para relatórios, e fiz o mesmo select para conferir se as páginas dados são as mesmas ou se existiria alguma alteração:

 

É possível verificar que o resultado foi idêntico. Como tenho bases D-1 em meu ambiente, posso utilizar essa base para rapidamente descobrir o que tem dentro de uma página corrompida na base de produção.

Claro que a base de produção pode sofrer alterações, mas em grande partes dos casos esse teste nos ajudará.

Como se trata de uma função não documentada, ela pode desaparecer nas próximas edições do SQL Server, o que seria uma pena.

Realmente um comando para não esquecer. Tanto que estou guardando aqui bem destacado no Blog.

Gostou desse Post?

Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Abraços,

Fabrício Lima

MCITP – Database Administrator

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006