Professional Documents
Culture Documents
ALUMNOS:
PROFESOR:
MATERIA:
Bases de datos
Estadísticas de DB2
Si bien, dentro de una base de datos relacional, el componente principal son las
tablas, existen otros componentes importantes como lo son las vistas y los índices.
Todos estos objetos tienen un tamaño máximo para ser creados y manipulados.
Para comenzar, el máximo de objetos que pueden ser creados en DB2 es de 32767,
sin embargo, este dato es poco preciso y confiable, ya que en este momento no se
encuentra dentro de la documentación de DB2, fue obtenido de una respuesta
dentro de un foro de hace un año y medio.
Por otro lado, sí se tiene definido un número preciso de tablas y triggers máximo por
un solo archivo de base de datos, el cual es de 11767.
Uno de los datos más relevantes dentro de DB2 es el tamaño máximo de una tabla;
este es 128TB para tablas que no contengan LOB(Large objects).
Ahora bien, este tamaño depende de la acción que estemos realizando con SQL,
por ejemplo, al realizar un SELECT, únicamente es posible hacer referencia 255
tablas en la cláusula FROM.
El máximo número de columnas soportadas por una tabla o una vista es de 750,
esta restricción está dada por el soporte de SQL.
Procesamiento
Aislamiento
DB2 soporta cuatro niveles de aislamiento en las transacciones y estos son las
siguiente; están ordenadas desde la que no permite anomalias hasta la que las
permite completamente:
● Lectura repetible
Se bloquean las tablas de la transacción para que otras transacciones que
añaden valores a la tabla o los eliminan de la misma no puedan cambiar
condiciones WHERE. Esto impide todos los tipos de anomalías de base de
datos.
● Estabilidad de lectura
Este nivel indica que las filas que se leen retienen bloqueos para que otra
transacción no pueda cambiarlas si la transacción no ha finalizado. Esto no
permite las lecturas sucias y las lecturas no repetibles. Las lecturas fantasma
siguen siendo posibles.
● Estabilidad del cursor
Este nivel indica que los cambios efectuados dentro de una transacción no
son visibles fuera de ella hasta que se compromete la transacción. Esto
impide que las lecturas sucias sean posibles.
● Lectura no confirmada
Este nivel permite que las transacciones vean los cambios no comprometidos
en los datos. En este nivel son posibles todas las anomalías de base de
datos.
Ahora, los tipos de anomalías pueden ser: lecturas sucias, lecturas no repetibles y
lecturas fantasma. Las lecturas sucias son producidas una primera transacción
inserta una tupla, una segunda transacción lee la nueva tupla y la primera
transacción cancela la inserción de la tupla. Las lecturas no repetibles ocurren
cuando una primera transacción lee una tupla, una segunda transacción modifica la
misma tupla y la primera transacción vuelve a leer la tupla obteniendo los nuevo
valores de la tupla. Y por último las lecturas fantasma ocurren cuando una primera
transacción realiza un consulta con una cláusula where, una segunda transacción
hace una inserción que cumple con la misma cláusula where y la primer transacción
vuelve a hacer la misma consulta y obtiene la nueva tupla
Seguridad en DB2
DB2 utiliza identificadores para manejar el acceso a los datos. DB2 asigna id’s a
cada proceso e inicio de sesión que se solicitan, estos id’s son llamados ID de
autorización (IDA). Estos ID mantienen privilegios que es lo que les permite realizar
ciertas acciones y niega otras. Los privilegios son:
● Privilegios relacionados
Db2 define los conjuntos de privilegios relacionados, denominados
autorizaciones administrativas. Al otorgar una autorización administrativa a un
ID, se otorgan todos los privilegios asociados con ésta, en una sentencia.
● Privilegios de objeto
La propiedad de un objeto conlleva un conjunto de privilegios relacionados
sobre el objeto. Un ID puede ser el propietario de un objeto que crea o puede
crear un objeto que pertenecerá a otro ID. La creación y propiedad de los
objetos se controlan de forma separada.
● Privilegios de paquete y plan de aplicación
El privilegio para ejecutar un plan de aplicación o un paquete requiere
atención especial. La ejecución de un plan o un paquete ejerce
implícitamente todos los privilegios que el propietario del plan o paquete ha
necesitado para vincularlo. Por lo tanto, el otorgamiento del privilegio para
ejecutar puede proporcionar un conjunto detallado de privilegios y puede
eliminar la necesidad de otorgar otros privilegios por separado.
● Etiquetas de seguridad
La seguridad de varios niveles limita el acceso a un objeto o a una fila
basándose en la etiqueta de seguridad del objeto o fila y en la etiqueta de
seguridad del usuario.
● Roles
Un rol es una entidad de base de datos que agrupa uno o más privilegios. Un
rol sólo está disponible cuando el proceso se ejecuta en un contexto fiable.
Un contexto fiable es una entidad de base de datos basada en un ID de
autorización del sistema y en un conjunto de atributos de fiabilidad de
conexión. Puede crear y utilizar un contexto fiable para establecer una
conexión acreditada entre Db2 y una entidad externa como, por ejemplo, un
servidor de middleware.
Los usuarios se asocian a un rol en la definición de un contexto fiable. Un
contexto fiable puede tener un rol por omisión, roles específicos para
usuarios individuales o ningún rol.
Los privilegios son organizados en autorizaciones de manera jerárquica así cada
autorización tiene privilegios y los privilegias de las autorizaciones que están por
debajo. Se clasifican en autorizaciones del sistema, de base de datos y de
colección.
Otra forma en que podemos implementar seguridad en una base de datos en BD2
es mediante el uso de vistas. El uso de las vistas y la asignación de privilegios en
esta nos permiten tener control de los datos a los cuales puede tener acceso
además de que encapsula las sentencias SQL dentro de la base de datos. A esto se
le denomina control de acceso de nivel de campo o sensibilidad de nivel de campo.
Modulos Agregados.
El sistema de administración de bases de datos DB2 no cuenta con el soporte para 4GL.
Sin embargo, IBM maneja INFORMIX, el cuál permite el uso de 4GL.
COPY
La utilidad COPY crea hasta cuatro copias de imágenes de espacios de tablas,
índices y conjuntos de datos.
Los dos tipos de copias de imagen son los siguientes:
QUIESCE
La utilidad QUIESCE establece un único punto de coherencia, denominado punto de
inactividad , para uno o más conjuntos de páginas. Para establecer puntos de
recuperación regulares para la posterior recuperación en un momento dado, debe
ejecutar QUIESCE frecuentemente entre ejecuciones regulares de COPY.
MERGECOPY
La utilidad MERGECOPY fusiona las copias de imagen que produjo la utilidad
COPY o las copias en línea que produjeron las utilidades LOAD o REORG.
MERGECOPY puede combinar varias copias incrementales de un espacio de tabla
para hacer una copia incremental. También puede combinar copias incrementales
con una copia de imagen completa para hacer una nueva copia de imagen
completa.
BACKUP SYSTEM
La utilidad en línea BACKUP SYSTEM invoca z / OS® DFSMShsm (Versión 1,
versión 5 o superior). BACKUP SYSTEM copia los volúmenes en los que residen los
datos Db2 y la información de registro Db2 para un subsistema Db2 que no
comparte datos o un grupo para compartir datos Db2 .
RECOVER
La utilidad RECOVER recupera los datos al estado actual o a un punto anterior en el
tiempo mediante la restauración de una copia y, a continuación, mediante la
aplicación de registros.
REBUILD INDEX
La utilidad REBUILD INDEX reconstruye los índices de la tabla a la que hacen
referencia.
REPORT
La utilidad REPORT proporciona información que se necesita para recuperar un
espacio de tabla, un índice o un espacio de tabla y todos sus índices. También
puede usar la utilidad REPORT para obtener información de recuperación sobre el
catálogo.
RESTORE SYSTEM
La utilidad en línea RESTORE SYSTEM invoca z / OS DFSMShsm (versión 1,
versión 5 o superior). RESTORE SYSTEM utiliza datos que se copian con la utilidad
BACKUP SYSTEM.
Reporteador
No existe como tal un reporteador como en Oracle. Sin embargo podemos obtener
reportes de datos e informes históricos.
Para generar algunos datos históricos, las tablas de explicación deben existir bajo el
esquema del usuario que ejecuta la herramienta. Para crear las tablas de
explicación, vaya al directorio / sqllib / misc y ejecute lo siguiente:
db2 CONNECT TO SAMPLE
db2 –tvf EXPLAIN.DDL
Ejecute el script del generador de datos históricos, wlmhist.pl, para generar datos
históricos para las actividades que se capturan en las tablas del monitor de eventos
de actividades. El formato es el siguiente:
● A: Tablas golpeadas
● B: tablas no golpeadas
● C: Índices de éxito
● D: Índices no golpeados
● E: Peticionarios
Si el parámetro userId que especifica no es el mismo que el que se usó para
ejecutar el script wlmhist.pl cuando se creó la tabla wlmhist, debe especificar el
nombre de esquema correcto. Los parámetros fromTime y toTime deben
especificarse en formato de marca de hora (por ejemplo, 2007-06-06-17.00.00).
Para este ejercicio, genere informes para tablas de éxito y no índices de aciertos:
Referencias:
[1] Conceptos de Db2 IBM Knowledge center. [Online] Disponible:
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_11.0.0/intro/src/tpc/db2z
_db2concepts.html
[2] Limits in Db2 IBM Knowledge center. [Online] Disponible:
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_11.0.0/sqlref/src/tpc/db2
z_limits.html