Encuentre el puerto que utiliza MS SQL Server para establecer conexiones

De manera predeterminada, SQL Server escucha en el puerto 1433 de TCP / IP y 1434 de UDP para las emisiones. Usted puede encontrar el puerto de escucha de varias formas:

1. Chequear la aplicación del Registro de Eventos de Windows- ID de evento 26022.
2. Usar el Administrador de Configuracion de SQl Server (SQL Server Configuration Manager).
3. Consultar el Registro de Windows.

 

Aplicación del Registro de Eventos de Windows

Cada vez que se inicia una instancia, SQL Server registra el puerto de escucha (s) en el visor de sucesos de Windows.

1. En el menú Inicio, seleccione Programas o Todos los programas, seleccione Herramientas administrativas y, a continuación, haga clic en Visor de sucesos.
2. Si no se muestra el registro de aplicación, en el menú Registro, haga clic en Aplicación.

Si el filtro de Id. de suceso es 26022, hay cuatro eventos asociados con la puesta en marcha. Busque el evento que tiene esta en el cuerpo del mensaje:

He demostrado aquí que el nombre de la instancia "JOHNSQLSERVER" escucha en el puerto 49526. Como dije, hay cuatro eventos asociados con la puesta en marcha y los otros tres eventos informa el protocolo IPv6 y el puerto UDP de difusión:

El servidor está escuchando en [127.0.0.1 49527].

El servidor está escuchando en [:: 1 49 527].

El servidor está escuchando en ['any' 49526].

Asegúrese de buscar el mensaje en la imagen.

 

Administrador de configuración de SQL Server

Otra manera fácil y eficaz es utilizar el Administrador de configuración de SQL Server. Abrir y ampliar "SQL Server Network Configuration en el panel de la izquierda. Verá los elementos de menú para los protocolos de varias instancias. Solo haga clic en uno de los elementos de menú de protocolo y obtendrá una lista de protocolos para esa instancia que aparece en el panel de la derecha. Haga clic derecho en ‘TCP/IP’ y ​​seleccione ‘Propiedades’.

 ':

Elija la ficha "Direcciones IP". Desplácese hasta la parte inferior de la lista hasta encontrar la seccion 'IPAll’. El ‘ajuste del Puerto TCP’ tendrá el puerto de escucha, a menos que la instancia está preparada para escuchar de forma dinámica. Si es así, la configuración de 'Puertos dinámicos TCP’ contendrá el puerto de escucha:

 

Utilizando el registro de Windows (via TSQL)

El registro de Windows almacena esta información. Que se pueden leer con la siguiente sentencia:

DECLARE @InstName VARCHAR(16)



DECLARE @RegLoc VARCHAR(100)



SELECT @InstName = @@SERVICENAME



IF @InstName = 'MSSQLSERVER'

  BEGIN

    SET @RegLoc='Software\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib\Tcp\'

  END

 ELSE

  BEGIN

   SET @RegLoc='Software\Microsoft\Microsoft SQL Server\' + @InstName + '\MSSQLServer\SuperSocketNetLib\Tcp\'

  END



EXEC [master].[dbo].[xp_regread] 'HKEY_LOCAL_MACHINE', @RegLoc, 'tcpPort'

Esto devuelve el Puerto como se muestra aquí:

Conclusión

Hay varias formas para determinar el puerto en el que una instancia de SQL Server está escuchando. Si tiene problemas para conectarse, utilice una de las técnicas descritas aquí para confirmar que se conecta al puerto correcto.

Mejores Prácticas para usar las cuentas de servicio de SQL Server

La seguridad de SQL Server es una de las principales prioridades del cualquier DBA de SQL Server. Es extremadamente importante que los DBAs y los Administradores de Sistemas se aseguren que SQL Server,  no se exponga a usuarios que no necesiten acceso a SQL Server. Solo los usuarios válidos y necesarios se le deben conceder los permisos “necesarios”.

Además de configurar los permisos adecuados para los usuarios de SQL Server, también es muy importante seleccionar la cuenta correcta para ejecutar los servicios de SQL Server. Hoy vamos a explorar cuando utilizar las cuentas de servicio para ejecutar los servicios de SQL Server.

Cuando usar Cuentas de Usuario de Dominio

Si SQL Server interactúa con otros servidores, servicios o recursos en la red (Por ejemplo: Recursos Compartidos, etc) o si los servicios de SQL Server utiliza Linked Server para conectarse a otros servidores SQL Server en la red, entonces usted puede utilizar una Cuenta de Usuario de Dominio con bajos privilegios para la ejecución de  los servicios de SQL Server. La cuenta de Usuario de Dominio es la cuenta más recomendadas para la creación de servicios de SQL Server que interactúan con otros servidores de la red. Otro de los puntos a favor de la utilización de una Cuenta de Usuario de Dominio es que la cuenta es controlada por el Active Directory de Windows , por lo tanto la política de nivel de dominio en las cuentas se aplica a la cuenta del servicio de SQL Server.

Cuando usar Cuentas de Servicio de Red

NUNCA se debe utilizar la Cuenta de Servicio de Red para el funcionamiento de los servicios de SQL Server. Las Cuentas de Servicio de Red se comparten con otros servicios que se ejecutan el equipo local.

Todos los servicios de SQL Server que se ejecuta en la cuenta de servicio de red, pueden acceder a los recursos de red mediante el uso de las credenciales de la cuenta de equipo. Esta cuenta se muestra como "NET AUTHORITY \ NETWORK SERVICE" al configurar Servicios de SQL Server.

Cuando usar Cuentas de Usuario Local

Se usa cuando SQL Server no presenta interacciones con otros servidores, servicios o recursos en la red (Por Ejemplo: Recursos Compartidos, Servidores Vinculados, etc) , entonces puede usar una cuenta de usuario local con privilegios bajos para el funcionamiento de servicios de SQL Server.

Nota: No es necesario que utilice la cuenta de usuario local con privilegios de Administrador para ejecutar los servicios de SQL Server.

Cuando usa una Cuenta del Sistema Local

NUNCA se debe utilizar la Cuenta del Sistema Local para el funcionamiento de los servicios de SQL Server. La Cuenta del Sistema Local tiene más privilegios de lo que imagina. Se trata de una cuenta integrada de muy alto privilegio creado por Windows.

La cuenta del sistema local tiene privilegios amplios en todo el sistema local y actúa como un ordenador de la red de su empresa. Esta cuenta se muestra como "NT AUTHORITY \ SYSTEM" al configurar los servicios de SQL Server.

Permitiendo la administración de los Jobs a usuarios que no son System Administrators en SQL Server Agent 2005 o superior

Antes de que llegara el Microsoft SQL Server 2005 al mercado, si usted deseaba que alguien tuviera acceso a ver, modificar, crear y ejecutar los SQL Server Agent Jobs, necesitaba darle permisos de sysadmin al login deseado de SQL Server, con el inconveniente que  también le iba a permitir hacer lo que deseara en esa instancia.

A partir del SQL Server 2005, se incluyeron los siguientes 3 roles:

SQLAgentUserRole: Los usuarios pueden crear jobs y manejar solo los jobs que ellos han creado.
SQLAgentReaderRole: Van a tener los privilegios del rol SQLAgentUserRole junto con la habilidad de enumerar y ver el historial de todos los jobs.
SQLAgentOperatorRole: Van a tener los mismos privilegios del rol SQLAgentReaderRole junto con la habilidad de ejecutar jobs locales de los cuales ellos no son dueños.

El procedimiento para asignarle permisos a un login en alguno de esos roles es el siguiente:

1. Agregue el usuario deseado a la base de datos “msdb”:

USE [msdb]

GO

CREATE USER [<User_Name>] FOR LOGIN [<User_Name>]

GO

2. Asigne el rol deseado al usuario:

USE [msdb]

GO

EXEC sp_addrolemember 'SQLAgentUserRole', '<User_Name>'

GO

Limpieza del Historial de Backups

SQL Server mantiene un historial de todos los Backups y Restore que se han hecho en el sistema. Nuestra organización realiza copias de seguridad y restaura con frecuencia y debido a esto nuestra Base de Datos msdb puede llegar a ser muy grande.

Como puedo purgar algunos de estos datos y liberar espacio en la Base de Datos?

Solución:

Son mantenimiento regular, las tablas del sistema puede crecer a tamaños muy grandes que conducen a un tamaño total grande para la Base de Datos msdb.

Estas tablas msdb incluyen:

backupfile

backupfilegroup

backupmediafamily

backupmediaset

backupset

retorefile

restorefilegroup

USE msdb;

GO

DECLARE @v_MaxDateHistory DATETIME

SET @v_MaxDateHistory = CONVERT(DATETIME,CONVERT(VARCHAR,DATEADD(MONTH,-3,GETDATE()),112))

EXEC sp_delete_backuphistory @v_MaxDateHistory;

GO

Debido a que los índices no son los apropiados en estas tablas, el procedimiento almacenado toma mucho tiempo en completarse ¿Cuál es la solución? Estos índices aceleran el proceso:

CREATE INDEX [media_set_id] ON [dbo].[backupset] ([media_set_id]);

CREATE INDEX [restore_history_id] ON [dbo].[restorefile] ([restore_history_id]);

CREATE INDEX [restore_history_id] ON [dbo].[restorefilegroup] ([restore_history_id]);

Para comparar:

SELECT count (*) FROM restorefile;

SELECT count (*) FROM restorefilegroup;

SELECT count (*) FROM restorehistory;

SELECT count (*) FROM backupfile;

SELECT count (*) FROM backupset;

SELECT count (*) FROM backupmediafamily;

SELECT count (*) FROM backupmediaset;