En SQL Server 2005 hay un nuevo "Isolation level" que se llama "SNAPSHOT".
La finalidad de este nivel de loqueo es que el usuario siempre lea una vista consistente de los datos (no dirty read) y a la vez no bloquear otros lectores o escritores accediendo a los mismos datos. Similarmente los escritores no loquean a los lectores.
En SQL Server 2000 ya está el isolation level "READ COMMITED" que no hace lecturas sucias, la única contra que tiene es que antes de leer hace un shared lock (lockeando a un posible escritor como un mecanismo de evitar posibles dirty reads).
De cualquier forma las aplicaciones Genexus/SQLServer (al menos hasta GeneXus 8.0 que es la versión con la que trabajo actualmente) usan en algunas sentencias el hint "NOLOCK" lo que es equivalente al isolation level "READ UNCOMMITTED" (que es sinónimo de dirty reads). Pese a los "dirty reads", este isolation level tiene una ventaja y es que no lockea nada.
Ahora con este nuevo isolation level se podría lograr lo mejor de 2 mundos: no dirty reads y loqueo cero.
viernes, julio 14, 2006
miércoles, junio 28, 2006
Separación usuario-esquema en SQL Server 2005
SQL Server al igual que los DBMS’s mas comunes en el mercado utiliza el concepto de esquema para definir un dominio de nombres únicos de objeto.
A modo de ejemplo, en una base SQL Server no es posible tener 2 tablas de nombre “cliente” dentro de un esquema de nombre “sueldos_desarrollo”. Pero si podría tener dentro de la misma base la tabla “cliente” en el esquema “sueldos_desarrollo” y la tabla “cliente” en el esquema “sueldos_testing”.
En SQL Server 2000 el usuario y el esquema están implícitamente relacionados. Al crear un usuario se crea automáticamente un esquema y un esquema no existe sin su usuario asociado.
Este diseño es simple pero tiene algunas desventajas:
- Limita la independencia que deberían tener los desarrolladores para trabajar libremente con los objetos de un esquema y los DBA’s para administrar la seguridad del usuario asociado
- El nombre del esquema puede resultar poco amigable y no refleja la realidad ya que este nombre coincide con el nombre del usuario asociado al esquema.
En SQL Server 2005 este diseño cambia, independizándose el usuario del esquema. Al crear un usuario no se crea un esquema asociado y los esquemas de una base de datos se crean sin asociarse a un usuario.
Este diseño tiene algunas ventajas sobre el anterior:
- Para eliminar un usuario ya no es necesario eliminar previamente todos los objetos del esquema asociado (pues simplemente no hay esquema asociado)
- Se puede renombrar un usuario sin tener que renombrar el esquema, lo cual podía implicar un cambio en las aplicaciones que accedían a tablas de dicho esquema
- Cuando se tenían varios usuarios en una base de datos, al tener cada uno su propio esquema se corría el riesgo de que un usuario creara tablas u otros objetos en su esquema para el caso en que lo deseable fuera concentrar todas las tablas en un único esquema
- El nombre de un esquema no tiene porque coincidir con el nombre de un usuario
Una necesidad que surge de este nuevo diseño es lo que en SQL Server 2005 se llama “esquema por defecto”. Esta propiedad del usuario se usa para determinar la tabla a la que el usuario quiere acceder para el caso en que se haga referencia a un objeto por su nombre sin incluir el esquema como parte del nombre. En el siguiente ejemplo se intenta explicar el funcionamiento de esta propiedad:
Supongamos que en una base se tiene el usuario “supervisor” que tiene como default_schema “sueldos_testing”. Al intentar acceder a la tabla “clientes”, SQL Server 2005 intenta primero ubicarla en el esquema “sueldos_testing”. Si la tabla no existe en ese esquema, SQL Server 2005 intenta como alternativa ubicar la tabla dentro del esquema “dbo”.
Si se estuviera en SQL Server 2000 primero se intentaría ubicar la tabla dentro del esquema “supervisor” (es decir el propio esquema del usuario “supervisor”) y sino se encontrara en este esquema se buscaría en el esquema “dbo”.
Un usuario siempre tiene un esquema por defecto que se indica en la cláusula DEFAULT_SCHEMA de la sentencia CREATE/ALTER USER. Sino se indica un DEFAULT_SCHEMA se asume “dbo” como esquema por defecto.
A modo de ejemplo, en una base SQL Server no es posible tener 2 tablas de nombre “cliente” dentro de un esquema de nombre “sueldos_desarrollo”. Pero si podría tener dentro de la misma base la tabla “cliente” en el esquema “sueldos_desarrollo” y la tabla “cliente” en el esquema “sueldos_testing”.
En SQL Server 2000 el usuario y el esquema están implícitamente relacionados. Al crear un usuario se crea automáticamente un esquema y un esquema no existe sin su usuario asociado.
Este diseño es simple pero tiene algunas desventajas:
- Limita la independencia que deberían tener los desarrolladores para trabajar libremente con los objetos de un esquema y los DBA’s para administrar la seguridad del usuario asociado
- El nombre del esquema puede resultar poco amigable y no refleja la realidad ya que este nombre coincide con el nombre del usuario asociado al esquema.
En SQL Server 2005 este diseño cambia, independizándose el usuario del esquema. Al crear un usuario no se crea un esquema asociado y los esquemas de una base de datos se crean sin asociarse a un usuario.
Este diseño tiene algunas ventajas sobre el anterior:
- Para eliminar un usuario ya no es necesario eliminar previamente todos los objetos del esquema asociado (pues simplemente no hay esquema asociado)
- Se puede renombrar un usuario sin tener que renombrar el esquema, lo cual podía implicar un cambio en las aplicaciones que accedían a tablas de dicho esquema
- Cuando se tenían varios usuarios en una base de datos, al tener cada uno su propio esquema se corría el riesgo de que un usuario creara tablas u otros objetos en su esquema para el caso en que lo deseable fuera concentrar todas las tablas en un único esquema
- El nombre de un esquema no tiene porque coincidir con el nombre de un usuario
Una necesidad que surge de este nuevo diseño es lo que en SQL Server 2005 se llama “esquema por defecto”. Esta propiedad del usuario se usa para determinar la tabla a la que el usuario quiere acceder para el caso en que se haga referencia a un objeto por su nombre sin incluir el esquema como parte del nombre. En el siguiente ejemplo se intenta explicar el funcionamiento de esta propiedad:
Supongamos que en una base se tiene el usuario “supervisor” que tiene como default_schema “sueldos_testing”. Al intentar acceder a la tabla “clientes”, SQL Server 2005 intenta primero ubicarla en el esquema “sueldos_testing”. Si la tabla no existe en ese esquema, SQL Server 2005 intenta como alternativa ubicar la tabla dentro del esquema “dbo”.
Si se estuviera en SQL Server 2000 primero se intentaría ubicar la tabla dentro del esquema “supervisor” (es decir el propio esquema del usuario “supervisor”) y sino se encontrara en este esquema se buscaría en el esquema “dbo”.
Un usuario siempre tiene un esquema por defecto que se indica en la cláusula DEFAULT_SCHEMA de la sentencia CREATE/ALTER USER. Sino se indica un DEFAULT_SCHEMA se asume “dbo” como esquema por defecto.
lunes, junio 12, 2006
Análisis de Riesgo en el módulo de cargas del GIA
Así como desde el año 2004 se manejan criterios de riesgo para las declaraciones aduaneras de importación, exportación y transito, desde el mes pasado se han empezado a cuantificar los riesgos de las declaraciones de carga marítimas, aéreas y terrestres en la aduana de Uruguay.
El modulo de riesgo permite a los usuarios aduaneros la definición dinámica de reglas por diferentes criterios y condiciones en un lenguaje sencillo y entendible por todos. También se manejan criterios de aleatoriedad y permite el manejo de diferentes valores de riesgo.
Por ejemplo, se pueden redactar reglas del tipo:
SI PRODUCTO='HARINA' Y VIA_TRANSPORTE='MARITIMA'
ENTONCES
VERIFICACION_FISICA 45%
VERIFICACION_DOCUMENTAL 30%
SIN_VERIFICACION 25%
La incorporación de esta metodología del manejo de riesgo para operaciones de cargas, trae mas agilidad al comercio por poder focalizar las verificaciones en las operaciones consideradas riesgosas y una correcta administración de los recursos.
El sistema esta desarrollado en Java/Oracle y se comunica con el sistema aduanero a través de Web Services.
El modulo de riesgo permite a los usuarios aduaneros la definición dinámica de reglas por diferentes criterios y condiciones en un lenguaje sencillo y entendible por todos. También se manejan criterios de aleatoriedad y permite el manejo de diferentes valores de riesgo.
Por ejemplo, se pueden redactar reglas del tipo:
SI PRODUCTO='HARINA' Y VIA_TRANSPORTE='MARITIMA'
ENTONCES
VERIFICACION_FISICA 45%
VERIFICACION_DOCUMENTAL 30%
SIN_VERIFICACION 25%
La incorporación de esta metodología del manejo de riesgo para operaciones de cargas, trae mas agilidad al comercio por poder focalizar las verificaciones en las operaciones consideradas riesgosas y una correcta administración de los recursos.
El sistema esta desarrollado en Java/Oracle y se comunica con el sistema aduanero a través de Web Services.
viernes, junio 09, 2006
Auditoria de TABLAS en el SIGE
En la próxima versión del SIGE (Sistemas Integrados de Gestión Empresarial) se agrega la funcionalidad de la realización de auditorias de tablas.
El cliente podrá elegir cuales son las tablas que quiere controlar, y de las mismas quedará un registro de que usuarios realizan en ellas, inserciones, modificaciones y borrado de datos.
Se registrará también la fecha y hora de la operación así como también desde que terminal fue realizada la operación.
Esta forma de auditoria, agrega seguridad y trazabilidad a los cambios que se realizan en la base de datos por medio de la aplicación, permitiendo un mayor control sobre la información de la empresa.
El cliente podrá elegir cuales son las tablas que quiere controlar, y de las mismas quedará un registro de que usuarios realizan en ellas, inserciones, modificaciones y borrado de datos.
Se registrará también la fecha y hora de la operación así como también desde que terminal fue realizada la operación.
Esta forma de auditoria, agrega seguridad y trazabilidad a los cambios que se realizan en la base de datos por medio de la aplicación, permitiendo un mayor control sobre la información de la empresa.
martes, noviembre 22, 2005
Como reportar problemas
En mi trabajo me toca muy seguido reportar problemas, pero también me toca recibir reportes realizados por otras personas. A veces no es fácil reproducir un problema, por eso es necesario contar con la mayor cantidad de información posible.
Cuando nos encontramos con un problema, lo primero que debemos hacer antes de reportarlo, es asegurarnos que efectivamente es un problema. Puede parecer algo trivial, pero hay algunas cosas que debemos preguntarnos:
Cuando nos encontramos con un problema, lo primero que debemos hacer antes de reportarlo, es asegurarnos que efectivamente es un problema. Puede parecer algo trivial, pero hay algunas cosas que debemos preguntarnos:
- ¿Estoy haciendo algo mal? Si es posible, tratar de leer la documentación correspondiente y ver si estoy haciendo las cosas de forma correcta. A veces pasa que estoy tratando de usar algo, pero en realidad no se bien como funciona.
- ¿Es un caso particular o es un problema genérico? Deberíamos probar si el problema se da solo en este caso, o si ocurre también en casos similares.
- ¿Pasa también en otros equipos, le ocurre a otros usuarios? Algunos problemas dependen de la configuración del PC y es importante saber si esto es así.
- Tratar de aislar el problema. Por lo general la persona que recibe el reporte tiene menos idea del caso particular que se está probando. Es conveniente tratar de aislar lo más posible el problema, para facilitarle la tarea a quien lo tiene que corregir.
- Explicar lo más claramente posible lo que se está haciendo. Si es un problema que involucra varios pasos, tratar de explicar en detalle, aunque parezca trivial, cada uno de ellos.
- Dar información de las pruebas que se hicieron, por ejemplo si se probó otro caso similar, si encontré documentación que dice que el funcionamiento debería ser otro, etc.
- Indicar con que datos estoy probando. Muchas veces los problemas pueden ser errores o inconsistencias en los datos, por lo que es información muy importante.
- Cualquier otra cosa que se nos ocurra que puede resultar útil (que no por aparecer en el último punto deja de ser importante): una foto de la pantalla, el nombre del programa, los parámetros de configuración del equipo que parezcan relevantes, la base de datos, etc.
Suscribirse a:
Entradas (Atom)