Haverá uma atualização no farm de virtualização do VMWare 6.7 para o VMWare 7. Tenho um cluster do SQL Server nesse farm, ambas as máquinas precisam estar inativas para realizar a atualização.
Qual é a melhor abordagem para o cluster do SQL Server:
Alguma outra opção para evitar possíveis problemas?
Movemos um banco de dados SQL Server para uma máquina virtual no Azure.
Como o banco de dados contém apenas dados históricos e não possui mais transações, queremos desligar e ligar a VM em uma programação para reduzir custos.
Até onde eu sei, a corrupção do banco de dados pode acontecer se a máquina reiniciar no meio de uma transação, então tenho três perguntas sobre isso:
A corrupção do banco de dados pode ocorrer em um banco de dados que não possui mais transações quando a máquina é desligada?
Existe uma maneira correta de desligar a máquina e evitar um cenário de corrupção?
Devemos deixar esta máquina funcionando 7 x 24?
Temos duas formas de provisionar o SQL Server em uma máquina virtual do Azure, uma é criar a VM e depois carregar os binários do SQL Server e fazer a instalação manualmente, a segunda é usar o SQL Server nas máquinas virtuais do Azure que fornece imagens do SO e a versão desejada no SQL Server.
A questão se aplica à segunda opção. Existe uma maneira de provisionar uma máquina virtual do SQL Server no Azure com uma instância nomeada ou sempre instala o padrão?
Essa pode ser uma pergunta boba mas recentemente criei um banco de dados azure sql e preciso verificar a política de backup mas não encontro a opção gerenciar backups que a documentação mostra como você pode ver na próxima imagem:
e é assim que a lâmina do meu banco de dados se parece
Estou esquecendo de algo?
Instalamos o sql server em uma máquina virtual e registramos a máquina para que a extensão de agente de IaaS do SQL Server (SQLIaaSAgent) seja habilitada e executada em máquinas virtuais do Azure para automatizar tarefas de administração para o sql server. Uma dessas tarefas é automatizar os backups como você pode ver na próxima imagem
Agora, para realizar os backups automatizados precisamos de uma conta de armazenamento, criamos essa conta de armazenamento e dentro da conta de armazenamento um contêiner de blob, mas o problema que temos agora é que quando estamos selecionando o armazenamento onde queremos que os backups vão só podemos selecionar a conta de armazenamento, mas não o contêiner. Então, para onde estão indo os backups? não conseguimos encontrá-los na conta de armazenamento, como podemos ter certeza de que os backups estão sendo feitos? e como podemos selecionar o armazenamento de blobs neste recurso?. desde já, obrigado
Estou tentando fazer backups em um armazenamento de blobs do azure que tenha a data em que o backup é feito, dessa forma o trabalho não falha quando o backup é gerado com o mesmo nome, estou concatenando convert(varchar(500),GetDate() ,112) + '.bak'), mas estou recebendo o próximo erro na execução do trabalho
Sintaxe incorreta perto de '+'. [SQLSTATE 42000] (Erro 102). A etapa falhou.
O roteiro:
Modelo de banco de dados de backup para url = 'https:containerurl/azurecontainer/model' + convert(varchar(500),GetDate(),112) + '.bak') go
Existe algum log, query ou alguma outra forma de ver quando foi feita uma alteração nas configurações de memória do SQL Server?
Devido ao fim do suporte do sql server 2008 R2, estamos planejando mover o banco de dados para o azure como um serviço paas (banco de dados sql do azure). No momento o servidor de aplicação possui o reporting services 2008 R2, por enquanto não será movido para a nuvem nem atualizará sua versão. Os usuários criam os relatórios, então eles os carregam para os serviços de relatórios e geram as informações desejadas, Minha pergunta é esta: como o banco de dados azure sql usa a versão mais recente do sql server, os usuários ou eu temos que refazer os relatórios em uma versão mais recente do construtor de relatórios ou ferramentas de dados do visual studio, ou os relatórios funcionarão da mesma maneira e a única coisa que tenho que modificar são as fontes de dados.
Herdei um banco de dados em que muitas das tabelas têm bigint como tipo de dados para muitos dos campos, e quando você vê o conteúdo ele não exige todo o espaço que o bigint oferece. O uso de bigint para campos que não precisam afeta o desempenho do banco de dados?
Antes de mais nada, meu inglês não é meu idioma principal.
Estamos criando um template azure para implantar uma máquina IaaS com discos C e D com windows server, e a ideia também é implantar uma instalação de sql server, então inicialmente os binários e arquivos do engine serão implantados nos drives C e D da unidade.
Temos algumas dúvidas para ver se é possível fazer no azure
É possível instalar através de um template não só o SO, mas também o SQL Server?
Caso a pergunta anterior seja possível fazer após a instalação do SQL Server, existe algum script ou guia para criar um script para mover os arquivos lógicos e físicos do sql server sem precisar entrar no sql server management studio e executar um script t-sql ou mover os arquivos manualmente?. A ideia por trás disso é automatizar ao máximo a implantação da Máquina Virtual e mover os arquivos para seus respectivos volumes para atender as melhores práticas do SQL Server em relação à separação dos dados de log dos dados do usuário e tempdb e também a reinicialização do a instância assim que as etapas anteriores forem concluídas.
ou existe uma forma de fazer a instalação do SO e SQL Server e no template especificar quais arquivos do banco de dados devem ir para um disco específico e evitar a movimentação em uma etapa posterior da implantação da máquina
desde já, obrigado
Existe algum motivo ou benefício de desempenho em ter dois arquivos de log para um único banco de dados e em unidades diferentes?
Por motivos de segurança, queremos alterar a senha que inicia o serviço SQL Server todos os dias. É possível fazer isso sem reiniciar o serviço?
Se for possível, as alterações serão aplicadas imediatamente ou, eventualmente, precisarei reiniciar o serviço para obter a nova senha?
Estávamos pensando em fazer essa alteração na opção de serviços do sistema operacional Windows e não no gerenciador de configuração do SQL Server.
Então eu herdei um servidor que tem sérios problemas de latência de gravação de acordo com um script fornecido por glen berry, também notei que os arquivos tempdb estão espalhados por várias unidades.
Quais poderiam ser os benefícios de ter arquivos Tempdb.ndf em unidades diferentes? existe algum? também a latência mais alta vem das unidades que hospedam esses arquivos tempdb