Se você foi perguntado se um sistema poderia sustentar o crescimento duplo, o que 3 coisas que você faria para resposta?

Question

Vamos dizer em seu trabalho seu chefe diz:

Esse sistema por lá, que perdeu todo o conhecimento institucional, mas parece estar a correr muito bem agora, podemos despejar o dobro dos dados nele e sobreviver?

Você está completamente familiarizado com o sistema.

É no SQL Server 2000 (principalmente um aplicativo de banco de dados).

Não há ambiente de teste.

Você pode ser capaz de seqüestrar ele nos fins de semana se for necessário para executar um benchmark.

Quais seriam as 3 coisas que você faria para convencer a si mesmo e, em seguida, seu gerente que você poderia assumir essa carga extra. E se você não poderia fazê-lo, no mesmo hardware ... o hardware extra (medido em dólares) que seria necessário para satisfazer esse pedido.

Para resolver a resposta do doofledorfer, você pressupostos são quase todos os 180 graus fora. Mas isso é minha culpa por uma questão ambígua.

1. Um dos principais servidores corre 7x24 a 70% de base e picos de lá e ninguém sabe o que está fazendo.

2. Isto não é uma questão de buy-in ou lamentar-se ... Nossa empresa pode não ter muita escolha no assunto.

3. Uma vez que este está sendo mandatado externamente, os atrasos na execução pode resultar em multas enormes. Tão grande reunião para avaliar o risco é quase impossível. Há um risco, que o dumping dobro dos dados levaria o sistema para baixo para os clientes existentes.

Eu estava esperando que alguém diria algo como, veja se você levar o sistema off line domingo à noite à meia-noite e executar testes SQLIO para ver o quão perto o subsistema de armazenamento é a saturação. Coisas assim.

Answer 1

1. Configurar um ambiente de teste, mesmo se eu tiver que fazê-lo no meu laptop.

2. Ativar algum tipo de registo no sistema de produção para ter uma idéia do volume de transações, além do volume de dados.

3. Leia o código-fonte como eu executar testes de estresse no meu laptop com quantidades crescentes de dados.

Dito isto, eu simpatizo com esta atribuição, porque é injusto. É como pedir alguém em um barco se o barco pode flutuar com o dobro da carga -. Mas você não pode sair do barco ou tirá-lo do seu serviço regular

Answer 2

Você acaba de descrever um projeto típico Agile. Sua resposta deve ser:

1. eu não sei, e eu não vou ser capaz de dizer sem testes.
2. Além de volume de dados, pode haver problemas com padrões de uso, interações de aplicativos, ajuste de banco de dados e servidor, etc.
3. Então, vamos trabalho através de uma lista básica de fatores de risco, e como podemos resolvê-los.
4. Uma vez que tenhamos feito isso, o trabalho de deixar passar-los em ordem inversa de risco; e fazer um stop / continuar decisão à medida que desenvolvemos os resultados.
5. etc.

Sem management buy-in e participação, pelo menos nesse nível, qualquer outra resposta que você pode dar é de alto risco que desejam, e "3 mais importante" é um non sequitur.

Eu seria otimista a menos que seu sistema atual é substancialmente já carregado. A maioria dos servidores deve funcionar a capacidade de menos de 50% em todos os recursos, ou então estar no suporte de vida. E eu espero que você não estaria tendo a conversa se o servidor existente já estavam lidando com problemas de carga; embora "parece estar a correr muito bem agora" é suficiente imprecisa para ser preocupante.

Answer 3

na maior parte depende do seu nível atual. Se duplicação vai de 2GB a 4GB apenas fazê-lo. Se ele vai de 1TB 2TB você tem algum planejamento para fazer.

Eu coletar algumas informações usando o Monitor de Desempenho e fornecê-lo para ajudar a fazer uma decisão educada.

Answer 4

Depende do que você entende por "duplicar os dados".

Se isso vai afetar uma tabela única (tabela de produtos digamos), então provavelmente você está seguro como a maioria das consultas que são referentes a essa tabela um é mais provável que o dobro do tempo de execução (que assume que você não faz referência a mesmo tempo duas vezes em uma consulta).

O problema surgirá se você dobrar a quantidade de dados em todas as tabelas como o tempo de execução pode crescer de forma exponencial, em seguida, e pode levar a alguns problemas graves.

Mas, em geral eu apoiaria o resposta por doofledorfer