Buscar

El Blog del Maldo

Si, es poco lo que escribo

Categoría

SQL Server

Crecimiento automático grupo de archivos sqlserver.

Hace unos días tuvimos un problema con el servidor de base de datos, un sqlserver 2012 en una máquina muy potente, dentro de la base de datos tenemos guardadas unos archivos que usamos para el sistema, están con su grupo de archivos aparte y con un esquema de respaldo que no revienta nuestra capacidad de backups, pese a todo esto y que estábamos muy felices con la salud general del motor, la subida de archivos comenzó a fallar.

Primero le echamos la culpa al sistema, porque claro la base no puede ser… entramos a QA y no pillamos nada, luego culpamos al paso a producción, que se nos quedó algo… comparamos las bases de datos y nada, comenzamos probando el resto del sistema y funcionaba sin problemas, solo fallaba el subir archivos, miramos la base pensando que nos quedamos sin espacio … y ni por lejos, habían cientos de gigas libres, descartado todo miramos la base.

En una revisión solo encontramos una cosa rara, que el grupo de archivos que correspondía a los archivos no crecía, miramos salud, bien, indices, bien, todo bien, pero no crecía, hasta que dimos con el problema, el grupo de archivos era muy grande, pesaba 27 gigas y el crecimiento del grupo de archivos estaba configurado al 10%, al parecer hacer crecer el archivo en más de 2 Gigas causa problemas, en nuestro caso fue imposible hacerlo crecer con esta configuración, cuando cambiamos la configuración a un crecimiento de 200 megas, todo volvió  a la normalidad sin problemas, al parecer, según el reporte de microsoft, el crecimiento no tiene máximo para los archivos, pero dependiendo de los discos duros y el tamaño del crecimiento puede caer por time out, que es justamente lo que ocurría, al demorar demasiado el sistema revertía el crecimiento y no crecía nada.

Para tener en cuenta a la hora de configurar, por algo se recomienda un crecimiento fijo y no porcentual, pero no sabíamos por qué.

Transacción distribuida con NAT

Después de pelear toda la mañana con unos servidores, tratando de hacer funcionar las transacciones distribuidas y dejar conforme al administrador de redes, lo que he descubierto es tan raro que no puedo dejar de compartirlo con el mundo, por eso sacrificaré unos minutos de mi horario de almuerzo para poder dejar el conocimiento en Internet porque no encontré en ninguna parte la respuesta, así que ahí va el problema.

Tenemos dos servidores de base de datos SQL Server, conectados entre si por linked servers, se ejecuta unos procedimientos almacenados entre servidores guardando las respuestas de estos en tablas temporales (si si si… lo interesante es la solución del problema no lo feo de la implementación).

Hace poco migramos uno de los servidores y da un error al ejecutar la consulta el error siguiente.

Servidor: Msj 7391, Nivel 16, Estado 1, Línea 2
No se puede realizar la operación. El proveedor OLE DB ‘SQLOLEDB’ no pudo iniciar una transacción distribuida. Mensaje devuelto por el proveedor OLE/DB: No se puede dar de alta la nueva transacción en el coordinador de transacciones especificado.

Este error lo teníamos anteriormente pero se solucionaba muy rápido al levantar el coordinador de transacciones distribuidas de Windows, ahora no resultaba, ¿cual era la diferencia entre las configuraciones antiguas y nueva?, se incorporó un firewall y un NAT porque los servidores no se encontraban en la misma red.

Luego de indagar (Muuuuuuucho) encontramos que el puerto de las transacciones distribuidas era el 135 y debía ser abierto, como el administrador de redes es medio exquisito no quería que fuera bidireccional así que lo abrimos de un lado para otro, como es medio complicado voy a añadir un esquema.

 Diagrama de conexion de los elementos

Entonces se supone que para que se comunicaran servidor A con servidor B por medio del linked Server se debía abrir el puerto 1433 (defecto de SQL Server)  y listo, como es una transacción distribuida se tenía que abrir puerto 135 desde servidor B a servidor A, pero no fue suficiente, desde servidor B a Servido A teníamos que abrir los puertos desde 1025 a 1029 TCP, por que abre un puerto aleatorio entre estos, que corresponde a la comunicación de RCP. Y ESO ES LO QUE NADIE TIENE DOCUMENTADO!!!, bueno eso, espero que si alguien necesita aprenda.

A bueno lo otro es que existía un Nat entre servidores se ocupó la IP de las Nat para abrir los puertos.

Blog de WordPress.com.

Subir ↑