ver usuarios usuario rol privilegios otorgar objetos listar grants consultar asignar oracle database-design oracle11g schema-design

usuarios - privilegios de objetos oracle



Diseño de esquema Oracle: ¿Esquema separado con sobrecarga de E/S? (5)

Estamos diseñando un esquema de base de datos para un nuevo sistema basado en Oracle 11gR1. Hemos identificado un esquema principal que tendría cerca de 100 tablas, a las que se accederá desde la aplicación Java frontal.

Tenemos un requisito para auditar los valores que se cambiaron en cerca de 50 tablas, esto tiene que hacerse en cada fila.

Lo que significa que es posible que, para una sola fila en MYSYS.T1 haya 50 (o más o incluso menos, pero mínimo 1) filas en la tabla MYSYS_AUDIT.T1_AUD . Es posible que tengamos valores antiguos de cada entrada de columna y nuevos valores disponibles de T1 .

DBA hizo una observación, desaconsejando este método, porque dijo que un esquema separado significaba una E / S adicional para cada operación . Básicamente, el esquema AUDIT se usaría solo para analizar e ingresar valores (por lo tanto, SELECT e INSERT ).

¿Es cierto que "un esquema separado significa una E / S extra"? No pude encontrar la justificación.

Parece lógico para mí, ya que los datos de AUDITORIA no deben ser manipulados, por lo que un esquema separado.

Además, diseñamos un esquema separado para archivar algunas tablas de MYSYS . Desde MYSYS_ARC la tabla puede MYSYS_ARC en cintas o eliminarse después de un tiempo suficiente.

Pocas estadísticas:
Pocas tablas (cerca de 20, 30) en el esquema MYSYS podrían crecer a alrededor de 50 millones de filas.
Hemos pedido un espacio en disco total de 4 TB.
MYSYS_AUDIT posible que el esquema MYSYS_AUDIT tenga 10 veces más que MYSYS pero no los conservaremos más de 3 meses.
Un puñado de tablas en MYSYS tendrá las siguientes transacciones / minutos.

  • 100 INSERT en MYSYS significa el mismo número de insertos en tablas MYSYS_AUDIT .
  • 1000 UPDATE en tablas MYSYS significa el mismo número de inserciones en MYSYS_ADIT tablas MYSYS_ADIT .

Preguntas:
Teniendo en cuenta todo esto, ¿me pueden sugerir alguna mejora?

  1. ¿Esquema separado afecta disco E / S? (¿una E / S adicional para cada esquema?)
  2. Alguna sugerencia general?

Figura:

+-------------------+ +-------------------+ | MYSYS | | MYSYS_AUDIT | | | | | | 1. T1 | | 1. T1_AUD | | 2. T2 | | 2. T2_AUD | | 3. T3 |--------->| 3. T3_AUD | | 4. T4 |(SELECT, | 4. T4_AUD | | . | INSERT) | . | | . | | . | | . | | . | | 100. T100 | | 50. T50_AUD | +-------------------+ +-------------------+ | | | | |(INSERT) | | | * +-------------------+ | MYSYS_ARC | | | | 1. T1_ARC | | 2. T2_ARC | | 3. T3_ARC | | 4. T4_ARC | | . | | . | | . | | 100. T100_ARC | +-------------------+

Además de esto, tenemos dos esquemas más con solo derechos de solo lectura, pero principalmente son para fines ad hoc y no nos importa el rendimiento en ellos.

Sugerencias:
Hay un par de sugerencias. Estamos de acuerdo en lo siguiente.

  1. Esquema para separaciones lógicas.
  2. TRIGGER para insertar datos en tablas AUDIT.
  3. Los nombres de las tablas no tendrán el sufijo _AUD . :)
  4. Procedimiento para rellenar las tablas de esquema ARCHIVE .
  5. Particiones basadas en intervalos.

Estamos analizando ...

  1. Opción del administrador del espacio de trabajo.

La pregunta sigue abierta para obtener más sugerencias antes de aceptar la solución de APC o dpbradely.


Además de la respuesta de APC.

Podría echar un vistazo a Workspace Manager , podría ser mejor que los desencadenadores, ya que pueden fallar o estar deshabilitados, etc.


Además, si tiene el dinero, mire el retiro total de Oracle


Eche un vistazo a la partición de rango para los datos de auditoría. Es posible que desee enviar datos de auditoría a un almacenamiento menos costoso. Las particiones facilitan el envío, por ejemplo, un mes de datos, a otro servidor. O para eliminar registros de autorización anteriores a un mes.

http://www.orafaq.com/wiki/Interval_partitioning


Tener los objetos en un esquema separado no causará E / S extra; tal vez hubo un malentendido y lo que su DBA quiso decir es que la presencia de auditoría daría como resultado E / S extra, lo que por supuesto será cierto sin importar cómo lo implementas


Tener un esquema separado definitivamente es el camino a seguir. Aparte de cualquier otra cosa, significa que puede usar los mismos nombres de tabla: MYSYS.T1 y MYSYS_AUDIT.T1 , lo que es útil si tiene tablas con nombres largos (> 25 caracteres).

Pero la principal virtud del esquema separado es que las tablas de auditoría pueden protegerse contra la manipulación accidental o maliciosa.

El impacto de insertar filas de auditoría, e, g, desde un desencadenante, permanece independientemente de quién posee las tablas.

consejos generales de diseño de mesas

Es una buena idea dar a las tablas de auditoría la misma estructura que la tabla principal. Entonces, si tiene columnas de metadatos que necesita para la auditoría, como el número de revisión, inclúyalos en la tabla principal. Además, llene las tablas de auditoría con nuevos valores, no antiguos. Es decir, cuando se inserta un nuevo registro en MYSYS.T1 inserte un registro coincidente en MYSYS_AUDIT.T1 ; cuando un registro existente se actualiza en MYSYS.T1 inserte un nuevo registro en MYSYS_AUDIT.T1 . Es mucho más fácil validar e informar sobre las tablas de auditoría si sus registros más recientes son los mismos que los actuales en las tablas principales.

uso de desencadenantes

La auditoría no necesita ser complicada. Todo lo que necesitamos es una declaración de inserción en un before insert or update or delete trigger . Estos se pueden generar fácilmente desde la vista del diccionario de datos USER_TAB_COLUMNS.