Es como dices. La principal causa de los deadlocks y de los problemas de concurrencia en SQL 2000 y anteriores se debe a que no estan bien diseñadas y normalizadas las bases y cuando se hacen actualizaciones no se respetan las relaciones seleccionando las mas adecuadas para evitar las esperas circulares y minimizando los bloques de transaccion a espensas de tener que armar transacciones de correccion en procesos reenganchables y por sobre todo, no controlar los errores y condiciones y reintentar.
Si les interesa hay una critica muy interesante a los niveles de aislamiento definidos en el ANSI en el sitio de reesearch de MS Oracle hace rato y SQL Server 2005 salen de la especificacion estandar del 92. Saludos -- -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting . 2008/4/21 Esteban Grinberg <[EMAIL PROTECTED]>: > Mariano, esto de acuerdo que usar NOLOCK alegremente en cada consulta de > una base no es la mejor opcion. > Ahora, lamentablemente hasta las versiones anteriores al SQL Server 2005, > el problema con los deadlocks era muy habitual en entornos concurrentes. > Tuve muchos mas problemas por lejos de dealock con SQL Server que con > Oracle, que usa por defecto un tipo de transaccion similar al snapshot de > SQL 2005. > Un mejor diseño de la base, un uso adecuado de los indices y de las > transacciones reduce estos problemas. Pero una vez que un sistema esta > desarrollado, cambiar el modelo puede ser una tarea casi imposible. > Entonces, si aceptamos perder cierta confiabilidad de los datos (cosa que > muchas veces no es aceptable), el NOLOCK funciona. Si, es verdad que vamos a > tener lecturas sucias, fantasmas, duplicadas, etc, pero es un costo que uno > al usar el NOLOCK sabe (o deberia saber) que paga. > No es la solucion ideal, estoy de acuerdo, pero a veces es eso a tener que > por ahi reescribir una parte importante de la capa de datos de una > aplicacion. > > 2008/4/20 Jose Mariano Alvarez <[EMAIL PROTECTED]>: > > > El uso del NOLOCK es una mala práctica en sistemas con abundante > > concurrencia. Solo se la debe usar bajo circunstancias muy controladas y las > > condiciones adecuadas. En la práctica cuando voy a una consultoría me > > encuentro muchas veces con sistemas plagados de lecturas sucias por culpa > > del NOLOCK. Esto suele ocurrir para salvar problemas debidos sobre todo a > > inadecuados diseños de bases de datos (tanto físicos como lógicos) y a no > > adecuarse a las formas en que trabaja el SQL Server hasta la versión 2000. > > > > Habitualmente se pueden producir demoras por bloqueo de recursos y en > > ocasiones aparecer deadlocks, entonces, se prefiere correr el riesgo de > > obtener inconsistencias que arreglar los problemas de cuajo, que en ese > > punto suelen ser difíciles o a veces casi insalvables. > > > > En fin si NO se espera que se presenten algunos de los *fenómenos* que > > describo más abajo y que define el ANSI es verdad que se podría usar NOLOCK > > sin problemas pero lamentablemente no se lo usa bien. > > > > En cuanto al SQL Server 2005 la cosa cambia rotundamente con la > > aparición del nivel de aislamiento SNAPSHOT que es similar al funcionamiento > > de ORACLE y evita algunos de estos problemas de cara al desarrollador. > > > > > > > > *Un poco de info para entender.* > > > > En bases de datos se denomina ACID o Atomicity, Consistency, Isolation > > y Durability (Atomicidad, Consistencia, Aislamiento y Durabilidad) a la > > propiedad de una base de datos para realizar transacciones seguras. > > > > · Atomicidad: es la propiedad que asegura que la operación se > > ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar > > a medias, o sea, se hace todo o no se hace nada. > > > > · Consistencia: es la propiedad que asegura que sólo se empieza > > aquello que se puede terminar. Por lo tanto se ejecutan aquellas operaciones > > que no van a romper la reglas de integridad de la base de datos. > > > > · Aislamiento: es la propiedad que asegura que una operación no > > puede afectar a otras. Esto asegura que la realización de dos transacciones > > sobre la misma información nunca generará ningún tipo de error. > > > > · Durabilidad: es la propiedad que asegura que una vez > > realizada la operación, ésta persistirá y no se podrá deshacer aunque falle > > el sistema. > > > > > > > > En ANSI 92 se definen tres fenómenos que pueden producirse cuando existe > > concurrencia > > > > *Lectura sucia* > > > > Esto ocurre si en una transacción se pueden ver los resultados de las > > acciones de otras transacción antes de que confirme las modificaciones. > > > > Transaction 1 > > > > Write(a) > > > > > > > > Rollback > > > > Transaction 2 > > > > > > > > Read(a) > > > > > > > > Si la transacción 2 lee los valores escritos por la transacción 1, > > entonces lo que ocurre es una lectura sucia. Es sucia porque T1 puede > > decidir más adelante hacer un rollback de la transacción lo que nos lleva a > > la situación en que T2 *trabaja con datos que se deben considerar que > > aun no existen*. > > > > > > > > *Lecturas no repetibles. * > > > > Esto ocurre si los resultados de una transacción pueden ser modificados > > o eliminados por otra transacción antes de que termine.. > > > > Transaction 1 > > > > Read(a) > > > > > > > > > > > > Read(a) > > > > Transaction 2 > > > > > > > > Write/Delete(a) > > > > Commit > > > > > > > > Si la transacción 1 obtiene resultados diferentes en cada cuna de las > > lecturas, entonces ha ocurrido una lectura no repetible. T1 lee datos > > que más adelante T2 cambia y hace un commit. Si T1 lee los mismos datos otra > > vez (después de que T2 hace el commit) encuentra que se han cambiado o > > eliminado (según lo que haga T2). Esto se llama lecturas no repetibles > > porque la misma SELECT *no devuelve los mismos datos dentro de la misma > > transacción*. > > > > > > > > *Lecturas fantasma. * > > > > Esto ocurre si los resultados de una consulta dentro de una transacción > > pueden ser cambiados por otra transacción antes de que termine. > > > > Transaction 1 > > > > Select(criterio) > > > > > > > > > > > > Select(criterio) > > > > Transaction 2 > > > > > > > > Update/Create(Coincide criterio) > > > > Commit > > > > > > > > Si la transacción 1 obtiene un resultado diferente dentro de cada > > consulta, entonces una lectura fantasma ha ocurrido. S1 lee datos con > > una condición WHERE específica. Después S2 inserta ciertos datos que cumplen > > la condición WHERE de S1 y hace el commit. Cuando S1 devuelve el resultado > > *encuentra nuevos registros dentro de la misma transaccion*. Es un caso > > especial de lecturas no repetibles. > > > > > > > > Los niveles de aislamiento del ANSI SQL 92 son cuatro. > > > > · read uncommitted > > > > · read commited > > > > · repeatable read > > > > · serializable > > > > Según SQL 92, una transacción está siempre en exactamente una de estos > > niveles del aislamiento y no pueden cambiar dentro de una transacción. Estos > > niveles del aislamiento definen que leen fenómenos se pueden esperar que > > ocurran > > > > solation Level > > > > Lecturas sucias > > > > Lecturas no repetibles > > > > Lecturas fantasma > > > > Read Uncommitted > > > > SI > > > > SI > > > > SI > > > > Read Committed > > > > NO > > > > SI > > > > SI > > > > Repeatable Read > > > > NO > > > > NO > > > > SI > > > > Serializable > > > > NO > > > > NO > > > > NO > > > > > > > > Espero les sirva. > > > > > > > > -- > > -------------------------------- > > Atte. > > Ing. Jose Mariano Alvarez > > SQL Total Consulting > > > > > > > > 2008/4/20 Esteban Grinberg <[EMAIL PROTECTED]>: > > > > Optimizar consultas es dificil, no hay una forma de hacerlo univoca y > > > todo depende del modelo, de los datos, de la concurrencia y de como esten > > > hechas las cosas. > > > Te cuento yo lo que hago cuanto tengo querys complejas y poco > > > performantes: > > > > > > 1) Generalmente si la consulta es complicada, hay varias maneras de > > > hacer lo mismo. > > > Algunas opciones por ahi implican tener que usar tablas temporales o > > > variables de tabla. > > > Hay que tratar de evitarlas, pero en algunos casos, pueden mejorar la > > > performance. > > > Lo importante es probar todas las alternativas y ver cual es la mas > > > rapida. > > > > > > 2) Ver el plan de ejecucion de la query y buscar donde hay lios. > > > Revisar que no haya tables scan (y de haberlos, que sean de tablas > > > chicas). > > > Revisar que se esten usando los indices y de forma correcta. Si vez un > > > Index > > > Scan tambien a hay que ver ahi que esta pasando. > > > > > > 3) Hay ciertos tips en una query donde uno ya sabe que puede haber > > > lios. > > > Por ejemplo, si en el WHERE usamos OR con campos indexados, o se usan > > > funciones tambien con campos indexados. El uso del IN muchas veces se > > > puede > > > reemplazar por el EXISTS, generalmente mas performante. > > > El poner un SELECT *, tampoco es lo mejor. > > > Subquerys del estilo SELECT A, (SELECT B FROM TABLE) FROM TABLE2, > > > tampoco suele ser la mejor opcion. > > > > > > 4) Agregar indices a la tabla o a la vista en caso de ser necesario. > > > Pero tener cuidado en donde se agregan los indices y a que campos. No hay > > > que hacerlo alegremente. > > > No vaya a ser que ganamos velocidad en la consulta, pero la perdemos > > > en el insert y update y tengamos problemas ahi. > > > > > > 5) En lo posible, revisar el modelo de la base para ver si no hay una > > > mejor opcion. > > > Tambien en determinados lugares, desnormalizar el modelo, en pos de > > > ganar eficiencia es una buena practica. > > > > > > 6) El uso del NOLOCK no es una mala practica, *SIEMPRE Y CUANDO* no > > > nos interese la integridad de los datos a mostrar. O sea, si vamos a > > > mostrar > > > un reporte financiero donde hasta el ultimo decimal es importante, > > > definitivamente el NOLOCK no va. > > > Ahora, si vamos a mostrar en una pagina web datos no tan criticos, ahi > > > podriamos evaluar si resignamos confiabilidad en los datos en pos de ganar > > > performance. > > > > > > 7) Tambien si la query andaba bien y de "repente" empezo a funcionar > > > mal, podrias ver si los indices no estan fragmentados, si las estadisticas > > > estan actualizadas y ese tipo de tareas que un DBA tendria que ocuparse. > > > > > > 2008/4/19 Jose Mariano Alvarez <[EMAIL PROTECTED]>: > > > > > > > El usar el NOLOCK no es recomendable ya uqe puedes tener multiples > > > > problemas (lecturas no confirmadas, fantasmas, etc) si hay accesos > > > > concurrentes. > > > > > > > > Saludos > > > > > > > > -- > > > > -------------------------------- > > > > Atte. > > > > Ing. Jose Mariano Alvarez > > > > SQL Total Consulting > > > > > > > > > > > > > > > > > > > > 2008/4/18 Damián Herrera <[EMAIL PROTECTED]>: > > > > > > > > > Hola Clarisa, > > > > > > > > > > Es complejo el tema. En mi experiencia, para poder hacer que una > > > > > consulta tenga mejor rendimiento tenes que utilizar todo el know-how > > > > > que > > > > > tengas, no hay una receta. Desde ver si los SELECT internos son > > > > > necesarios y > > > > > ver si podes unir varios en uno solo, utilizar índices, evaluar el > > > > > uso de > > > > > With(NoLock), evaluar uso de cláusula IN, operadores de comparación, > > > > > planes > > > > > de ejecución y demás. En resumen y pocas palabras, para hacer mejor > > > > > un query > > > > > tenes que tener mayor conocimiento de la plataforma que quien lo hizo > > > > > :) > > > > > Alentador no? > > > > > > > > > > > > > > > Espero haberte ayudado! > > > > > Saludos, > > > > > Damián Herrera > > > > > > > > > > > > > > > ------------------------------ > > > > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Clarisa > > > > > Savio > > > > > *Enviado el:* Viernes, 18 de Abril de 2008 06:23 p.m. > > > > > *Para:* [EMAIL PROTECTED] > > > > > *Asunto:* [dbms] select anidados > > > > > > > > > > el tema es que tengo un sp que ejecuta algo como > > > > > > > > > > select blabla from vw_repote where blabla > > > > > > > > > > este vw_repotes tiene la consulta del tipo: > > > > > > > > > > select campo1, campo2 ..., campo3 * (select campo5 > > > > > from VistaDeUnaTablaEnOtraBbase where algo ) from ( Select campo8 , > > > > > COUNT(campo9) from OtraVistaMas ) > > > > > > > > > > > > > > > es complejo el asunto asi que orientame mas o menos que puntos > > > > > deberia leer de help de sql y con eso me arreglo, :) > > > > > > > > > > Muchas Gracias!! > > > > > Salduos > > > > > Clarisa > > > > > > > > > > > > > > > 2008/4/18, Jose Mariano Alvarez <[EMAIL PROTECTED]>: > > > > > > > > > > > No hay una respeusta clara ni unica para eso. > > > > > > Por favor envianos la query y el diseño de tablas si puedes. > > > > > > En 2005 estan los CTE para simplificar la escritura de las > > > > > > consultas. > > > > > > Sin embargo no creo que mejore tu consulta. > > > > > > Podes crear una vista indexada quiza. > > > > > > > > > > > > -- > > > > > > -------------------------------- > > > > > > Atte. > > > > > > Ing. Jose Mariano Alvarez > > > > > > SQL Total Consulting > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/18 Clarisa Savio <[EMAIL PROTECTED]>: > > > > > > > > > > > > > Buenas!!! > > > > > > > > > > > > > > alguien sabe de que forma puedo reemplazar el uso de select > > > > > > > anidados para poder optimizar una consulta sql? > > > > > > > o al menos un dato de que deberia leer, estoy con sql 2005 con > > > > > > > compatibilidad para 2000. > > > > > > > > > > > > > > Muchas Gracias!! > > > > > > > Saludos > > > > > > > Clarisa > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
