Como resetar senha de usuário MS-SQL

Para efetuar os comandos é necessário ser administrador da base e que os logins sejam do SQL.

O link acima utiliza dois comandos:

Se usando o query analyser, selecione a base a ter o usuário ajustado. Caso contrário execute:

use DATABASE
go

Em seguida:

sp_change_users_login 'update_one', 'LOGIN', 'LOGIN'

Para mudar a senha de LOGIN:

Se usando o query analyser, selecione a base MASTER. Caso contrário execute:

Use master
go

Em seguida execute:
sp_password NULL, 'ok', 'test'

Configuração da faixa de porta local

Configuração da faixa de porta local para conexões TCP no Windows 2003 Server

para a configuração da faixa de porta local é necessário ter prerrogativas de administrador.

• Executar o regedit (Iniciar/Executar/regedit.exe)
• Localizar a chave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
• Adicionar uma chave nova de valor tipo DWORD com nome MaxUserPort
• Inserir um valor entre 5000 e 65535

Instalação de Disco maiores de 120gb

Instalação de Disco maiores de 120gb no Windows 2000 Server

Execute o regedit
Navege ate a chave HKEY_LOCAL_MACHINE \ SISTEMA \ CurrentControlSet \ serviços \ atapi \ parâmetros
Do menu da edição, selecione adciona um novo valor de "DWORD"
após adciona coloque o nome "EnableBigLba" a seguir edite a chave que foi criada
ajuste o valor para 1.
feche o editor do registro, e reinicie o windows

SQL Server - Base Suspect e agora????

Base Suspect - Recuperar Database após corromper o Log de Transação

Cenário:

Vamos criar um database em seguida vamos simular um erro de Log corruption, e vamos realizar alguns procedimentos para torná-lo operacional novamente.

Passo a passo (Reprodução):

1 - Criar um database de nome Teste no servidor SQL Server:

CREATE DATABASE Teste
ON (NAME='Teste_Data', FILENAME='D:TempTeste_Data.MDF')
LOG ON (NAME='Teste_Log', FILENAME='D:TempTeste_Log.LDF')

2 - Pare o serviço do SQL Server.
3 - Renomeie o arquivo de Log.
4 - Inicie o serviço do SQL Server.
5 - Verifique o status do database pelo Enterprise Manager, provavelmente estará em Suspect.
6 - Faça um detach no database:

EXEC sp_detach_db 'Teste'

7 - Localize os arquivos de dados (.mdf) e log (.ldf) e renomei-os para um nome qualquer.
8 - Crie um novo database com o mesmo nome do banco corrompido, conforme passo 1.

Nota: Na medida do possível é recomendado que os arquivos deste novo banco tenham o mesmo tamanho que os arquivos do banco corrompido.

9 - Pare o serviço do SQL Server.
10 - Localize os arquivos de dados (.mdf) e log (.ldf) do banco recém criado e renomeie os arquivos para o nome dos arquivos originais (banco corrompido).
11 - Inicie o serviço do SQL Server.
12 - Verifique o status do database pelo Enterprise Manager, provavelmente estará em Suspect.
13 - Vamos tentar "zerar" o status do database para o modo operacional.

EXEC sp_resetstatus 'Teste'

Nota: Neste passo verificamos que o comando acima retorna que nada foi alterado.

14 - Vamos novamente tentar colocar o database operacional, utilizando um comando DBCC não documentado.

DBCC DBRECOVER (Teste, ignoreerrors)

Server: Msg 5173, Level 16, State 1, Line 1
Cannot associate files with different databases.
Log file 'd:TempTeste_Log.LDF' does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

A mensagem acima indica que o arquivo de Log encontrado não é correspondente ao Primary Data File.

15 - Sendo assim, vamos fazer um "rebuild" no arquivo de Log para que nosso database torne-se operacional.

EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO
BEGIN TRANSACTION
UPDATE sysdatabases SET status = 32768 WHERE name='Teste'
COMMIT TRANSACTION
GO
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO

15.1 - Vamos novamente verificar o status do nosso database no Enterprise Manager.

Agora ele deve apresentar-se em "Emergency Mode", neste status conseguimos realizar um "rebuild" no Log, para isso vamos utilizar um outro comando DBCC não documentado:

USE master
GO
DBCC REBUILD_LOG('Teste','D:TempTeste_Log_new.LDF')

A seguinte mensagem deverá ser exibida:

Warning: The log for database 'Teste' has been rebuilt. Transactional consistency has been lost. DBCC CHECKDB should be run to validate physical consistency. Database options will have to be reset, and extra log files may need to be deleted.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

16 - Após os procedimentos do passo 15, vamos corrigir as inconsistências que por ventura possam ter ocorrido nesse "rebuild".

DBCC CHECKDB('Teste')

Caso ao final dessa checagem sejam encontradas inconsistências, execute:

EXEC sp_dboption 'dbo use only', false
GO
EXEC sp_dboption 'single user', true
GO
DBCC CHECKDB('Teste', REPAIR_FAST)

Se mesmo após o REPAIR_FAST continuar encontrando inconsistências execute:

DBCC CHECKDB('Teste', REPAIR_ALLOW_DATA_LOSS)

Nota: Este procedimento deve ser executado em último caso, pois como o próprio nome diz, existe a possibilidade de perda de dados.

Ao final dessa checagem verifique novamente se existem inconsistências executando o comando DBCC CHECKDB do passo 16.

17 - Caso não existam mais inconsistências, devemos colocar nosso banco operacional novamente, sendo assim execute:

EXEC sp_dboption 'single user', false

Pronto, a partir deste ponto o database deverá ficar operacional novamente. Lembre-se de realizar um backup full