Onde começar a entender um banco de dados desconhecido

Então, o título resume tudo.

Eu tenho um banco de dados do SQL Server com 28 tabelas e 86 procedimentos armazenados que devem ter engenharia reversa. Tenho certeza de que algumas tabelas nunca são usadas e que nem todos os procs também são usados.

O maior problema é que todos os serviços do Windows que foram criados para serem usados ​​com esse banco de dados e toda a documentação do software e do banco de dados foram perdidos, e a pessoa que projetou o sistema inteiro está em nenhum lugar.

Já consegui criar um diagrama de ER para me ajudar a entender os relacionamentos, mas como não tenho experiência em administração de banco de dados, não tenho idéia de onde devo começar.

Também sinto muito se esse tipo de pergunta não foi feito aqui.

Três etapas muito rápidas para você começar:

1)

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

Dirá a última vez que cada índice foi usado, incluindo o índice clusterizado. Portanto, pelo menos, forneça uma amostra de quais tabelas estão sendo acessadas (e quais não estão).

2) Ative uma sessão de Eventos Estendidos (ou rastreio do Profiler do lado do servidor, se você estiver executando o pré-SQL 2012) por uma hora ou mais enquanto o aplicativo estiver sendo usado. Você também pode solicitar que um usuário execute várias ações no aplicativo em uma ordem específica, para correlacioná-lo com o rastreio / sessão.

Uma sugestão útil: se você pode modificar a cadeia de conexão que o aplicativo usa, acrescente "; Nome do Aplicativo = AppNameGoesHere" para poder executar um rastreamento rastreando esse Nome do Aplicativo em particular. Boas práticas de qualquer maneira.

3) Obtenha uma versão do aplicativo trabalhando em um servidor que não seja de produção. Desenvolva uma lista de testes orientados por comportamento para o aplicativo ("Quando o usuário clica no botão Novo Item, ele cria um novo item para esse usuário" etc.) Comece excluindo objetos que você não tem nenhuma influência nos testes, renomeando-os. (Eu uso um formato como objectName_DEPRECATED_YYYYMMDD - com a data no dia em que pretendo realmente excluí-lo.) Reverifique todos os seus testes.

Por meio de uma combinação da sessão de Eventos estendidos, da DMV de uso do índice e da exclusão suave, você deve poder identificar os principais objetos que estão sendo usados ​​pelo aplicativo e um bom consenso geral sobre qual objeto faz o quê.

Boa sorte!

Sua melhor aposta para começar é documentar seu banco de dados usando o SQL Power Doc

Documentação do SQL Server e do Windows usando o Windows PowerShell

O SQL Power Doc é uma coleção de scripts e módulos do Windows PowerShell que descobrem, documentam e diagnosticam instâncias do SQL Server e suas configurações subjacentes de SO e máquina do Windows. O SQL Power Doc funciona com todas as versões do SQL Server do SQL Server 2000 a 2014 e todas as versões do Windows Server e Windows Operating Systems do Windows 2000 e Windows XP ao Windows Server 2012 R2 e Windows 8. O SQL Power Doc também é capaz de documentação dos bancos de dados SQL do Windows Azure.

Nota: Eu o usei e isso lhe dará um bom começo para documentar e entender sua instância do servidor de banco de dados.

Como eu já estive em uma situação semelhante, posso dizer que esse será um trabalho difícil ou impossível. Eu só tinha código fonte (> 100k linhas de código), o serviço em execução, o banco de dados em execução (~ 50 tabelas) e nenhuma documentação e ninguém para perguntar sobre ele, exceto um usuário desse aplicativo e uma cópia do banco de dados e serviços em execução no um ambiente de teste (que estava com alguns números de versão à frente, mas sem código fonte). Outro requisito era que os serviços precisassem ser executados 24 horas por dia, 7 dias por semana, porque eram externos aos clientes. A situação surgiu porque a maioria dos funcionários saiu quase ao mesmo tempo, incluindo os desenvolvedores e a documentação desapareceu no caos. Levei mais de 6 meses para obter uma visão geral / documentação aproximada. Havia muitas tabelas e funções que não tiveram efeito porque eram para uso futuro ou nunca foram totalmente implementadas, recursos defeituosos, obsoletos ou não lançados. Após os seis meses, tive que reescrever a documentação, porque descobri coisas novas ou relacionamentos entre as coisas e, antes, tinha suposições erradas.

Por que estou dizendo isso? Porque, às vezes, em tal situação, é mais fácil e mais barato começar do zero e escrever um novo aplicativo que atenda aos requisitos do antigo (ou novos, se eles forem alterados ao longo do tempo ou se você desejar uma nova versão principal). Ou para lhe dizer o que você terá que esperar.

Se você realmente deseja fazer engenharia reversa, recomendo as seguintes etapas:

• Faça um backup de todo o sistema! (Primeiro: você nunca saberá quando precisará. Segundo: você precisará para a próxima etapa)
• recrie uma cópia do sistema (serviços e banco de dados) para trabalhar e anote como criá-lo, porque você certamente precisará fazer isso várias vezes nos próximos meses, porque você estragará várias vezes enquanto faz engenharia reversa
• crie um diagrama de ER com as dependências entre as tabelas
• visualize e documente as dependências de cada tabela, procedimento armazenado, ... porque geralmente não são incluídas nos diagramas de ER
• entender o que o software deve fazer perguntando aos usuários e utilizando-o (melhor no sistema de teste)
• Se o código-fonte dos serviços estiver disponível: obtenha uma visão geral e chame o banco de dados e documente-o (doxygen é uma boa ferramenta para obter uma documentação aproximada com hierarquias de chamada de função)
• tente obter uma visão geral aproximada do banco de dados observando os nomes de tabelas e suas colunas
• assistir o banco de dados enquanto o usa
• com as 4 etapas anteriores, divida as tabelas em 3 categorias (pode ser diferente para você, dependendo do seu aplicativo): dados estáticos (dados que não mudam durante a execução do servidor como a configuração do servidor, enumeração para restringir valores válidos em outras tabelas usando chaves estrangeiras) , ...), dados de configuração (dados que raramente mudam, como configurações do usuário, ...) e dados OLTP (mensagens do usuário no servidor de bate-papo, postagens em um fórum, valores de medição em um sistema de controle de máquina, batalhas em um jogo online, ...)
• repita as 5 etapas anteriores até ficar satisfeito ou desistir
• Documente e codifique como se o cara que acabasse mantendo SEU código / sistema / banco de dados fosse um psicopata violento que sabe onde você mora.

Desejo boa sorte ;)

Não tenho representante suficiente para postar um comentário, mas queria ajudar com sua pergunta sobre

getting the SQL Power Doc to work.

Se você seguir as etapas na página de documentação, elas funcionarão com bastante facilidade. Basta começar do topo.

https://sqlpowerdoc.codeplex.com/wikipage?title=Guide%20For%20PowerShell%20Beginners