TodoSQL Blog de SQL Server en español

Que tal !,como les fue en el día de hoy? para mi fue medio pesadito pues tuve problemas con técnico de pc bastante soberbio y con una falta de humildad increíble, para colmo se puso a decir que cualquiera tiene un titulo de Lic. en Sistemas, siendo que muchos son analistas, licenciados o bien sin titulo universitario y son capos en la materia. Porque decía esto? para resaltar a los demás que había obtenido el titulo de ing., pero lo grave de la cuestión es que la tarea que realiza es la de simple reparador de pc y por su forma de ser mucho no le sirve, salvo cerrar puertas por su falta de humildad y constancia en el aprendizaje cotidiano que demanda nuestra profesión y su aparente nulo cococimiento en las materias humanísticas como ética y moral profesional(Que se dicta en la carrera de ingenieria), para colmo la gente que en ese momento lo rodeaba era cisco admin, dba's, desarroladores senior,arquitectos de aplicaciones, etc. y muchos no necesitan de ese titulo pues ya son muy buenos profesionales. Cuando me recibi de licenciado, nos dieron una materia que se llama ética y moral profesional y se nota que aun a muchos las enseñanzas de esta fue por un camino sin retorno para llevarlo a la práctica y el trabajo en equipo de manera armoniosa.

Que harían en la situación que les conté ?.
Para finalizar, que bondadoso es nuestro país (Argentina) no ?.

Pasemos a lo técnico, hoy les voy a comentar algo con respecto a SQL Server 2000 y 2005 relacionados a los campos del tipo image.

En un entorno Windows2000-SQLServer2000 con sp3a, teníamos un DTS package o paquete de servicio de transformación de datos, cuyo código estaba destinado a la generación de bases con imágenes de 4GB c/u aprox. El origen de la data conteniendo el tipo de dato image, era una base de 100 GB de data aprox., el problema surgido era que debíamos reiniciar el server una vez por semana pues cuando el paquete se ejecutaba (una vez por semana) nuevamente a la otra semana varias bases las generaba con todos los campos excepto los campo del tipo image. Este inconveniente, cabe destacar, que no nos volvió a suceder cuando migramos de entorno, es decir, Windows2003 y SQLServer2005 sp1.

Abrazo virtual a todos y éxitos.

Gente que tal, como están !. Bueno les cuento algo rapidito, hoy recibí una consulta por un query con select anidados, donde tenian problemas de rendimiento o performance, el query tarda entre 24 a 36 hs por lo cual no es razonable y debe cancelarse. Las pautas que le dimos a la analista y desarrolladores de la aplicación es que tengan en cuenta los siguientes tips para poder mejorar la performance:

1) Depurar las tablas si es factible.
2) Verificar indices por criterio de filtro (campos en la sentencia WHERE)
3) De acuerdo al punto 2) chequear si la busqueda es por rangos o exacta.
4) Crear indices cluster para rangos.
5) Crear indices noncluster para busquedas exactas.
6) Si es factible, crear un covered index, es decir, campos a devolver (SELECT micampo1,micampo2) que formen parte del indice, pues de esta manera no accede a la tabla y realiza la busqueda y obtiene datos del indice y tenemos menos I/O.
7) Tratar analizar la consulta o query, para ver si cambiando el orden de result set(conjunto de registros resultado) ganamos en que sea menos mounstruoso la cantidad de registros en memoria.

Bueno me voy a casa, les mando un abrazo virtual a todos.

Gente, les comento un temita relacionado con MSSQLServer2K5, que es ”Cambio de nombre de servidor windows“. Les puede suceder que al cambiar el nombre del server, SQL Server tome el nuevo nombre (hostname) para todo lo que es conectividad al DBMS pero deben tener en cuenta que si utilizan tipo de funciones internas del motor como por ej: @@servername, les seguira informando el nombre del server antes del cambio y los script/codigo de aplicaciones comenzaran a fallar. Que deben hacer?, lo siguiente:

1) Chequear que nadie este conectado al motor y el nombre actual:

select * from sys.sysprocesses

si hay conexiones y todos los servicios están bajos, realizar un kill de los procesos reflejados.

2) Chequear el nombre actual.

select * from sys.servers

3) Correr las siguientes sentencias:

sp_dropserver 'viejo_nombre'
sp_addserver 'nuevo_nombre','local'

4) Verificar el cambio

select * from sys.servers

5) Bajar y subir el servicio mssqlserver del servidor afectado.

Y ahora si ejecutar la sentencia ‘select @@servername’ veremos que nos devuelve el nombre nuevo o correcto.

Bueno un abrazo virtual para todos y espero sirva !.

Hola como están, que lindo día de lluvia no ?, los días de lluvia están bárbaros para tomar mate con tortas fritas o escuchar la lluvia en un lugar tranquilo para meditar o bien hacer otras cosillas, no ?. Bueno y como digo siempre, pasemos a lo técnico, hoy les voy a contar algo relacionado a los problemas de performance que pueden llegara tener con las utilidad BCP o bien vía TSQL con BULK INSERT. Por ejemplo (luego en la parte II les voy a presentar dos escenarios), estan realizando operaciones con la utilidad BCP, con base, tablas y archivos con volúmenes idénticos, donde realizan la prueba primero en una PC y luego en un Servidor con todos sus recursos disponibles (sin carga transaccional, procesos de auditoria, ni mantenimiento) y el resultado de la misma arroja que en la PC tarda 20 min, mientras que en el Servidor 3 hs. Bueno, no nos llenemos de terror, sino lo que tenemos que chequear es el correcto funcionamiento de los discos-hd y las placas controladoras y básicamente en dos puntos:

1º Que no existan errores de hardware (HD y Placas controladoras).
2º Drivers de placas controladoras.

Una vez verificado y solucionado el problema proveniente de los puntos anteriores, todo toma su curso normal en los tiempos de respuesta.
En la segunda parte, les voy a plantear dos escenarios reales (lo sufrí en carne propia) de lo planteado anteriormente, pues hoy ya no tengo mas ganas de seguir escribiendo, ya que quiero ir a jugar con mi hija !.

Un abrazo virtual para todos !!!

JuanPL

Link's relacionados:
http://www.todosql.com/blog/200704/problemas-de-performance-con-utilidad...
http://www.todosql.com/blog/200704/problemas-de-performance-con-utilidad...

Hola gente !!!, como están ?, ayer estaba un poco bajoneado pues extrañaba a mi familia (ellos viven en el interior del pais y yo en la capital), pero bueno son cosas que pasan, lo bueno, es que cuando llegue a casa me encontre con unos amigos que hace mucho que no veia (viven en españa hace 2 años) y realmente me reconforto y rei mucho como hace largo tiempo no me reia !!!
Y como digo siempre pasemos a lo técnico, hoy voy a continuar con los escenarios que tuvimos que luchar con problemas de performance o rendimiento.

Escenario 1

Proceso: Operativa financiera cuya función era refrescar diariamente las cuentas de sus clientes antes de la atención al público, con lo cual la ventana horaria era limitada, pues, los procesos centralizados terminaban a una hora determinada, eran transmitidos y luego aplicados en el entorno distribuido, mediante una carga y actualización de la base de datos.

Entorno: Windows NT4.0 Enterprise Edition sp6a.
MS SQL Server 7.0 sp4

Técnica y herramientas: Job de SQL Server llamados por una aplicación, en cuyo código el núcleo funcionaba (funciona) con BULK INSERT tomando archivos (*.dat) generados por la aplicación para cargase en las tablas afectadas.

Síntomas: Tiempo de ejecución de procedimiento correcto, salvo, en el tiempo de los job´s de SQL Server (BULK INSERT).

Solución: Se chequearon niveles de sp´s de SQL Server y configuración del mismo la cual era la correcta. El problema era el mal funcionamiento de la placa raid.

Escenario 2

Proceso: Espejado de base de datos entre servidores distintos, mediante una aplicación que controlaba el proceso y generación de carga.

Entorno: Windows 2000 Enterprise Edition
MS SQL Server 2000 sp3a

Técnica y herramientas: Job de un scheduler propietario, que invocaba a la aplicación, en cuyo código el núcleo funcionaba (funciona) con la utilidad BCP generando archivos (*.txt) que luego impactaban en la base destino o ´espejada´.

Síntomas: Tiempo de ejecución de procedimiento correcto, salvo, en el tiempo de la operativa que utilizaba BCP en el momento de cargar la tabla y no de generar los archivos.

Solución: El problema era la desigualdad de drivers de las placas controladoras de disco.

Un abrazo virtual a todos y hasta la próxima.

JuanPL

Link's relacionados:
http://www.todosql.com/blog/200704/problemas-de-performance-con-utilidad...
http://www.todosql.com/blog/200704/problemas-de-performance-con-utilidad...

Hola buen día !!!!, como va !!!!, por suerte es viernes no ?, que vamos a hacer el finde ?, yo por lo pronto tratare de disfrutar a mi familia a full, jugando con mi bebú y compartiendo momentos con mi mujer. Pasemos a lo técnico, lo siguiente es una sugerencia que podemos tener en cuenta al momento de tener que realizar un restore de base de datos muy voluminoso desde un archivo de backup ya sea proveniente de cinta, algún storage tipo vts en mainframe o bien desde hd; donde para evitar problemas (por ej. cancela el restore de la base luego de 2,30 hs siendo un tiempo estimado de 6 hs), deberíamos chequear el archivo desde una sentencia sql como restore verifyonly, además, de haber tenido ciertos recaudos de chequeo de integridad, de esta manera podemos en 15 min(dependiendo de la velocidad de discos y volumen de archivo) evitarnos perdidas de tiempo sustanciales cuando se manejan volúmenes grande de data.
Los pasos y las sentencias serían las siguientes:

1° RESTORE VERIFYONLY FROM DISK =’d:\mssql.1\mssql\backup\mi_device.bak’
2° RESTORE DATABASE db FROM DISK=’d:\mssql.1\mssql\backup\mi_device.bak’

Nota:

No trabaja con snapshot, en este caso deben utilizar un DBCC CHECKDB.
Para volúmenes grandes estamos considerando 30 GB en adelante (Nosotros trabajamos con 150 GB en SQL Server).

Y como siempre un abrazo virtual a todos !!!.

Links relacionados:

Problema detectado (operating-system-error-1130)
http://www.todosql.com/blog/200709/operating-system-error-1130%28not-eno...