Hola Daniel, te cuento que yo no tengo un esquema de 24hs pero si tengo picos muy altos de actualizaciones en la base de datos en días claves del mes con mas de 300 usuarios y a todo esto hacemos auditorias con triggers y si bien no es una cosa de locos pero se los banca sin problemas.
Como otra alternativa te puedo comentar que aquí usamos una herramienta BrightStor High Availability, con esto replicamos el Server completo (Base de datos y SO) y ni se entera el server de que está replicado, pero no se si te serviría como auditorias porque al cambiar un registro en el Server1 también se cambia en el Server2 y ya perdiste el dato original :-( ____________________________________________________________________________ ________________________ AS. Diego Vega DBA - <blocked::http://www.caruso.com.ar/> Caruso Cía Argentina de Seguros S.A <blocked::http://www.vates.com/> Vates Ing. de Software CMMI 4 Córdoba - Argentina dvega[arroba]vates.com dvega[arroba]caruso.com.ar _____ De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Daniel Maina Enviado el: Martes, 20 de Febrero de 2007 05:23 p.m. Para: Diego Vega Asunto: [dbms] RE: [dbms] Re: RE: [dbms] Re: Histórico de Cambios Bueno, mi problema es que las tablas críticas son muy consultadas y actualizadas simultáneamente durante gran parte del día por unos 130 usuarios aprox., por lo que los tiempos de bloqueos deben ser lo más corto posible. Al utilizar trigers la operación de tomar los datos de las tablas deleted /inserted y grabado en la tabla repositorio x así decirlo, que debo realizar sin dudas aumenta el tiempo de bloqueo dado que se realiza dentro de la misma transacción. Respecto a la alternativa 1: El esquema de replicación se basa en la marca y lectura del registro de transacciones del publicador por lo que entiendo que no me genera tiempos de bloqueos superiores. Lo que sí puede comprobar prácticamente es que la replicación con distribuidor en server separado no me generó problemas de performance (tengamos en cuenta que la empresa cuenta con muy buenos recursos en cuanto a servers y red). Tengo montado un esquema de replicación transaccional hace más de un año dónde inclusive se replican varias de las tablas más comprometidas y todo funciona muy bien. Pero es verdad que el mantenimiento no es sencillo, sobre todo cuando hay que hacer cambios en la estructura de las tablas publicadas; hay que tener cuidado con las instantáneas que generan bloqueos compartidos en las tablas publicadas al momento de crearse, etc.. Pero bueno, esta administración ya la conocemos . Por estos motivos es que estoy ensayando con esta tecnología Respecto a la alternativa 2: realmente es una idea media loca que aún no tengo desarrollada y la exprese más que nada para escuchar opiniones. Ahora, es verdad que las trazas sobrecargan el procesador y pensando mientras escribo si hay que auditar y no queremos perder nada .la sobrecarga será mayor ¡!... aún falta armar la herramienta que nos permita analizar los datos Respecto a la alternativa 3: gracias x la info ¡!! ,,creo que no voy a perder tiempo tratando de desarrollar la alternativa 2 .. jaja!!!! además no pinta sencilla ¡!! Bueno, en este caso habría que hacer un análisis costo-beneficio entre lo que es la compra, capacitación e implementación de un producto y el desarrollo de algo basado en la alternativa 2 .. no??? No obstante Maxi, no desesperes voy a incorporar un nuevo ensayo: poner los trigers a un par de estas tablas complicadas y medir ;) Otra vez, muchísimas gracias PD/ y ahora entre nosotros a mi me parece o el SQL 05 le pegó una paliza más o menos a más de una herramienta de 3ro?? Ing. Daniel A. Maina Dpto. Sistemas Jerarquicos Salud _____ De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Maxi Accotto Enviado el: Martes, 20 de Febrero de 2007 11:30 Para: Daniel Maina Asunto: [dbms] Re: RE: [dbms] Re: Histórico de Cambios Hola Daniel, mi experiencia me dice que cualquiera de esos 3 metodos no son nada eficientes, y entro a detallarlos: 1) Se sobrecarga mucho al procesador y si esta en un server separado ademas a la red, tambien tiene otras implicancias con respecto al mantenimiento de esas bases de datos, cuando quieras hacer un cambio no es tan sencillo en 2000. 2) La traza tambien hace una sobrecarga de procesos y si ademas la usas con profiler y no como traza en si podes tener serios problemas de performance y lo mas critico aun seria que algunos datos no aparezcan, esto tambien influye en que luego buscar dentro de una traza no es tan simple. 3) La gente de idera hace lo mismo que haria una traza, con lo cual es igual al punto 2, solo que a mi en lo particular no me gusta poner productos de terceros ya que no sabes que compatibilidad tienen y que hacen realmente :( aunque la gente de idera tiene algunas cosas interesantes. Perdona que insista pero podrias comentar porque el uso de trigger para ti es el que mas impacta en la performance? es cierto que esta dentro de la misma transaccion pero mira que he puesto auditorias en varias bases y algunas gmuy grandes y no se ha visto un impacto grande ni mucho menos. El día 20/02/07, Daniel Maina <[EMAIL PROTECTED]> escribió: Gracias Maxi por tu opinión.- Coincido en todo lo que decís pero me parece que el uso de triggers es la alternativa que más impacta en la performance y como estaría dispuesto a resignar algo del 100% de seguridad estoy analizando algunas otras alternativas: 1) Estoy haciendo una experiencia con replicación: en este caso modifiqué los SP de update y delete para que inserten en las tablas replicadas pero bueno tiene toda su historia en cuanto al mantenimiento, que estoy viendo como optimizarlo. Además cuento un servidor independiente para distribución por lo que espero lograr bajo impacto en la performance. Ya tengo toda una infraestructura de replicación montada y funciona muy bien.- 2) Estoy pensando en armar otra experiencia basada en el uso de trazas.- 3) Por otro lado estoy por analizar un producto de una empresa llamada IDERA que entre otras tiene unas herramientas para auditoria Bueno, si tienen alguna otra idea o experiencia será bienvenida ¡! Desde ya muchas gracias.- Saludos a todos.- Ing. Daniel A. Maina Dpto. Sistemas Jerarquicos Salud _____ De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Maxi Accotto Enviado el: Lunes, 19 de Febrero de 2007 12:49 Para: Daniel Maina Asunto: [dbms] Re: Histórico de Cambios Hola, si queres auditar siempre va a impactar en la performance y si queres tener 100% de seguridad yo pondria un trigger, cualquier otra alternativa no va a cambiar el tema performance y no sera tan seguro El día 19/02/07, Daniel Maina < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > escribió: Hola a todos, Les consulto: alguien tiene algún paper o best practices de cómo hacer un control de cambios sobre los registros de varias tablas???, es decir, necesito armar un histórico de los registros de la/las tabla: quien insertó un registro, cuando y quien lo cambio, qué campos cambiaron del registro, cuando y quien lo borró.- La primera idea fue hacerlo a través de triggers (incluso hay un paper de Maxi) pero dado que su uso impacta en la performance prefiero evitarlos (performace me es un tema crítico).- Conocen alguna otra herramienta o metodología para hacerlo?? Ing. Daniel A. Maina Dpto. Sistemas Jerarquicos Salud AVISO LEGAL La información contenida en este mensaje, y en cualquier archivo asociado al mismo, es confidencial y está destinada exclusivamente a su destinatario. Si usted no lo es, y por error lo ha recibido, por favor reenvíelo a su emisor indicando tal situación y luego elimínelo. La distribución, reproducción o copia de lo arriba expresado está prohibida y corresponden a su autor. No debe interpretarse que pertenezcan o sean compartidas por Jerárquicos Salud, quien no se responsabiliza por errores u omisiones producidas, ni garantiza la certeza de lo transmitido por este medio debido a que puede ser objeto de interpretación, alteración, demora, contener virus u otras anomalías. -- ---------------------------------------------------- Microsoft MVP en SQL Server SQLTotalConsulting - Servicios & proyectos en SQLServer Orador Culminis - Microsoft Influencier www.sqlgurus.org <http://www.sqlgurus.org/> ------------------------------------------- AVISO LEGAL La información contenida en este mensaje, y en cualquier archivo asociado al mismo, es confidencial y está destinada exclusivamente a su destinatario. Si usted no lo es, y por error lo ha recibido, por favor reenvíelo a su emisor indicando tal situación y luego elimínelo. La distribución, reproducción o copia de lo arriba expresado está prohibida y corresponden a su autor. No debe interpretarse que pertenezcan o sean compartidas por Jerárquicos Salud, quien no se responsabiliza por errores u omisiones producidas, ni garantiza la certeza de lo transmitido por este medio debido a que puede ser objeto de interpretación, alteración, demora, contener virus u otras anomalías. -- ---------------------------------------------------- Microsoft MVP en SQL Server SQLTotalConsulting - Servicios & proyectos en SQLServer Orador Culminis - Microsoft Influencier www.sqlgurus.org ------------------------------------------- AVISO LEGAL La información contenida en este mensaje, y en cualquier archivo asociado al mismo, es confidencial y está destinada exclusivamente a su destinatario. Si usted no lo es, y por error lo ha recibido, por favor reenvíelo a su emisor indicando tal situación y luego elimínelo. La distribución, reproducción o copia de lo arriba expresado está prohibida y corresponden a su autor. No debe interpretarse que pertenezcan o sean compartidas por Jerárquicos Salud, quien no se responsabiliza por errores u omisiones producidas, ni garantiza la certeza de lo transmitido por este medio debido a que puede ser objeto de interpretación, alteración, demora, contener virus u otras anomalías.
