Seguridad
Lo primero es evitar utilizar las contraseñas por defecto que son conocidas por todos, en ninguna Base de Datos se deberían usar las contraseñas que Oracle provee por defecto para SYS y SYSTEM, ni tampoco para los otros usuarios o esquemas de ejemplo o componentes. Ahora más que nunca la Seguridad en TI ha tomado mucha importancia y aunque una Base de Datos que no sea de Producción, alguien podría querer robar información importante o acceder a datos restringidos; mejor aún si habilitas la función “Password Verify Function” y te aseguras de tener contraseñas más complejas para los Usuarios que se conectan a la base de datos.
También se debe seguir la regla de la menor cantidad de privilegios otorgados, es decir darle solo lo estrictamente necesario a los usuarios y esquemas en la Base de Datos.
Así mismo, como es lógico no es buena práctica otorgar el Rol de DBA a usuarios ni tampoco al esquema dueño de la aplicación, de igual manera no es conveniente otorgar privilegios tipo “ANY” a usuarios o roles (por ejemplo “Select ANY Table”).
Escalabilidad
Asegúrate de no crear objetos de tu aplicación dentro de los esquemas SYS o SYSTEM o cualquiera de los esquemas del motor de Oracle, así mismo tampoco se deben crear tablas dentro de los Tablespaces default de Oracle, como por ejemplo SYSTEM o SYSAUX. Las tablas y objetos de la aplicación deben ser creados en sus respectivos esquemas y tablespaces, tanto por cuestión de orden, desempeño y administración como por seguridad.
Por ejemplo: no es buena práctica crear todos los objetos de diferentes esquemas dentro del tablespace de “Users”, en general es mejor la separación y el orden lógico (tanto a nivel de Tablespaces como a nivel de almacenamiento, sea dentro del ASM o bien en FileSystems).
Inclusive cuando se habilita la Auditoría dentro de la base de datos, es mejor práctica cambiar la configuración para que los datos vayan a un Tablespace dedicado y no al Tablespace de SYSAUX que es el pre-configurado por defecto.
Recuperabilidad
Tener la Base de Datos con el Modo Archive habilitado, es lo mejor para su recuperación hasta el último momento antes de un desastre o para una recuperación en un determinado punto en el tiempo y también para utilizar las funcionalidades de Flash Back, además si se desea implementar algún tipo de replicación también es necesario. Es importante recordar darle un mantenimiento a la ruta donde se vayan a enviar los “archive files” para evitar que se vaya a llenar.
La funcionalidad “Guaranteed Restore Point” (GRP – punto de restauración garantizado) es de gran ayuda como parte de la política de cambios en caso que se requiera deshacer un cambio y dar marcha atrás la base de datos hasta el momento en que se tomó el punto de restauración, por ejemplo antes de aplicar un Parche o realizar algún cambio significativo en las estructuras o un cambio masivo de datos, se puede tomar un GRP y luego de las pruebas borrarlo si no fue necesario dar marcha atrás con los cambios realizados.
Más información: https://docs.oracle.com/database/121/BRADV/flashdb.htm#BRADV71000
Respaldos
Utiliza RMAN para realizar los respaldos (“backups”), aunque las herramientas EXPDP/IMPDP suelen ser utilizadas para copiar datos de una base de datos a otra (especialmente cuando se trata de unas pocas tablas), no es recomendable basar la política de respaldos únicamente en simples “Exports” e “Imports”, lo apropiado es utilizar RMAN para tener respaldos, tanto Completos como Incrementales. Importante recordar que no se necesita ninguna Licencia extra para utilizar RMAN. Aunado a realizar los respaldos, está la importante tarea de verificar los mismos para una eventual restauración de la base de datos utilizándolos, RMAN provee utilidades para comprobar si la base de datos se puede recuperar de los respaldos existentes, es buena práctica ya sea utilizar “Validate” o bien realizar un “Restore” de vez en cuando en un Servidor de Pruebas.
Más información: https://docs.oracle.com/database/121/BRADV/toc.htm
CiberSeguridad
Mantén tu versión actualizada con los últimos Parches de Seguridad (“CPU/PSU: Oracle Critical Patch Updates / Oracle Patch Set Updates”), aunque muchas veces en Producción es difícil tener una ventana de Mantenimiento, Oracle recomienda planificar e implementar sus parches de Seguridad tan pronto como sea posible, los mismos son anunciados con mucha antelación y están listados en un calendario cuatrimestral, por lo cual planificar para cada 4 meses aplicar estos parches de seguridad es una tarea mandatoria. Es importante recordar que este tipo de parches no son un upgrade de versión y no van a afectar el desempeño actual de la base de datos, pero de todas formas, si se cuenta con un ambiente de desarrollo es mejor aplicarlos primero ahí a modo de prueba y práctica, para luego proceder con Producción.
Puedes consultar el calendario en: https://www.oracle.com/technetwork/topics/security/alerts-086861.html
Desempeño
Aún cuando se tiene la versión de Oracle Enterprise, a menos que tengas la Licencia para Diagnostic and Tuning Pack, no estás autorizado para hace uso del utilitario de ASH y AWR, por lo tanto una excelente alternativa es instalar el paquete Statspack, con el cual similar a AWR podemos ayudarnos al momento de realizar investigaciones del desempeño dentro de la base de datos, esta es un tarea de las más importantes para el DBA, sin embargo, los reportes que provee el Statspack son útiles para los desarrolladores también. Este utilitario no requiere de ninguna Licencia adicional (a diferencia de AWR) y puede ser ejecutado en cualquiera de las versiones de Oracle (tanto Standard Edition, como Enterprise).
Para referencia y descarga visita en el sitio de soporte de Oracle (conocido como Metalink): FAQ- Statspack Complete Reference (Doc ID 94224.1)
Monitoreo
Es necesario tener alguna opción de monitoreo que alerte al DBA o el encargado de la base de datos en caso de problemas, especialmente y como mínimo: espacio, errores y backups fallidos.
Monitorear el espacio tanto de los “tablespaces”, como de los “diskgroups” o “Filesystems” donde se alojen los datafiles, archive files, redo log files e inclusive las rutas donde se almacenan los archivos de diagnóstico y auditoría, es de suma importancia asegurarse que vamos a recibir algún tipo de alerta cuando estemos prontos a quedarnos sin espacio libre. La idea es anticipar y extender el espacio antes de que se llene a su 100%, además de poder agregar almacenamiento lógico y físico de forma planificada y así evitar mantenimientos de emergencia, esto es una de las grandes prioridades para el DBA y el System Admin.
Monitorear los errores que se registren en el archivo “Alert_<SID>.log”, muchas veces el diseño de algunos queries a la base de datos puede causar errores conocidos o también el comportamiento de la aplicación puede enfrentarse a algún tipo de falla documentada y registrar un error en el Alert.log de la base de datos. El monitoreo de esta bitácora es una tarea esencial para el DBA, muchos errores pueden requerir de cambios para ser resueltos o bien de implementación de parches en particular, de la misma manera algunos errores son mayormente informativos y no requieren de ninguna acción.
Monitorear si la ejecución de los Backups se está dando y si están terminando de manera exitosa; lo peor que puede pasar es que el día que se necesite un respaldo (“Backup”), este no esté disponible, es sumamente importante revisar el log de los Backups para confirmar que efectivamente está comportándose sin errores ni problemas. Incluso es recomendable como mínimo correr un Restore Validate de vez en cuando, aún mejor hacer un restore completo de vez en cuando en un ambiente de pruebas, para verificar que tenemos todo lo necesario en caso de un desastre.
Auditoría
Habilitar las opciones de Auditoría al menos para los cambios a nivel de estructuras y permisos (DDL/DCL), esto ya sucede por default a partir de la versión 12c y como parte de la nueva herramienta “Unified Audit” (así mismo con los intentos de conexión fallidos), la idea es saber quién realiza cualquier tipo de cambio a nivel de estructuras, en caso de que ocurra un cambio no autorizado, se puede indagar en las bitácoras de auditoría de la base de datos. Así mismo, para aquellas tablas que contienen datos personales, sensibles o de acceso restringido, es conveniente habilitar Auditorías sobre las operaciones de lectura, escritura, actualización y o borrados (DML).
Para mayor referencia: https://docs.oracle.com/database/121/DBSEG/auditing.htm#DBSEG1023
Novedades
En general es bueno informar tanto a los DBAs como los desarrolladores sobre los “New Features” (nuevas características o funcionalidades) para que contemplen hacer uso de los mismas en sus soluciones, tanto para mejorar y actualizar las existentes, como para las nuevas a ser desarrolladas.
Muchas nuevas características vienen a ayudarnos a resolver de mejor manera tareas cotidianas en TI en general, otras a mejorar el desempeño de la base de datos y otras a incrementar la seguridad en nuestros datos.
También hay utilidades existentes que son reemplazadas por otras más nuevas, aunque Oracle siempre mantiene lo antiguo por compatibilidad, es mejor práctica ir migrando hacia lo nuevo, por ejemplo el paquete para calendarizar tareas DBMS_JOB (vista DBA_JOBS), a partir de Oracle 10g ha sido reemplazado por el paquete DBMS_SCHEDULER (vista DBA_SCHEDULER_JOBS), si bien aún con la aparición de su nueva versión el uso de DBMS_JOB puede ser suficiente y perfectamente funcional, es recomendable especialmente a partir de Oracle 12c migrar todos los “Jobs” a DBMS_SCHEDULER.
En general es mejor ir migrando poco a poco cualquier utilidad a su versión más nueva (con su respectivo ciclo y tiempo de prueba por supuesto).
Licenciamiento
Finalmente y no menos importante, tener cuidado con las características (features) que utilizamos, Oracle provee una gran cantidad de herramientas extra, sobre todo para trabajar el desempeño de la base de datos (Tuning and Performance), así como para replicación, seguridad y otros, es importante revisar la documentación de Oracle para cerciorarse de que la funcionalidad que estemos utilizando esté debidamente licenciada dentro de la versión y opciones que hemos comprado. Es común que diferentes artículos de la internet nos apunten a utilizar ciertas soluciones, pero algunos no mencionan si requieren de una licencia extra.
Para referencia, visita: https://docs.oracle.com/cd/E55822_01/DBLIC/E49208-21.pdf