Arquivo da categoria ‘Administração’

Olá pessoal,

Hoje eu recebi um servidor que foi clonado de outro server que já tinha o SQL Server instalado e o serviço do SQL Server não iniciava.

Pelo Event Viewer em Windows Log\System a mensagem era a seguinte:

The SQL Server (INSTANCENAME) service terminated with service-specific error The requested address is not valid in its context..

Pesquisando na web eu não encontrei muita coisa sobre esse erro acima, então fui investigar mais no Event Viewer e nos eventos de Windows Log\Application e encontrei a seguinte log:

Could not start the network library because of an internal error in the network library.

SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

TDSSNIClient initialization failed with error 0x2741, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. The requested address is not valid in its context.

Server failed to listen on XXX.XXX.XXX.XXX <ipv4> XXXX

Opa… XXX.XXX.XXX.XXX era um IP…hummm as coisas começaram a ficar mais claro e fui no SQL Server Configuration Manager olhar o SQL Server Network Configuration em TCP/IP e heis que nas configurações de IP4 estava um IP que não era o do servidor, provavelmente do servidor que foi clonado.

Bom, foi só alterar o IP para o IP correto do servidor e o serviço subiu perfeitamente.

É isso aí pessoal, espero que isso possa ajudar vocês!

Olá pessoal,

Minha área não é e nunca foi PowerShell, mas aqui onde trabalho a equipe administra mais de 500 servidores e sabe-se lá quantas instâncias e estávamos com a necessidade de criar os usuários locais no Windows Server para todos os membros da equipe de DBA.

Com um pouco de pesquisa na internet e a ajuda do meu grande amigo Laerte Junior(blog) eu consegui montar um script que cria facilmente os usuários locais e adiciona no grupo de Administrador. Eu testei esse script nas versões Windows Server 2008/R2 e Windows Server 2012 e funcionou perfeitamente.

Segue o script:


param($username,$password)

$objOu = [ADSI]"WinNT://localhost"
$objUser = $objOU.Create("User", "$username")
$objUser.setpassword($password)
$objUser.SetInfo()
$objUser.PasswordExpired = 0
$objUser.SetInfo()
$objUser.UserFlags.value = $objUser.UserFlags.value -bor 0x10000
$objUser.SetInfo()

$group = [ADSI]"WinNT://localhost/Administrators,group"
$group.Add("WinNT://$username,user")

$Account = [ADSI]"WinNT://localhost/$username,user"
if($Account.Name)
{
 Write-Host "Usuário $username criado com sucesso..."
}

Se desejarem que o usuário troque a senha no primeiro logon basta substituir a linha:

$objUser.PasswordExpired = 0

Pela linha:

$objUser.PasswordExpired = 1

Para executar esse Script eu criei um batch para facilitar a criação de vários usuários.

Segue o batch:


powershell Set-ExecutionPolicy RemoteSigned

powershell createuser.ps1 NomeUsuario1 Senha1

powershell createuser.ps1 NomeUsuario2 Senha2

Lembrem-se de colocar o arquivo batch e o ps1 no mesmo diretório e executar o batch como administrador(Run as Administrator)

Espero que isso ajudem vocês.

Abraços do Japa…

Fala galera,

Uma forma rápida para descobrir desde quando o SQL Server está rodando é a seguinte:


SELECT sqlserver_start_time FROM sys.dm_os_sys_info

 

Abraços e até uma próxima

Olá pessoal, no post de hoje eu vou falar um pouco sobre rotinas de manutenção.

Acredito que a grande maioria dos DBAs fazem as rotinas de manutenção como backup, reindexação e checagem de integridade via MP(Maintenance Plans) que no final das contas é SSIS(SQL Server Integration Service). Eu não vejo problema algum em fazer via MP, inclusive eu por muito tempo fiz por ele, até surgir uma instância com bancos de dados do Sharepoint para eu administrar e foi aí que começaram meus problemas. O que acontece é que o Sharepoint cria vários bancos de dados, pois é um banco para cada serviço dele e na instância que eu administrei eram 72 base de dados e o administrador do Sharepoint instalava e desinstalava novos serviços e ao fazer isso bancos eram criados ou apagados e foi aí que começaram meus problemas, pois as rotinas de manutenção via MP se perdiam pelo fato de ser necessário especificar explicitamente os bancos envolvidos na rotina ao tentar fazer backup ou demais rotinas de um banco que não existia mais dava erro e tão grave acontecia quando um banco não entrava nas rotinas, ou seja, eu tinha que ficar monitorando todos os dias se foi criado ou apagado banco.

Foi então que eu comecei a procurar uma saída para esses problemas. Pensei em criar minhas próprias rotinas de backup, reindexação e checagem, mas preferi antes procurar na internet pois acreditei que eu não seria o primeiro a passar por tais problemas e heis que encontrei as rotinas do Ola Hallengren que caíram como uma luva no ambiente, pois diferente do MP que é fixo o nome dos bancos, nela é mais flexível, podendo especificar os bancos ou se não especificar ela faz de todos os bancos e o mais legal é que você pode especificar somente um pedaço do nome dos bancos, pois as rotinas dele aceita wildcard.

As rotinas estão disponíveis para download no próprio site dele que é o http://ola.hallengren.com/ e lá tem uma vasta documentação e exemplos de implementação. De início eu implementei da forma default como estão nos exemplos mas depois com o tempo eu fui lendo a documentação e vendo o que era ou não possível fazer.

A rotina do Ola hallengren serviu muito bem para outro problema que eu tinha com os bancos de dados do ERP Protheus da Totvs onde com o MP eu quase nunca conseguia completar a rotina de reindexação por normalmente os bancos passarem de 500 GB e simplesmente os pacotes do SSIS do MP dava erro e dificilmente eu conseguia identificar quais erros eram esses. Já com as rotinas mais inteligentes do Ola Hallengren os problemas foram sanados e com elas é possível você jogar os resultados das execuções de cada comando para uma tabela a parte, o que me facilitou muito meu trabalho.

Já que eu comentei em Protheus, para quem quiser se inteirar um pouco sobre esse banco de dados eu tenho um post que fala um pouco sobre o assunto. Basta acessar: http://wp.me/p2n5Jb-V

Por hoje é isso. Futuramente eu vou escrever sobre as formas de implementações dessas rotinas campeãs do Ola Hallengren, pois elas por muitos anos são vencedoras no site do sqlmag.

Até lá.

Olá pessoal,

Esses dias meu amigo Leandro Ribeiro (blog | twitter) solicitou no Twitter dicas sobre o banco de dados do Protheus e como eu dou manutenção no banco de dados desse produto, percebi que eu sabia vários detalhes que poderiam ser úteis para quem está começando a trabalhar com o Protheus agora.

Para quem não conhece o Protheus é um dos maiores ERPs do mundo, ele é desenvolvido pela empresa brasileira Totvs onde há alguns anos é líder de mercado nacional. A grande vantagem do Protheus é que além dele ser bem completo ele customizável, ou seja, você compra a licença do sistema e pode contratar um desenvolvedor para customizá-lo a seu gosto, já imaginou isso ? Já pensou se você pudesse fazer isso com qualquer software que comprasse ou utilizasse ? Pois é, por aí dá para sentir o poder do produto e dá para começar a perceber o porque ele é tão usado no mercado nacional, mas é claro que nem tudo são flores e é obvio que esse produto tem seus pontos fracos, algumas particularidades e é exatamente para discutir isso que escrevi esse post.

Vamos as dicas:

  1. Quase sempre o banco de dados se chama DADOSADV ou pelo menos começa com DADOS. Não me pergunte o motivo, pois eu não sei;
  2. A aplicação não acessa o banco de dados diretamente ela usa uma camada intermediária chamada Top Connect. O Top Connect quase sempre é instalado no mesmo servidor que o banco de dados, porém há casos em que ele é instalado em uma máquina exclusiva e então a aplicação se conecta ao Top e o Top se conecta ao SQL Server;
  3. O Protheus é multiempresa, porém ao contrário do que estamos acostumado a ver nas modelagens onde a empresa é identificada com um campo dentro de cada tabela, o banco do Protheus cria uma tabela para cada empresa até a versão 10 do ERP, então se o teu cliente tiver mais de uma empresa aberta trabalhando no mesmo banco de dados, para cada empresa terá uma tabela de cliente, produto, nota fiscal e assim suscetivamente. Agora imaginem uma construtora do ramo imobiliário que para cada incorporação construída tem que ser aberto um CNPJ. Já pensou se ela tiver mais de 100 empreendimentos construídos ou em construção? O banco passará de 100 mil tabelas facilmente!
  4. A partir da versão 11 do Protheus já é possível criar as empresas dentro da mesma tabela o que diminui significativamente o número de tabelas dentro do banco de dados. Essa dica da versão 11 do Protheus foram dadas pelos amigos Bruno e Luiz Carlos nos comentários do post.
  5. O nome das tabelas não ultrapassam 6 caracteres e são representados da seguinte maneira: 3 primeiros caracteres é a família que aquela tabela pertence, os 2 próximos caracteres representa a empresa que aquela tabela pertence e o último caractere é reservado ao sistema, por exemplo a tabela de cliente da empresa 01 é a SA1010, da empresa 02 é a SA1020 onde SA1 é a família da tabela, 01 e 02 representa a empresa e o 0 no final é reservado. Como assim família ? Exemplo, cliente é SA1, fornecedor é SA2 e assim por diante. A Totvs considera que Cliente e Fornecedor pertencem à mesma família;
  6. O campo chave primária das tabelas é sempre o mesmo, ou seja, todas as tabelas tem um campo chamado R_E_C_N_O_ que é auto-incrementado pelo Top Connect e é a PK das tabelas;
  7. Os registros das tabelas nunca são deletados fisicamente. Todas as tabelas contém um campo chamado D_E_L_E_T_ e quando alguém excluí um registro no sistema, no banco de dados esse campo é preenchido com um *, então sempre que for fazer qualquer select lembrem-se de desprezar os registros deletados colocando na condição where D_E_L_E_T_ = ”, ou D_E_L_E_T_ <> ‘*’. Esse conceito de exclusão lógica foi herdado do DBF;
  8. Não existe campo DateTime nas tabelas. Todos os campo data são VARCHAR(8), nunca são nulos e são sempre preenchidos com 8 caracteres em branco para informar que estão vazios;
  9. Não existe campo NULL. Se o campo for numérico ele é preenchido com zero e se for String/Char é preenchido com espaços em branco. Em ambos os casos o preenchimento é feito via Constraint Default. Agora imaginem a quantidade de Constraint que cada tabela tem!;
  10. Muito cuidado ao criar índices nas tabelas, pois se você criar em uma terá que criar em todas, por exemplo: Se criar um índice na tabela de cliente SA1XX0 lembre-se de replicar esse índice para as demais tabelas de cliente caso tenha;
  11. O Protheus trabalha com um dicionário de dados próprio onde são definidas as tabelas, campos e índices então em uma atualização de versão é feita uma checagem do dicionário de dados com a estrutura do banco de dados e tudo que não estiver definido no dicionário será apagado, seja campo, índice ou tabela, portanto ao criar um índice utilizado em um trabalho de Tuning eu aconselho a criar uma rotina que diariamente verifica a existência desse índice e então caso não exista mais crie-o novamente. Eu costumo colocar tudo dentro do step de um job que diariamente consulta a sys.indexes pelo nome;
  12. Nunca crie um campo em uma tabela sem antes passar para o dicionário de dados do Protheus, pois ao abrir uma tela que use a tabela onde o campo foi criado, essa tela irá travar por não ter o campo no dicionário;
  13. O desempenho das consultas não são grande coisa, pois a maioria dos desenvolvedores Protheus não tem grandes habilidades e conhecimento sobre indexação, então é sempre bom dar uma checada nas consultas mais lentas e dar um help para a galera de desenvolvimento;
  14. Uma forma de ganhar espaço em disco com o banco do Protheus é usar a compressão de dados a nível de página caso o SQL Server seja Enterprise. Em testes realizados na tabela SB1(Produtos) com 28000 produtos, comprimindo apenas a tabela passou de 72 MB para 6 MB, ou seja, uma taxa de compressão de 91.66%;
  15. Os bancos geralmente são enormes então é válido pensar em uma estratégia de particionamento das tabelas;
  16. Índices não usados e duplicados não é excessão e sim regra, então é válido analisar isso e repassar para os desenvolvedores. Nunca apague um índice sem antes apagar no dicionário, pois as telas fazem essa verificação também em sua abertura e caso não encontre no banco elas travarão;
  17. O Top Connect não funciona em cluster devido ao hardlock que é quem licencia o Protheus e como em alguns casos ele é instalado no mesmo servidor do banco de dados, não será possível colocar ele no Service and Application do Cluster e quando ocorrer um Failover será necessário reiniciar o servidor de licença que fica geralmente em outro servidor, senão ele não voltará ao ar e a aplicação não abrirá;
  18. Não é possível fazer uma replicação merge das tabelas, devido fato da replicação merge adicionar um campo de controle de unicidade chamado rowguid e caso tenha um campo na tabela do banco e não tenha no dicionário do Protheus isso causa sérios impactos. Mesmo que não houvesse o impeditivo do campo rowguid, muitas tabelas ultrapassam 246 colunas e seria impossível replicar com merge devido o limite de 246 colunas por artigo;
  19. Devido o padrão das tabelas do Protheus não terem campos NULL e todos serem preenchidos com uma Constraint Default isso impede que as tabelas sejam colocadas In-Memory a.k.a Hekaton que é o novo recurso do SQL Server 2014. É possível desde que todas as Constraints Defaults sejam excluídas e os campos que são Not Null passem a ser Null, porém isso implicaria em uma grande mudança na modelagem do banco e os efeitos colaterais nesse tipo de mudança são incontáveis;
  20. Normalmente os bancos são muito grandes, então a rotina de manutenção de índices se torna uma tarefa difícil e quase impossível para a rotina do Maintenance Plan do SQL Server, portanto é válido usar rotina própria ou de terceiros como a rotina do Ola Hallengren.

Bom galera espero que essas dicas sejam úteis para todos. Conforme eu for me lembrando de mais coisas eu vou atualizando o post.

Até mais.

No último dia 26/07/2012 foi lançado o SP2 do SQL Server 2008 R2 que você pode baixar aqui.

Atentem-se as correções nele contida, pois você pode estar passando por algum problema já corrigido.

Aqui contém o KB da Microsoft que demonstra todas as correções.

Em um dos clientes que eu dou consultoria, administro um ambiente com 12 servidores e quando preciso executar algum script em todos os servidores fica inviável ir de um em um via Management Studio, abrir uma nova Query e executar o script.

Para facilitar meu trabalho nessas ocasiões eu uso o utilitário de comando que vem junto com o SQL Server a partir do 2005 chamado sqlcmd.

Para utilizar o sqlcmd basta ir no prompt de comando do Windows e sua sintaxe é bem simples como podemos ver abaixo.

Utilizando sqlcmd com autenticação SQL Server:

sqlcmd -S NomeServidor -d NomeBancoDados -U NomeUsuario -P Senha -i Caminho\NomeArquivo.sql

Utilizando sqlcmd com autenticação integrada:

sqlcmd  -E -S NomeServidor -d NomeBancoDados -i Caminho\NomeArquivo.sql

É isso aí galera, espero que isso possa ajudar muito vocês e facilitar um pouco o dia a dia.

Até a próxima.