07 noviembre 2018

Oracle Linux 7 Update 6, ya está aquí

Oracle anunció el pasado 18 de Octubre del 2018 la disponibilidad de la vista previa para desarrolladores de Oracle Linux 7 Update 6 como parte de nuestro objetivo continuo de hacer de Oracle Linux la distribución para el desarrollo.

La versión previa para "viciosos" (a.k.a. desarrolladores) de Oracle Linux 7 Update 6 incluye los siguientes paquetes de kernel:



    • kernel-uek-4.14.35-1818.2.1.el7uek.x86_64
    El Unbreakable Enterprise Kernel Release 5, que es el kernel predeterminado.


    • kernel-3.10.0-933.el7.x86_64

    El último kernel compatible con Red Hat (RHCK), antes de los tiempos oscuros antes del IBMperio.

    Para comenzar a usar Oracle Linux 7 Update 6 Developer Preview, puede simplemente realizar una instalación nueva utilizando las imágenes ISO disponibles para descargar desde Oracle Technology Network.

    O bien, puede realizar una actualización de una instalación existente de Oracle Linux 7 utilizando los canales de vista previa del desarrollador para Oracle Linux 7 Update 6 en el servidor Oracle Linux y la Red de Linux Unbreakable (ULN).

    # vi /etc/yum.repos.d/public-yum-ol7.repo
    
    [ol7_u6_developer]
    name=Oracle Linux $releasever Update 6 installation media copy ($basearch)
    baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/6/developer/$basearch/
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
    gpgcheck=1
    enabled=1
    
    [ol7_u6_developer_optional]
    name=Oracle Linux $releasever Update 6 optional packages ($basearch)
    baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/optional/developer/$basearch/
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
    gpgcheck=1
    enabled=1
    El servidor Oracle Linux yum se refleja dentro de Oracle Cloud Infrastructure para permitir descargas más rápidas. Sigue las instrucciones para configurar las réplicas del servidor Oracle Linux yum en Oracle Cloud Infrastructure.

    Sigue este enlace para más información sobre los paquetes  proporcionados por la utilidad yum.

    Modifica la configuración del canal yum y habilite los canales de vista previa para desarrolladores de Oracle Linux 7 Update 6. A continuación, realiza la actualización.

    # yum update
    Una vez completada la actualización, reinicie el sistema y tendrá ejecutada la versión preliminar de Oracle Linux 7 Update 6 Developer.

    # cat /etc/oracle-release
    Oracle Linux Server release 7.6
    Recuerda que esta versión se proporciona solo para fines de desarrollo y prueba y no está cubierta por el soporte de Oracle Linux y la gente de Oracle y cualquiera con dos dedos de frente, NO recomienda el uso de este tipo de versiones en producción, solo para "jugar".





    15 octubre 2018

    GDPR en el contexto de Oracle E-Business Suite

    El Reglamento general de protección de datos (GDPR) de la UE entró en vigencia el 25 de mayo de 2018. Este nuevo reglamento afecta a todas las organizaciones, agencias gubernamentales y empresas de todo el mundo que recopilan o utilizan datos personales vinculados a residentes de la UE.

    Un primer paso importante es determinar si la aplicación Oracle E-Business Suite está dentro del alcance de GDPR. Cualquier aplicación o base de datos que contenga información personal sobre ciudadanos o residentes de la UE está dentro del alcance de GDPR, incluidos, entre otros, clientes, empleados, trabajos de contingencia y proveedores. Las siguientes consultas SQL ayudarán a determinar si el entorno de Oracle E-Business Suite contiene datos de GDPR en el ámbito. Estas consultas no son definitivas, pero proporcionan, al menos, un punto de partida en el proceso de alcance del GDRP.

    Recursos Humanos: Solicitantes, trabajadores eventuales, empleados


    TCA: Clientes, Organizaciones, Personas, Grupos



    Proveedores

     

    12 octubre 2018

    Auditoría unificada en Oracle Database 12c


    Una de las principales funciones de un DBA es implementar seguridad en la base de datos. Aunque si bien hay muchos aspectos relacionados a la aplicación de la misma, no siempre todos son utilizados en todos las empresas. Pero a pesar de esto, puede que un DBA no tenga que llegar a implementar una solución de autenticación basada en Kerberos pero siempre va a tener la responsabilidad de saber que está pasando en su base de datos. Es decir, quien se está conectado, que sentencias se están ejecutando, etc,.... La auditoria ha sido desde hace años la manera de satisfacer esta necesidad. No solamente es fácil de implementar y administrar, sino que además cubre todos los aspectos necesarios que un DBA tiene que cuidar cuando se trata de proteger su base de datos.

    La política de auditoria unificada es como un grupo de opciones de auditoria con diferentes condiciones. Para habilitar la auditoria, primero debe crear una política con diferentes opciones de auditoria y luego debe habilitar o deshabilitar para todos o pocos usuarios, según los requisitos que tengamos. Todos los registros de auditoria se almacenarán en la tabla UNIFIED_AUDIT_TRAIL

    Por defecto, hay 7 políticas de auditoria que estarán presentes en una base de datos Oracle 12c.

    En versiones anteriores a 12c, el DBA tiene a su disposición 5 tipos diferentes de  auditoria. Estas son:

    Auditoria obligatoria: Este tipo de auditoria está siempre habilitada y monitoriza las operaciones que involucren el inicio o apagado de la base de datos. Además de estas acciones, en cualquier momento que alguien utilice los roles predefinidos del sistema SYSDBA, SYSASM o SYSOPER esa acción será auditada.

    Auditoria estándar: Este tipo de auditoria se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema, y actividades de red o multicapa. Este tipo de auditoria se define y controla completamente a nivel de base de datos.



    Auditoria basada en valores: La auditoria basada en valores fue introducida para poder capturar los valores reales que se cambian cada vez que algún tipo de sentencia DML es ejecutada en todas o determinadas filas de una tabla. Este tipo de auditoria aprovecha la funcionalidad de los triggers de base de datos (construcciones PL/SQL que responden a eventos) para lograr este objetivo.



    Auditoria de grano fino: La auditoria de grano fino se centra en una auditoria de nivel  mas granular y las acciones auditadas se capturan basándose en el contenido accedido o modificado. Se puede simplemente crear políticas para disparar eventos de auditoria cuando alguien trata de realizar acciones que responden a las condiciones especificadas en la definición de la política.



    Auditoria SYS: Este tipo de auditoria en realidad permite monitorizar las actividades de un administrador del sistema. Los usuarios que se conecten como SYS serán auditados y los registros de sus acciones serán escritos en un archivo de sistema operativo para evitar que sean borrados de la tabla AUD$ dentro de la base de datos. El parámetro de inicialización AUDIT_SYS_OPERATIONS se utiliza para activar y desactivar la auditoria de SYS.

    Auditoria mixta: por defecto está habilitada en 12c. Permite utilizar tanto la auditoria tradicional como los métodos de auditoria unificada. Es decir. Además de la auditoria tradicional, podemos usar todas las características de la auditoria unificada. Una vez que nos sentimos cómodos con el concepto unificado, podemos migrar la configuración de auditoria existente a una política unificada, podemos habilitar la auditoria pura.
    Esto sirve como un buen mediador para un cambio fácil y sin problemas a la auditoria Unificada preferida.

    Auditoria pura: una vez que se habilita la auditoria pura. No podemos utilizar los métodos de auditoria tradicionales.


    • Valor: FALSE  -> AUDITORIA MIXTA
    • Valor: TRUE   -> AUDITORIA PURA


    ¿Qué modo de auditoria unificado está habilitado para mi base de datos?


    ¿Cómo cambiar de una auditoria mixta a pura?



    Políticas por defecto en la base de datos Oracle 12c:



    Pero no todos están habilitados. Consulta AUDIT_UNIFIED_ENABLED_POLICIES para buscar, qué políticas están habilitadas.



    Consulta para comprobar las opciones de auditoria incluidas en una política:



    Incluso si no se crea una nueva política en la base de datos, la acción de auditoria de las opciones de auditoria anteriores se registrará en UNIFIED_AUDIT_TRAIL.

    Eliminamos la política de auditoria:



    Purgamos la pista de auditoria:



    07 octubre 2018

    Migrar de Oracle 11g a Oracle 12c: ¿Qué hacemos con la auditoria?



    Si estas pensando en migrar a Oracle Database 12c, sin importar el tipo de entorno implicado (desarrollo, prueba, certificación producción), una de las muchas decisiones que debes consolidar con tu equipo es definir qué hacer con la auditoria. La nueva característica más importante en esta área es la denominada Auditoría Unificada, que captura información de auditoria de diferentes fuentes, como por ejemplo registros de auditoria "normales" y FGA, contextos de aplicación, RMAN o DataPump más algunas otras y las almacena en un formato y lugar comunes. , que es de solo lectura, tabla particionada en el esquema AUDSYS, que reside de forma predeterminada en el tablespace SYSAUX y utiliza la función Oracle SecureFiles.

    Afortunadamente, Oracle nos dio flexibilidad en cuanto a las opciones de migración disponibles. Por ejemplo, en 12c todavía es posible utilizar la auditoría tradicional, de manera similar a como lo haciamos en la versión 11g. Incluso existe la posibilidad de realizar auditorias de modo mixto, en las que se completan las pistas de auditoria tradicionales y unificadas. Por supuesto, usar solo un enfoque unificado también es posible.

    Independientemente del modo que desees utilizar después de la migración, es una buena idea habilitar la auditoria unificada desde el principio, volviendo a vincular los binarios de la base de datos con el parámetro uniaud_on. Esto le permitirá evitar la no disponibilidad si decide realizar una auditoria unificada (o de modo mixto) en una etapa posterior. Utilice la siguiente consulta para encontrar si está correctamente habilitado:


    Todos los parámetros de inicialización de auditoria utilizados anteriormente:
    • audit_trail
    • audit_file_dest
    • audit_sys_operations
    • audit_syslog_level

    No tienen significado (en caso de usar solo auditoria unificada). Sin embargo, todavía están disponibles, ya que son necesarios para los modos tradicional y mixto.

    Teniendo en cuenta las migraciones, también debe decidir qué hacer con los registros de auditoria antiguos. Incluso cuando la auditoria tradicional está deshabilitada, todavía existe la posibilidad de archivar y luego purgar los registros de auditoria de las pistas de auditoria tradicionales utilizando el paquete dbms_audit_mgmt, por lo que podría hacerse antes, durante o después de la actualización.

    ¿Qué debería convencerlo de que la auditoria unificada es una mejora significativa en comparación con el enfoque tradicional?

    Probablemente la ventaja más importante está incorporada en la palabra "unificada": el hecho de que todos los registros de auditoria están disponibles a través de la vista unificada_audit_trail y en el caso de un entorno multitenant en la vista cdb_unified_audit_trail, que proporciona registros de auditoria de cada PDB (disponible solo en la raíz). Parece que Oracle ha analizado todas las opciones y características de auditoria disponibles en versiones anteriores y ha diseñado la auditoria unificada como más consistente, segura y más fácil de administrar. 
    A partir de 12c, podría olvidarse del manejo diferente de los registros ubicados en aud $, fga_log $ o archivos del sistema operativo. Aún así, cuando la base de datos no se puede escribir (por ejemplo, cerrada, montada, abierta de solo lectura), los registros de auditoría se colocarán en archivos del sistema operativo (ubicados en $ ORACLE_BASE / audit / $ ORACLE_SID, que desafortunadamente parece no ser modificable). Se debe hacer de esa manera: es crucial para auditar operaciones como la conexión como sysdba, pero, por supuesto, no puede persistir en una base de datos que no se pueda escribir. Afortunadamente, actualmente existe la posibilidad de cargar archivos de auditoria ubicados en este directorio en la base de datos utilizando el procedimiento dbms_audit_mgmt.load_unified_audit_files. Posteriormente, podrían manejarse como otros registros de auditoria, sin la necesidad de implementar analizadores dedicados, etc.

    Gestión de auditoria distinta, pero más sencilla

    Hablando de una gestión de auditoria más fácil, debemos recordar no solo el manejo de los registros de auditoria, sino también la configuración de lo que se debe auditar. Es muy diferente en comparación con 11g, ahora se define en las políticas de auditoria. Podría tener muchas de estas políticas definidas y habilitarlas / deshabilitarlas de forma independiente, pero tenga en cuenta que, según la documentación de Oracle, la cantidad de políticas de auditoria habilitadas al mismo tiempo en la base de datos debe ser limitada.

    Como puede encontrar en el archivo $ ORACLE_HOME / rdbms / admin / secconf.sql, hay 3 políticas de auditoría predeterminadas definidas para nuevas instalaciones de 12c: 
    • ora_account_mgmt
    • ora_database_parameter
    • ora_secureconfig.
    Solo el último está habilitado de forma predeterminada, pero es una buena idea borrar la configuración predeterminada y usarla como punto de partida para diseñar su propia política de auditoria. Al hacer eso, tenga en cuenta que hay una serie de actividades que se auditan obligatoriamente.

    La administración en términos de acceso a los datos de auditoria también se simplifica, gracias a la introducción de dos nuevos roles, con nombres autodescriptivos: audit_admin y audit_viewer.


    Desde el punto de vista de la seguridad, esta era una limitación bastante grande, que actualmente, como resultado del nuevo diseño  de la auditoria en la versión 12c de la base de datos, se ha eliminado.






    04 octubre 2018

    PL/SQL: Server Result cache otra herramienta más en nuestro cinturón


    Una característica desde Oracle 11g, el llamado Result Cache, es una herramienta poderosa que se puede usar para almacenar en la memoria resultados de consultas y funciones. La información almacenada en caché se almacena en un área dedicada dentro de la Shared Pool donde puede ser compartida por otros programas PL/SQL que realizan cálculos similares. Si los datos almacenados en este caché cambian, los valores que se almacenan en el caché pierden su validez. Esta función es útil para las bases de datos con sentencias que necesitan acceder a un gran número de filas y devolver solo algunas de ellas. Como puede ocurrir en tiendas online, bancos, etc, ...

    La caché de resultados se configura utilizando el parámetro de inicialización result_cache_mode con uno de estos tres valores:

    • auto: los resultados que deben almacenarse se resuelven mediante el optimizador de Oracle
    • manual: Almacene en caché los resultados indicando la declaración usando la sugerencia result_cache | no_result_cache
    • force: todos los resultados serán cacheados.

    El paquete dbms_result_cache se usa para proporcionar las opciones de administración de DBA de la memoria utilizada tanto por la caché de resultados de SQL como por la caché de resultados de la función PL / SQL. Estos son los procedimientos y funciones del paquete dbms_result_cache:


    A continuación se describe una descripción práctica de cómo utilizar estos procedimientos y funciones.

    Para este ejemplo, la result cache de SQL se muestra y se explica cómo limpiar la memoria caché de resultados y cómo utilizar las sugerencias para corregir los resultados de una consulta en la memoria caché de resultados. Primero, eche un vistazo a los parámetros de inicialización del caché de resultados. Todos están configurados en sus valores predeterminados; por lo tanto, es necesario usar la sugerencia result_cache para mantener los resultados de las consultas en la memoria, ya que el parámetro de inicialización result_cache_mode es manual.



    Ahora consulta las vistas de caché de resultados que proporcionan información como objetos en memoria, dependencias de relación y estadísticas de caché de resultados.


    Seguimos con la comprobación



    Ejecute la operación "flush" para eliminar todos los objetos de la memoria caché de resultados. Existe la opción de conservar o liberar la memoria y / o las estadísticas según sea necesario. Aquí se encuentran todas las posibilidades de vaciar el caché de resultados:


    Es muy fácil mantener los resultados de las consultas en la memoria, pero presta atención a la columna de invalidaciones de la tabla v $ result_cache_objects. Esta columna muestra cuándo los resultados asociados a un objeto en la memoria dejan de ser válidos debido a una modificación de los datos.

    El parámetro result_cache se usa para que los resultados devueltos por esta función se almacenen en la memoria caché hasta que se modifiquen los datos de la tabla de empleados, lo que invalidará los resultados almacenados en caché para esta función.



    03 octubre 2018

    Analizador jerárquico PL / SQL en Oracle Database 11g

    El paquete DBMS_HPROF proporciona una interfaz para perfilar la ejecución de aplicaciones PL / SQL. Proporciona servicios para recopilar los datos del perfilador jerárquico, analizar la salida del perfilador sin procesar y la generación de información de perfilado.

    El generador de perfiles jerárquico PL / SQL se introdujo en Oracle 11g Versión 1 para permitir a los desarrolladores reunir y analizar datos de perfiles jerárquicos para programas PL / SQL. El generador de perfiles jerárquico consiste en el paquete DBMS_HPROF, que se siente similar a los paquetes DBMS_PROFILER y DBMS_TRACE, y la utilidad de línea de comandos plshprof para convertir la información de perfil en formato HTML.

    DBMS_HPROF
    El paquete DBMS_HPROF está instalado de forma predeterminada, pero para usarlo debemos otorgar permiso de ejecución en el paquete y proporcionar un directorio para escribir la información del generador de perfiles sin formato.



    Ahora podemos usar el generador de perfiles del usuario de prueba, pero para analizar los resultados, necesitamos instalar las tablas de perfil jerárquico en el usuario de prueba ejecutando el script:
    "$ ORACLE_HOME / rdbms / admin / dbmshptab.sql".



    Este script crea tres tablas y una secuencia en el usuario de prueba.


    A continuación creamos algunos procedimientos ficticios para perfilar. El procedimiento haz_algo_1 llama al procedimiento haz_algo_2, que a su vez llama al procedimiento haz_algo_3.



    A continuación, iniciamos el perfilador jerárquico utilizando el procedimiento START_PROFILING, ejecutamos el procedimiento haz_algo_1 y detenemos el perfilador usando el procedimiento STOP_PROFILING.



    Con el perfil completo, podemos ejecutar la función ANALIZE para analizar los datos sin procesar y colocarlos en las tablas de perfiles jerárquicos.



    La salida nos muestra el RUNID de la ejecución de análisis. También podemos encontrar esto en la tabla DBMSHP_RUNS.



    Usamos el valor RUNID apropiado para consultar la tabla DBMSHP_FUNCTION_INFO



    Podemos combinar esto con la información de la tabla dbmshp_parent_child_info para mostrar la vista jerárquica de los datos. para el RUNID específico.




    En otra entrada de este blog, seguiremos con la función: plshprof

    30 septiembre 2018

    Proceso en PL/SQL para matar sesiones en Oracle 11g RAC


    Alguna que otra vez, en tu que hacer diario, necesitas eliminar una sesión en una instalación Oracle database 11g RAC y más tarde, recibes un mensaje en el  que no se puede cancelar la sesión debido a que la sesión está conectada a una instancia diferente. Te tienes que conectar a esa instancia y matarla

    Comenzando con 11g, el fabricante incluyó el nombre de instancia en el comando de alterar el sistema (3º parámetro o @instance_id). Por lo tanto, para matar la sesión de bloqueo en cualquier nodo desde cualquier nodo que ejecutaría:



    Si ejecutamos nuestro código tenemos la siguiente salida:

    Ya puedes matar sesiones en un servidorRAC por instancia de este.




    Otra cosa interesante que hacer con la "tabla" DUAL

    Esta entrada en el blog es pequeña a modo de receta, veremos una aplicación que se puede usar con dual, aparte de las consabidas y ya habituales. A veces es bastante útil tener una consulta que siempre regresa a un cierto número de filas, imagina que te piden un informe que devuelva una fila para cada día del mes. El uso de DUAL y CONNECT BY le permite devolver tantas filas como sea necesario.
    Por ejemplo, esta consulta devuelve una fila para cada día del mes.

    En la siguiente imagen podemos ver como construir esta sentencia y su resultado en SQL DEVELOPER:



    21 septiembre 2018

    Contención en las secuencias en entornos Oracle RAC

    Recientemente me encontré con un caso en el que seleccionar el siguiente valor de una secuencia causó problemas de contención en Oracle RAC. Mira esta captura de pantalla:

    Los eventos de espera tendrán el mismo aspecto si se muestran en las pantallas de rendimiento de Enterprise Manager, que sí requieren una licencia para el Paquete de diagnóstico opcional.
    Podemos ver altas esperas en el evento de espera de bloque de caché de fila, así como múltiples eventos de espera de caché global (todos comienzan con "gc").
    El problema fue que la secuencia se creó con CACHE establecido en cero. Las secuencias en Oracle RAC con una configuración de caché demasiado baja verán eventos de espera como este. La solución es simple, aumente el tamaño de CACHE.



    09 julio 2018

    Cómo corregir las tablas fragmentadas de una base de datos Oracle 11g


    ¿Qué es la fragmentación de datos?

    Si a una tabla únicamente se somete a inserciones, no habrá ninguna fragmentación. La fragmentación viene solo cuando hacemos borrados/actualizaciones a la tabla.
    El espacio que se libera durante las operaciones “no-inserts” no son usadas inmediatamente (algunas veces jamás se usaran). Esto deja huecos en la tabla que resultan en fragmentación.
    la fragmentación de las tablas es diferente a la fragmentación de archivos, cuando se realizan muchas operaciones DML (Data manipulation language) en una tabla, la tabla se fragmenta, debido a que las DML no liberan el espacio de la tabla debajo de la High Water Mark ( HWM=  es la última parte de una tabla que le indica al cursor que hasta allí llego la tabla y contiene la cantidad de registros)
    Cada vez que la información crece, elimina el bloque donde está el HWM y recreando otro HWM cuando termina de incrementar el espacio, estos bloques donde estaban los HWM’s no ocupan casi nada de espacio, pero después de muchísimo uso y mucho tiempo ya pueden ser significativos en el tiempo de lectura.

    ¿Cuáles son las razones de reorganizar la tabla?


    ·         bajo tiempo de respuesta (de esa tabla en especial)
    ·         Alto número de campos encadenados (o migrados)
    ·         La tabla ha crecido muchos bloques y el espacio antiguo no ha sido reutilizado

    Nota: Los consultas basados en índices no se beneficiaran mucho por la reorganización comparado con las consultas que hacen un “full table scan”
     ¿Cómo encontrar la fragmentación de las tablas?
    En los esquemas de Oracle en donde se encuentran una gran diferencia entre el tamaño actual (se encuentra en la vista user_segments) y el tamaño esperado de user_tables (Num_rows*avg_row_length (in bytes)). Toda esta diferencia se debe a la fragmentación de la tabla o la columna de stats no está actualizada en dba_tables.
    Pasos para revisar y remover la fragmentación de las tablas:
    Obtener las estadísticas de las tablas:
    Para tener la diferencia exacta del tamaño actual (dba_segments) y el tamaño de las stats (dba_tables). La diferencia entre estos valores reportara la verdadera fragmentación al DBA. Así que para tener actualizadas las stats en dba_tables. Revisa el valor de LAST_ANALYZED de la tabla en dba_tables. Si este valor es reciente, puedes brincarte este paso, además yo sugeriría obtener las estadísticas de las tablas para actualizar este valor.
    exec dbms_stats.gather_table_stats(‘&schema_name’,’&table_name’);

    Revisa el tamaño de la tabla:
    De nuevo revisa el tamaño de la tabla y fíjate si se redujo. Recuerda que el dato esta en bytes, lo transformas a kb dividiéndolo en 1024 y a megabytes otra vez dividiendo en 1024
    select table_name,bytes/(1024*1024*1024) from dba_table where table_name=’&table_name’;
     Revisa la fragmentación de la tabla:
    El siguiente query te mostrara el tamaño total de la fragmentación esperada y cuanto porcentaje del tamaño se puede reclamar después de remover la fragmentación, el administrador de la base de datos te tiene que proveer el table_name y el schema_name, eso te lo pedirá este query.
    set pages 50000 lines 32767
    select owner,table_name,round((blocks*8),2)||’kb’ “Tamanio fragmentado”, round((num_rows*avg_row_len/1024),2)||’kb’ “Tamanio Actual”, round((blocks*8),2)-round((num_rows*avg_row_len/1024),2)||’kb’,
    ((round((blocks*8),2)-round((num_rows*avg_row_len/1024),2))/round((blocks*8),2))*100 -10 “espacio reclamable % ” from dba_tables where table_name =’&table_Name’ AND OWNER LIKE ‘&schema_name’
    /
    Esta consulta obtiene datos de dba_tables, así que la precisión del resultado depende de los stats del dba_table. Si tú encuentras espacio reclamable mayor al 20%, entonces podemos esperar que exista fragmentación es en esta tabla, suponiendo que el dba encuentra el 50% reclamable de la consulta anterior, puede proceder a remover la fragmentación.
    ¿cómo reiniciar los HWM /remover fragmentación?
    Tenemos cuatro opciones diferentes para reorganizar las tablas fragmentadas
    • Alter table move (mover la tabla a otro tablespace o dentro del mismo tablespace) y reconstruir índices.
    • Exportar e importar la tabla. (Muy difícil de implementar en un ambiente productivo)
    • Comando Shrink (de Oracle 10g para arriba) (el comando shrink solo es aplicable a las tablas que tengan activado “auto segment space management)
    • Alter table move (mover la tabla a otro tablespace o dentro del mismo tablespace) y reconstruir índices.

    Recolecta el estatus de todos los índices de la tabla:
    Recolectaremos todos los estatus de los índices en un solo lugar.
    select index_name,status from dba_indexes where table_name like ‘&table_name’;
    Mueve la tabla al mismo tablespace o a uno diferente:
    En este paso moveremos la tabla fragmentada a otro espacio (o al mismo) para recuperar el espacio fragmentado, encuentra el tamaño actual de tu table de los segmentos de dba_segments y revisa si continua con el mismo espacio libre.
    alter table <table_name> move; <—mueve la tabla al mismo tablespace
    O
    alter table <table_name> enable row movement;
    alter table <table_name> move tablespace <nuevo_tablespace>;
    Luego tienes que regresarlo al tablespace antiguo usando el siguiente comando:
    alter table table_name move tablespace tablespace_viejo;

    Ahora reconstruye los índices
    Necesitamos reconstruir todos los índices de la tabla porque con el comando move todos los índices viejos se vuelven inservibles

    SQL> select status,index_name from dba_indexes where table_name = ‘&table_name’;
    STATUS INDEX_NAME
    ——– ——————————
    UNUSABLE INDEX_NAME ——-> El valor que te diga aquí te dice si el índice sirve o no sirve
    SQL> alter index <INDEX_NAME> rebuild online; ——-> Usa este comando para cada índice
    Index altered.
    SQL> select status,index_name from dba_indexes where table_name = ‘&table_name’;
    STATUS INDEX_NAME
    ——– ——————————
    VALID INDEX_NAME ——-> después de ejecutar el comando anterior, aquí te debe de decir VALID
    Obtener estadísticas de la tabla
    ——————
    SQL> exec dbms_stats.gather_table_stats(‘&owner_name’,’&table_name’);
    PL/SQL procedure successfully completed.

    Revisa el tamaño de la tabla:
    —————–
    De nuevo revisa el tamaño de la tabla y verifica si ya bajo de tamaño
    select table_name,bytes/(1024*1024*1024) from dba_table where table_name=’&table_name’;

    Revisa la fragmentación de la tabla:
    ——————————–
    set pages 50000 lines 32767
    select owner,table_name,round((blocks*8),2)||’kb’ “Fragmented size”, round((num_rows*avg_row_len/1024),2)||’kb’ “Actual size”, round((blocks*8),2)-round((num_rows*avg_row_len/1024),2)||’kb’,
    ((round((blocks*8),2)-round((num_rows*avg_row_len/1024),2))/round((blocks*8),2))*100 -10 “reclaimable space % ” from dba_tables where table_name =’&table_Name’ AND OWNER LIKE ‘&schema_name’
    /
     Usa el comando shrink (para Oracle 10g)
    Comando shrink:
    Entre las nuevas características de 10g para reorganizar (shrink) las tablas “casi” en línea, puede ser usada junto al ASS (automatic segment space management)
    Este comando solo es aplicable para tablas que el tablespace tenga ASS

    Antes de usar este comando, tú debes de activar el “row movement”
    SQL> alter table <table_name> enable row movement;
    Table altered.

    Existen dos maneras de usar este comando.
    1. Reorganiza los campos y resetea el HWM
    Parte 1: reorganiza (todas las DML pueden ocurrir mientras haces esto)
     SQL> alter table <table_name> shrink space compact;
    Table altered.
     Parte 2: resetea el HWM (mientras haces esto no debes de ejecutar DMS. pero es muy rápido, casi imperceptible)
    SQL> alter table <table_name> shrink space;
    Table altered.
    2. Directamente resetea el HWM:
    SQL> alter table <table_name> shrink space; (con este comando se resetea y se reorganiza a la vez)
    Table altered.