ORACLE DATABASE DEVELOPMENT
Diseño:
La clave para diseño: Performance, escalabilidad, extensibilidad, funciones externas, objetos, seguridad,
disponibilidad, compatibilidad futura, portabilidad, diagnosticable, entornos especiales (data wharehouse, online
ops [OLTP])
DB conection: es el camino de comunicación física entre un proceso de cliente y la instancia de la DB.
DB session: Entidad lógica en la instancia de DB que representa el estado de un usuario en la DB.
Connection pool: cache de conecciones a una DB usable por una aplicación. Al correr, la aplicación hace un
pedido de conexión, se le otorga, la usa, la devuelve. Si el pool es estático, contiene un nro fijo de conexiones.
Cuando se alcanza el límite, los pedidos se encolan o se tira un error. Si es dinámico, se crean mas conexiones.
Esto parece ideal pero a veces se producen tormentas o sobre-inscripciones.
Estrategia de login: Un problema de desarrollo es determinar cuando y como la aplicación se loguea para iniciar
transacciones. En un diseño por ejemplo se hace login, sql, logout. consume mucho y anda bien si son pocas
transacciones por segundo.
Session leak: Cuando un programa pierde conexión pero su sesión continúa activa: Esto puede ocurrir por errores
no manejados.
Lock leak es una consecuencia, tablas o filas lockeadas esperando una inter-vención para liberar, pero esta no
llega pq se perdió la conexión.
Logical corruption: se pierde consistencia por falta o exceso de commit/rollbacks.
Runtime Connection Load Balancing
Oracle RAC (Real App Cluster) es una opción de DB en donde una DB se aloja en multiples instancias en multiples
nodos. Este metodo de cluster en discos compartidos mejora la disponibilidad, todas las instancias tienen acceso a
la DB.
Todas las peticiones se balancean durante la conexion o runtime. balance durante conexion se distribuye bien las
sesiones en la sintancias RAC. Balance durante runtime, se agina las peticiones en una session ppol que mejor
cuadre.
Performance
Data model
Analizar requerimientos de datos, funcionalidad y crear el diagrama de flujo de los datos.
Crear el diseño lógico y físico de la DB.: El diseño lógico es una representación gráfica que modela la relación entre
los objetos de la DB, agrupando data items (columnas) y estas en tablas. Relaciones entre tablas llevan a primary
y foreign keys. Luego se nortmaliza el diseño sacando redundancias.
Para el diseño físico creamos scripts SQL con DDL para crear esquemas y definir los objetos de la base.
Luego implementamos en un ambiente de test, hacemos pruebas de banco y luego vamos a produccion.
Objetivos (metrics)
Determinar nro de usuarios, transacciones por segundo, tiempos de rrespuesta esperados, camntidad de registros
por table por unidad d etiempo. Con todo esto creamos las pruebas de banco.
Herramientas
DBMS_APPLICATION_INFO: Este paquete se usa para registrar los nombres de los modulos ejecutables y/o
transacciones de la DB. Los especialistas lo usaran para rastrear la performance y debugging.
Sql Trace Facility (SQL_TRACE): Rastreo de cada instrucción SQL y bloques PLSQL.
EXPLAIN PLAN: Cuando se corre una instrucción, el optimizador genera varios posibles planes de ejecución,
calculando su costo y utilizando el mas bajo. El costo esta basado en estadísticas sobre distribucion y
almacenamiento de tablas, indices, accesos, etc. El acceso se basa en tiempos de I/O, CPU y Memoria. Si usamos
antes de la ejecución se guardan en una tabla a la cual se puede consultar para ver cual elije el optimizador.
Monitoreo de performance
ADDM (Automatic DB Diagnostic Monitor), analiza data capturada en Automatic Workload Repository (AWR).
Determina problemas y siguere soluciones. Normalmente se toma una isntantanea de AWR cada 1 hora y se
guardan por 8 días. OEM cloud control, muestra los hallazgos en la homepage de la DB.
OEM cloud control: puedo monitorar la performance en real-time. Tambien veo alertas, sus métricas, respuestas,
etc.
SQL Tuning advisor: Acepta instrucciones SQL y devuelve recomendaciones
SQL Access Advisor: Recomienda los mas optimos caminos de acceso a los datos, recomendnado vistas, logs,
indices.
Memory Advisors: Proveen analisis gráficos del uso de memoria, son SGA Advisor, Shared pool advisor, PGA
advisor y Memory advisor.
Cache de resultados de cliente
Aplicaciones que usen Oracla DB y drivers basados en librerías OCI pueden usar cache para mejorar el tiempo de
respuesta de pedidos repetitivos.
Este cache permite guardar queries en memoria del cliente. Como consecuencia permite ahorrar tiempo de CPU.
Es transparente para aplicaciones y se mantiene consistente con la DB.
Fetch y execute se hacen localmente eliminando un viaje al server.
Cache maneja perfectamente la concurrencia, la multiplicidad de instrucciones, el refresh de los resultados y el
manejo de memoria.
Hay que tener en cuenta que si los queries son complejos y usan muchas variables, por cada set de variables se
crea un cache diferente.
Queries que tengan type complejo o use funciones plsql, no se cachean
Se establece a tres niveles según esta precedencia:
Query: Se habilita o no con un hint SQL
Table: Para habilitar o no, puedo agregar una table annotation, sin tener que cambiar la aplicacion. La columna
result_cache de *_tables tiene el estado del cache en cada tabla.
Session: Para habilitar o no, usamos un parámetro de la DB.
SQL Hints
RESULT_CACHE, NO_RESULT_CACHE se aplica a un query simple. Y tiene precedencia sobre anotaciones de tabla o
el parametro RESULT_CACHE_MODE del servidor.
Anotaciones de Tabla
Tiene precedencia sobre RESULT_CACHE_MODE pero no sobre SQL Hint. Se usa al crear o modificar tabla con la
cláusula RESULT_CACHE(MODE FORCE) para habilitar o RESULT_CACHE(MODE DEFAULT) para deshabilitar. Todas
las tablas de un query tienen que estar en el mismo modo para que funcione.
Parámetro de sesión
Este parámetro se setea en el init.ora o con los comandos Alter Session, Alter System
RESULT_CACHE_MODE(FORCE) para habilitar o RESULT_CACHE_MODE(MANUAL)
Parámetros de inicialización
COMPATIBLE: Para establecer con que version de DB debe ser compatible, mínimo 11.0.0.0 o 11.2.0.0 para
views.
CLIENT_RESULT_CACHE_SIZE: tamaño del cache para procesos OCI del cliente 0 (disabled) o 32kb a 2 GB. Se
puede cambiar en sqlnet.ora con OCI_RESULT_CACHE_MAX_SIZE.
Se deberia establecer para todos los nodos de un RAC o para ninguno.
Es un parámetro estático. Si se cambia el valor con Alter System, se debe incluir la cláusula SCOPE=SPFILE y
reiniciar la DB.
CLIENT_RESULT_CACHE_LAG: Máximo tiempo en ms que cache puede retrasarse para cambios en los
resultados. Default 3000.
Es un parámetro estático. Si se cambia el valor con Alter System, se debe incluir la cláusula SCOPE=SPFILE y
reiniciar la DB.
Parámetros de configuración de cliente
Esto es opcional, pero si se establecen, tiene precedencia sobre los parámetros de init.ora.
Se setean en oraaccess.xml, sqlnet.ora o ambos (con ese orden de precedencia).
OCI_RESULT_CACHE_MAX_SIZE (max_size) Maximo general
OCI_RESULT_CACHE_MAX_RSET_SIZE (max_rset_size) Máximo de cada set de resultados.
OCI_RESULT_CACHE_MAX_RSET_ROWS(max_rset_rows) Máximo pero en filas.
Estadísticas
La vista CLIENT_RESULT_CACHE_STAT$ tiene estadísticas de cache
hacemos SELECT * FROM V$MYSTAT / V$SQLAREA con y sin cache para ver los tiempos
Server Result Cache
Estos resultados se guardan en SGA. Comparten con el cliente cache parametros
RESULT_CACHE, RESULT_CACHE_*, DBMS_RESULT_CACHE (pkg),
[GV/V]$ RESULT_CACHE _*, CREATE/ALTER TABLE ann
Cache de instrucciones
En el servidor, permite el uso de cursores sin re-parse. Se puede usar con pool de conexión o pool de sesión
OCI cache auto-tuning
Optimiza las características de sesión de aplicaciones sin cambiar la app. Auto-tuning por ejemplo optimiza el valor
del cache size para que sea equilibrado. Esto se setea en el archivo oraaccess.xml.
Archivo de parametros de despliegue del Cliente
Desde 12c existe este archivo con parametros OCI oraaccess.xml
Query Change Notification
Continuous Query Notification (CQN) permite registrar queries en la DB y recibir notificacio-nes de cambios (DDL,
DML) en los objetos (OCN), o cambios en el set de resultados (QRCN)
Para crearlas, se puede usar interfase PLSQL: en este caso la natoficacion está en un stored procedure del
servidor; Se puede usar OCI, (client side callback), Java, etc.
Database Resident Connection Pool
Provee un pool de conexiones para web apps. No lo voy a describir ahora.
Diseño para performance
Usar bind variables es mejor que literales en bulk operations
Agregar instrumentación (trace files, debug code) a las apps
Set-based: Para grandes cantidades de datos hay dos tipos de procesamiento, Set-based e iterativos. Despues de
años de testeo, set-based es mejor que procesar set enormes.
Iterativos
Procesan fila a fila iterando un set: Transfiere el set a client app, se procesa, se devuelve el set procesado. Esto se
logra con 3 técnicas cuyo resultado es el mismo.
1.Fila a fila:El mas comun y el que usamos siempre. Creamos un cursor y lo procesamos con un loop. Anda bien
con sets chicos. Se ejecuta serialmente, no aprovecha las ventajas del procesamiento paralelo de Oracle en
equipos con multiples procesadores, o RACs
2.Arrays: Similar pero procesa un grupo de filas en cada iteracion. Es serial también. Por ejemplo el uso de bulk
collect, FORALL...
3.Paralelismo manual: Lo mismo que los anteriores pero puende multiples servidores actuar en el trabajo al mismo
tiempo. Se usa ORA_HASH para dividir la data entre los procesos paralelos.
La función admite 3 argumentos: expresion(columna),max_buckets (nro de baldes), seed_value(multiples
resultados de la misma data).
Procesamiento Set-based
Es una tecnica que procesa data set dentro de la DB. Permite a la DB determinar la manera mas eficiente. Evita los
viajes desde hasta servidor y reduce los commits. Tiene tantas ventajas de tiempo en grandes lotes de datos que
usar otra cosa es injustificable.
alter session enable parallel dml;
insert /*+ APPEND */ into stage1_scan_events d
select s.* from ext_scan_events s;
commit;
Con el hint APPEND, la DB no crea redo, undo. Pero hay problema para mantener los buffers cache, porque
requiere mucha lectura de bloques. entre sus desventajas es que si bien hacer un insert es simple, la amyoria de
tecnicas son desconocidas para los desarrolladores. Y la reescritura de los procesos es mucho mas larga que con
otras tecnicas.
Seguridad
Acceso de usuarios
Privilegio de usuario es el derecho del usuario a efectuar una acción. Una coleccion de privilegios es un rol.
Hay que aplicar el principio de least privilege: Darle al usuario solo lo que necesita. De ser porible a traves de un
rol. Podemos hacer que nuestra app asigne un rol automaticamente, a traves de secure app role, que es un rol
asociado a un PLSQL. El pl valida al usuario. si falla, no puede loguearse. si pasa, el sistema le da un rol que le
permita usar la app, permiso que se revoca al logout.
Podemos crear triggers de logins (p.e. AFTER LOGON ON DATABASE).
VPD: Oracle Virtual Private DB, para crear políticas de acceso a nivel columna y filas. Esencialmente, VPD agrega
un WHERE dinámico contgra la tabla o vista en cuestion
ODR: Oracla Data Redaction enmascara la data en producción, cuando el usuario la intenta acceder. Esto anda
bien en un sistema que la data cambia constantemente. Se usa basicamente para nro de documento, tarjetas, etc.
Full: Todo el dato está enmascarado. P.E. (213167236) se muestra como 0. Parcial (se muestra como ***236).
Random (cambia el nro en sí), Regular exp. (Usamos patrones o expresiones para enmascarar algun dato como
p.e. mail).
OLS: Oracle Label Security: Actgua a nivel fila asignandoles niveles de seguridad (HIGHLY SENSITIVE, SENSITIVE,
PUBLIC) y se da acceso a los usuarios segun corresponda.
ODV: Oracle DB Vault: Restringe acceso adm a la DB. Por default SYS con SYSDBA tiene acceso a toda la DB.
Derechos para funciones y procedimientos
Cuando creamos un proc/fcn puede correr con privilegios del definer/owner (yo) o invoker/current_user. Para ellos
usamos clausula AUTHID DEFINER|CURRENT_USER. Ahora si quien crea tiene menos privilegios que quien usa, el
usuario al usar el proc, pasa al proc sus privilegios, permitiendo que el creador del proc tenga mas privilegios
(temporalmente), asi que podemos elegir o no hacer GRANT INHERIT PRIVILEGES ON usr TO usr
Auditoría de usuario
Podemos crear políticas de auditoría para ciertas acciones en el DB. cuando la instalamos se decide una
auditoria unificada en la que toda auditoria queda en un solo trail, visible en [ V|GV]$UNIFIED_AUDIT_TRAIL, o
un mix de unificada + pre 12c, para compatibilidad con los registros de auditoria que son diferentes
antes de 12c.
Alta Disponibilidad
TAF: Transparent App Failover es una caracteristica client-side para OCI, JDBC,etc. que minimiza interrupciones por
problemas de conectividad. Permite que una app se conecte a una segunda instancia con identicas caracteristicas
y con rollback. Los comandos ALTER SESSION no son automaticos. Tambien se hace desde el lado del servidor.
Desde el cliente con el parametro FAILOVER_MODE en la conexion y en servidor con el pkg
DBMS_SERVICE.MODIFY_SERVICE. Cuanta con callbacks para notificar fallos.
Oracle Connection Manager in Traffic Director Mode
Esto permite configurar CMAN en mode TDM para servir a clientes conectados a distintos servicios DB. Esto a
partir de 18.
Fast Application Notification (FAN) and Fast Connection Failover (FCF)
FAN: Notifica a otros procesos acerca de configuracion , service status (eventos UP/DOWN). Tiene el poder de
terminar una transaccion si hay error de instancia o servidor. Se publican con Oracle Notification Service.
FCF: Despues de mucha configuración ONS, Restart configuration, Advanced queuing, podemos habilitar esto. Los
clientes recibiran eventos FAN y relocar conexiones a la DB luego de un failover. Lo mejor que se usa es ONS.
SQL para desarrolladores
Paso a paso de una instruccion DML
1. Crear o abrir cursor implicito o explicito.
2. Analizar la instruccion en busca de errores.
3. Determinar si es un query o no.
4. Si es query, describir los resultados (solo si se desconoce, p.e. query interactiva que se ingresa en el momento)
5. Si es query, definir locacion, tamaño y tipo de variables que recibirán cada valor (define variables)
6. Unir variables. Asignar valores a cada una de las variables. (binding variables)
7. Paralelizar la isntrucción; Es opcional, se asignan multiples procesos de servidor para acelerar el proceso.
8. Ejecutar la instrucción. Se lockean filas si es UPDATE o DELETE, no se lockea si es SELECT o INSERT
9. Si es query, traer las filas
10. Cerrar el cursor
Shared SQL area
Oracle detecta queries similares. El area usada para procesar la primera ocurrencia es compartida, para uso
subsecuente.
Agrupar operaciones en transacciones
Primero se decide por tema de integridad y lógica que instrucciones agrupar en transacciones. Por ejemplo una
trnaaferencia de $ entre cuentas, implica dos SQL una restando en la primer cuenta, otra sumando en la segunda.
Ambas deben fallar o ejecutarse como una unidad.
Para cada trnasacción se recomienda:
Si se puede usar un simple SQL, mejor. Sino, usar PLSQL, Sino usar Java, Sino C.
Establecer estandares asi SQL usa shared areas.
Juntar estadísticas para implementar un acercamiento basado en el costo, con DBMS_STATS y ANALYZE.
Antes de comenzar, invocar DBMS_APPLICATION_INFO para registrar los procedimientos para luego hacer Trace
Incluir funciones PL de usuario en las expresiones SQL
Manejo de Commit Redo Action
Cuando una transacción updatea DB, se genera una entrada Redo, que se almacena en Redo log, hasta que la
transacción se completa. Cuando se hace el commit, el proceso de escritura del log (LGWR), escribe los registros
Redo a disco, en general antes de devolver la llamada al cliente. Esto causa una latencia. Oracle permite cambiar
la manera del Commit
WAIT: Default. Asegura que el commit vuelve solo despues que redo log es persistente (grabado)
NOWAIT: Commit vuelve al cliente sin importar si los redo log se han completado
BATCH: los redo log se agrupan esegun transacciones concurrentes, haciendo group commit
IMMEDIATE: LGWR graba los redo log enseguida.
NOWAIT y BATCH tiene pequeños momentos de vulnerabilidad en los que Oracle puede hacer rollback y la app la
ve como buena.
Corte recuperable
Es una falla que corta la coneccion entre cliente (app) y servidor (DB). La app recibe un mensaje de error. La
transacción que corría cuando se produce el corte se llama la in-flight tx. Para recuperarse, la app debe determinar
el resultado de la in-flight tx para saber si se hizo commit o no.
Esto se hace con Transaction Guard y DBMS_APP_CONT.GET_LTXID_OUTCOME
Transaction guard: Herramienta que nos informa del resultado del in-flight tx.Se basa en un identificador lógico de
tx (LTXID) que identifica el ultimo in-flight en una sesion que falló. No usarlo en propia sesión o en sesión viva.
LTXID se graba en el COMMIT y se guarda por el tiempo especificado en RETENTION_TIMEOUT, default 24hs.
Después d eun error Oracle lo retiene para asegurarse que ninguna tx con ese id sea commiteada. Esto permite a
la app devolver el resultado al usuario. Si la tx hace rollback, el id está disponible para Oracle.
DBMS_APP_CONT.GET_LTXID_OUTCOME:
tiene estos parámetros: CLIENT_LTXID. )Debe obtenerse justo antes de usar el pkg. Ojo no mucho antes porque
puede darnos otro ID. Según la APP usamos getLTXID para JDBC, OCI_ATTR_GET para OCI, etc.= COMMITED y
USER_CALL_COMPLETED (bools). (Una tx no termina necesariamente con commit o rollback. a veces la tx devuelve
un resultado como un select, o cantidad de registros, variables out devueltas, etc.)
----------
Puedo usar SELECT FOR UPDATE para lockear una fila aun sin cambiarla, p.e. en triggers para mantener integridad
referencial (Cambiar un Parent puede violar la integridad).
Tambien nos asegura ser el unico programa que está cambiando filas en ese momento.
Pero si hago SELECT FOR UPDATE en un cursor, las filas pueden estar cambiando. En ese caso se lockean las filas
que no cambiaron y luego PL reinicia el cursor con las filas faltantes.
Si mi app no puede garntizar que no haya deadlocks (ORA-00060), poner una excepcion.
Normalmente SELECT FOR UPDATE espera hasta que la fila requerida pueda lockearse. Si no queremos esto, hay
que usar NOWAIT, WAIT 0, SKIP LOCKED
DBMS_LOCK: para usar Oracle Lock Mgm Services (user locks). Una app puede pedir un lockeo de modeo
especifico, darle un nombre unico reconocible en otros programa, cambiar el modeo de lockeo , y liberarlo. Tiene
todas las caracteristicas de un lockeo oracle. Hay que asegurarse de que sean liberados despues d eun commit en
un entorno distribuido, para evitar deadlocks.
Se usa si se necesitan acceso a un dispositivo, como una terminal, sincronizar apps, detectar locks y releases.
Se usan los scripts CATBLOCK.SQL y UTLLOCKT.SQL para obtener info de lockeos de la DB en espera
Tx serializables.
Normalmente Oracle permite tx concurrentes modificando los mismos datos. Los cambios de una tx son invisibles
a las otras hasta que el commit o rollback. sin embargo a veces puede necesitarse tx serializables. En este modo,
tx concurrentes pueden hacer cambios que podrian hacer si estuvieran corriendo en serie, es decir una a la vez. Si
una tx quiere cambiar datos que otra tx cambió luego de que comenzó la tx serializable, tira ORA 8177. Hay q
terminarla y tirala de nuevo.
Interacción tx y nivel de aislamiento
En SQL hay 3 niveles de interacción tx Dirty read(tx A lee cambios no commiteados d ela tx B) Unrepeatable read
(Tx A toma datos, Tx B los cambia y commitea, Tx A re-lee los datos y ve los cambios) Phantom read (Tx A hace un
query, Tb agrega filas y commit, Tx a, repite query y ve las nuevas filas)
El tipo de interaccion es determinada por el nivel de aislamiento:
DIRTY UNREP. PHAN. ORACLE
READ UNCOMMITED SI SI SI NO.
READ COMMITED NO SI SI Si, por defecto. Oracle ve data commiteada al
comienzo de un query
REPEATABLE READ NO NO SI Si, en SERIALIZABLE
SERIALIZABLE NO NO NO Si, en SERIALIZABLE
Nivel de aislamiento
Se cambia con ALTER SESSION. Si queremos solo para una tx, usamos ISOLATION LEVEL del comando SET
TRANSACTION. Si se elije SERIALIZABLE, hay que cambiar el parametro INITRANS (de la tabla, con ALTER TABLE) a
por lo menos 3.
Tx serializables e integridad referencial
Como Oracle no hace locks en lecturas, aun en modo serializable, tx que revisan consistencia, deben tener en
cuenta la posibilidad de que la data haya cambiado. Por ejemplo confirmar que existe registro padre antes de
insertar hijo.
Hay dos niveles de aislamiento, con alto grado de consistencia y concurrencia, READ COMMITED, SERIALIZABLE
Una operación (query o tx) es tx set consistent si todas sus lecturas devuelven data escrita por el mismo set de tx
commited.. Cuando no es asi, algunas de las lecturas reflejan los datos de un set de tx y otras lecturas, de otro set
de tx.
Tx con READ COMMITED, son tx set consistent, porque todas las filas que una query lee deben estar commited
antes de comenzar el query.
Tx con SERIALIZABLE, también lo son porque todas las instrucciones de la tx son sobre una imagen de la DB al
comienzo de la tx.
La elección depende de la necesidad, debe haber balance entre concurrencia (rendimiento) y consistencia.
Operation READ COMMITTED SERIALIZABLE
Dirty write Not Possible Not Possible
Dirty read Not Not Possible Not Possible
Unrepeatable read Possible Not Possible
Phantom read Possible Not Possible
Compliant with ANSI/ISO SQL 92 S S
Read snapshot time Statement Transaction
Transaction set consistency Statement level Transaction level
Row-level locking S S
Readers block writers N N
Writers block readers N N
Different-row writers block writers N N
Same-row writers block writers S S
Waits for blocking transaction S S
Subject to "cannot serialize access" error N S
Error after blocking TX terminates N N
Error after blocking TX commits N S
Instrucciones DDL bloqueantes y no bloqueantes
Cuando una sesión manda un DDL, la sesión espera que cualquier DML concurrente termine. Mientras en espera,
pueden haber otras DML. Si estamos en nobloqueante, las nuevas DML se ejecutan de inmediato. De lo contrario,
se ejecutan despues que termina la DDL en espera.
El parámetro DDL_LOCK_TIMEOUT afecta sólo bloqueantes que entonces puede tirar un ORA-00054 (objeto
ocupado y con nowait)
Transacciones autónomas
(AT) es comenzada por otra tx, la principal.Una AT permite suspender la principal hacer de todo y luego continuar
con la principal. Por ejemplo en una orden de compra, puedo querer guardar los datos del clientes no importa si
completa la compra o no. O guardar un registro de errores aun si la tx hace rollback.
AT corre dentro del alcance de una rutina autónoma, usando pragma AUTONOMOUS_TRANSACTION.
Cuando termina la AT se continúa con la principal (no alcanza con COMMIT o ROLLBACK).
AT son visibles por otras tx en commit o rollback. AT pueden llamar a otras AT.
Errores de almacenamiento
cuando una larga tx se interrumpe por un error de almacenamiento (espacio ORA 1653, límites ORA 1628, quotas
ORA 1536), la app puede suspender la instruccion, corregir el problema y seguir ( resumable storage
allocation)
La app no recibe un mensaje de error, por lo tanto hay que usar un trigger AFTER SUSPEND o el DBA
tiene que revisar frecuentemente instrucciones suspendidas.
El trigger AS puede ser autónomo y consultar el pkg DMBS_RESUMABLE para tener info. También están
estas vistas DBA_RESUMABLE, V$_SESSION_WAIT
Elegir el data type correcto
Este cuidado al crear columns incrementa la integridad actuando como una constrain y disminuye los
requerimientos de almacenaje.
Tampoco asignemos el máximo posible aun con varchar2, porque oracle calcula el maximo que
necesita de memoria para una query en base al tamaño posible del varchar2.
Este cuidado también incrementa la performance, porque se elije un mejor plan de ejecución.
Para chequear y manipular types, usamos el pkg DBMS_TYPES
el ADT SYS.ANYDATA de Oracle nos permite representar cualquier tipo de escalar
Acceso rápido a filas
El acceso mas rápido es a través de su dirección o rowid
Expresiones regulares
Especifican un patrón de búsqueda usando metacaracteres y literales. SQL soporta búsqueda por
patrones, eliminando trabajo en otros puntos o interpretes.
REGEXP_LIKE: busca patrones que pueden aparecer en un WHERE
REGEXP_COUNT: Cuantas veces aparece un patrón en una cadena.
REGEXP_INSTR: como la función INSTR
REGEXP_REPLACE: como la función REPLACE
REGEXP_SUBSTR: como INSTR pero en lugar de devolver la posición, devuelve la cadena.
Opciones 'i': case insensitive, 'c' case sensitive '.' equivale al chr(10), lo tiene en cuenta en la
búsqueda, 'm' multilinea, 'x' ignora espacios en blanco
POSIX operators
. Cualquier caracter, incluido salto de linea. PE: a.b trae abb,acb,adb, etc
+ Una o mas ocurrencias de la expresion que la precede. PE a+ trae a,aa, pero no ba ni ab
* Cero o mas ocurrencias de la expresion que la precede. PE: ab*c trae ac,abc,abbc pero
no abb, bbc
? Cero o 1 ocurrencia de la expresion que la precede. PE: ab?c trae ac,abc pero no abbc
ni adc
{m} M ocurrencias de la expresión que la precede. PE: a{3} trae aaa, pero no aa
{m,} Por lo menos M ocurrencias de la expresión que la precede. PE: a{3,} trae aaa,aaaa
pero no aa
{m,n} Entre m y n ocurrencias de la expresión que la precede. PE: a{3,5} trae aaa,aaaa pero
no aa
[char..] Cualquier char entre []. PE [abc] trae all,bill,cold pero no doll
[^char. Cualquier char que no esté entre []. PE [^abc]def trae xdef, pero no adef
]
ch1| Uno u otro
ch2
(expr) Trata expr como un todo, tiene que coincidir todo
\n N=1-9 Trae la instancia n de lo que precede, no trae si encuentra menos de n. PE: (abc|
def)xy\1 trae abcxyabc, defxydef pero no abcxydef o abcxy
