Por que temos funções não documentadas e sem suporte no SQL Server?

Oct 27 2020

Depois de ler um artigo, datado de 2012 , sobre as funções não documentadas fn_dblog e fn_dump_dblog, fiquei me perguntando por que elas ainda não são documentadas e não têm suporte se já existem há muito tempo e são bastante úteis. O mesmo vale para este artigo sp_msforeachtable e sp_msforeachdb de 2004 .

Eu poderia me beneficiar com um deles para responder a uma pergunta no fórum ( durante um backup de log é feito backup dos dados no início ou no final da operação? ), Mas eu gostaria de saber por que eles são enviados com o SQL Server de forma não documentada e sem suporte até agora.

Eu entendo que eles não são considerados confiáveis, mas se esse fosse o único motivo, em 16 anos eles poderiam ter sido corrigidos. Portanto, deve haver outra explicação.

Respostas

9 mustaccio Oct 27 2020 at 15:17

Como alguém que trabalha para um grande fornecedor de software, posso dizer que os recursos não documentados e sem suporte 1 normalmente se enquadram em uma destas três categorias:

  1. Ferramentas para uso exclusivo dos engenheiros de suporte do fornecedor. Eles raramente são necessários, geralmente exigem conhecimento íntimo de componentes internos, são difíceis de configurar e usar e, muitas vezes, perigosos o suficiente para serem protegidos por senhas ou chaves únicas que devem ser explicitamente fornecidas pelo fornecedor. Eles nunca se destinam a se tornar recursos do produto. Eles estão lá para ajudar no suporte ao solucionar problemas difíceis de depurar.

  2. Correções e soluções alternativas para bugs esotéricos. Eles são implementados como hot fixes para situações críticas. Esses bugs são raros e suas causas raiz são eventualmente resolvidas, portanto, esses "recursos" perdem sua utilidade nesse ponto e não é do interesse do fornecedor fornecer suporte contínuo para eles.

  3. Beta e recursos experimentais. Normalmente, eles são disponibilizados primeiro e escassamente documentados para um pequeno grupo de testadores beta e grandes clientes que os solicitaram. Algumas delas acabarão por se tornar totalmente suportadas, outras serão deixadas lá para apodrecer quando as partes interessadas perderem o interesse ou quando entrarem em conflito com outras características consideradas mais importantes ou úteis.

Conforme mencionado nos comentários à sua pergunta, cada recurso totalmente suportado e documentado acarreta um custo para o fornecedor, e esse custo deve ser justificado pelo benefício esperado. Se houver pouco benefício para o fornecedor em manter um determinado recurso, não há razão para oferecer suporte.


1 - Eles não são realmente totalmente sem suporte; eles são suportados com base no "melhor esforço", o que significa "Podemos ter uma nota técnica em algum lugar que descreva resumidamente o recurso, mas não perderemos muito tempo ajudando você a fazê-lo funcionar, e se não funcionar ou se apagar seus dados, bem, difícil ".

1 Joshua Oct 28 2020 at 01:57

Lembro-me de ter que usar um há muito tempo. Já tentou alterar o nível de compatibilidade SQL de um banco de dados de dentro de uma transação? Acontece que você pode, se copiar o conteúdo do sp_comando que o fez. (Aviso de isenção de responsabilidade: este código só precisava funcionar exatamente no SQL 2005 e seu último service pack já havia sido lançado.)

Antigamente, os recursos que você só deveria ser capaz de acessar a partir da IU eram implementados usando vários tipos de sp_comandos ou xp_comandos de chamada de sintaxe não padrão . xp_os comandos eram programados, mas não havia muitos deles. sp_comandos apenas continham TSQL que fazia coisas. A maneira como foram realmente implementados não estava documentada, mas você poderia usar sp_helptextpara ler o código. Fazer isso geralmente era uma má ideia.

Então, há mais um recurso não documentado que as pessoas ainda usam. As funções hash de senha antigas do SQL 7 ainda estão lá e podem ser chamadas. Eles estão há muito tempo indocumentados e ninguém deveria usá-los mais, mas se você tiver um aplicativo antigo que ainda precisa verificar as senhas alteradas pela última vez no século anterior, é o único jeito.

E há ALTER DATABASE SET EMERGENCYisso que costumava ser algo ainda mais selvagem em versões ainda mais antigas. A MS foi forçada a fazer um comando documentado adequado por causa de pessoas que encontraram o comando não documentado e perderam o resto do procedimento para usá-lo. Nesse caso, a preguiça os alcançou.