Oracle APEX, pequeña introducción

¿Que es APEX?

Oracle Application Express (ApEx) es una herramienta de desarrollo web que permite compartir datos y crear aplicaciones personalizadas de forma rápida. Con ayuda de un explorador web y sin necesidad de contar con conocimientos avanzados de programación, se podrán desarrollar y desplegar potentes aplicaciones, rápidas y seguras.

El desarrollo de aplicaciones con APEXestá basado en el explorador y permite desarrollar aplicaciones desde cualquier PC conectado en red,utilizando para ello tan sólo un explorador web actual. La tecnología APEX se basa y usa como núcleo SQL y PL / SQL. APEX es una herramienta declarativa que proporciona gran cantidad de características diseñadas para hacer el trabajo de desarrollo más fácil. El propio APEX se encarga de muchas de las funciones subyacentes comunes a todas las aplicaciones basadas en web; esto permite al programador centrarse en la lógica específica de la aplicación.

¿Cuáles son los requisitos?

• Conocer sobre consultas SQL (básico) y programación con PL SQL (básico)

• HTML, CSS (no excluyente)

Instalación de Oracle APEX 

Antes de instalar Oracle Application Express (Oracle APEX) es necesario:

• Instalar base de datos Oracle (10g, 11g o 12c)

Estas son las versiones soportadas por Oracle APEX:

• Linux x86
• Linux x86-64
• Oracle Solaris on SPARC (64 bit)
• Oracle Solaris x86-64 (64 bit)
• HP-UX Itanium
• Microsoft Windows (32-bit)
• Microsoft Windows x64 (64-bit)
• IBM AIX on POWER Systems (64-bit)
• IBM: Linux on System z
• HP-UX PA-RISC (64-bit)

Descomprima el archivo zip que ha descargado en alguna posición de la unidad de disco duro. Aquí lo descomprimo en C: / DevProgram

A continuación, introduzca la sentencia sqlplus para iniciar sesión en sqlplus (Nota: no abra sqlplus directamente, sino a través de CMD después de posicionarse en el APEX home)

--
-- Run script apexins.sql with parameters:
--
-- @apexins.sql tablespace_apex tablespace_files tablespace_temp images
--
-- Where:
-- tablespace_apex is the name of the tablespace for the Oracle Application Express application user.
-- tablespace_files is the name of the tablespace for the Oracle Application Express files user.
-- tablespace_temp is the name of the temporary tablespace or tablespace group.
-- images is the virtual directory for Oracle Application Express images.
-- (To support future Oracle Application Express upgrades, define the virtual image directory as /i/.)
--
 
@apexins.sql sysaux sysaux temp /i/

El script anterior crea un SCHEMA en la base de datos, puede probar consultando Ver ALL_USERS en SQLPlus

--
-- Running script apex_epg_config.sql with parameter:
-- @apex_epg_config.sql parent of apex directory
--
 
@apex_epg_config.sql C:\DevPrograms

Habilitar usuario anonymous

--
-- Unlock user anonymous:
 alter user anonymous account unlock;

apexconf.sql 

 Ejecutar script apexconf.sql Se utiliza para realizar los pasos finales de configuración de Oracle Application Express, incluida la configuración del puerto de escucha HTTP XDB ​​y la contraseña ADMIN de Application Express.

--
-- Running script: @apxconf.sql
-- Setup password for ADMIN
-- Configuring XDB Http Listener port
--
 
@apxconf.sql

El usuario, puede usar ADMIN de forma predeterminada y el correo electrónico puede omitirse. Para la contraseña, el sistema requiere que ingrese una contraseña segura: 

• La contraseña no se ajusta a las reglas de complejidad de contraseñas de este sitio. 
• La contraseña debe contener al menos 6 caracteres.
• La contraseña debe contener al menos un carácter alfabético (abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ). 
• La contraseña debe contener al menos un carácter de puntuación (! "# $% & ()` '* +, - /:;? _).
• La contraseña debe contener al menos un carácter alfabético en mayúsculas. 
• La contraseña debe contener al menos un carácter alfabético en minúsculas.

El puerto predeterminado es 8080

Vamos a un navegador y tecleamos

• http://localhost:8080/apex/apex_admin

Introducimos clave y usuario.

Error ORA-38856 cuando duplicas una base de datos 11gR2 en entorno de alta disponibilidad

¿Qué hacer cuando duplicas una base de datos Oracle aparece este tipo de error en un entorno RAC?

En estos días, repasando mis Oracle skills, he estado clonando una bases de datos en RAC 11gR2 con el siguiente script:

RUN
{
ALLOCATE AUXILIARY CHANNEL CH1  TYPE DISK ;
ALLOCATE AUXILIARY CHANNEL CH2  TYPE DISK ;
DUPLICATE DATABASE TO TESTDB
  BACKUP LOCATION '/mount/harkonnen/copia01/originales/'
  DB_FILE_NAME_CONVERT '+DATA/ORIGINAL/DATAFILE','+DATA/TESTDB/DATAFILE'
  PFILE '/mount/dba01/oracle/TESTDB/pfile/initTESTDB1.ora'
  NOFILENAMECHECK
  NOREDO
LOGFILE
  GROUP 1 (
    '+DATA/TESTDB/ONLINELOG/redo01g1.log',
    '+DATA/TESTDB/ONLINELOG/redo02g1.log'
  ) SIZE 300M ,
  GROUP 2 (
    '+DATA/TESTDB/ONLINELOG/redo01g2.log',
    '+DATA/TESTDB/ONLINELOG/redo02g2.log'
  ) SIZE 300M
 ;

Al acabar la clonación, justo al abrir la base de datos, sucedio el siguiente error:

contents of Memory Script:
{
   Alter clone database open resetlogs;
}

alter database open resetlogs
*
ERROR at line 1:
ORA-38856: cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) 

Buceando en la inmensa Oracle Support encontré la nota 334899.1, en la que marca que podemos utilizar el siguiente parámetro:

_no_recovery_through_resetlogs=TRUE

Una vez que cambie el parámetro, volvi a lanzar la clonación de la base de datos, y esta vez acabo sin ningún problema

Error ORA-01503 y ORA-12720 cuando clonas una BD en entornos de alta disponibilidad

¿Qué hacer cuando mientras clonas una base de datos Oracle aparece este tipo de error en una implantación RAC?

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 10/07/2016 13:31:14
RMAN-06136: ORACLE error from auxiliary database: ORA-01503: CREATE CONTROLFILE failed
ORA-12720: operation requires database is in EXCLUSIVE mode

Se ha de cambiar el parámetro cluster_database a falso:

alter system set cluster_database=FALSE scope=spfile sid='INSTANCE_NAME';

Una vez que hayas terminado con el proceso de clonación, tienes que regresar el parámetro a verdadero para que esta instancia siga siendo parte de tu configuración de RAC.

alter system set cluster_database=TRUE scope=spfile sid='INSTANCE_NAME';

Java Forensics en bases de datos Oracle

Esta vez quiero mostrar cómo determinar si los ataques de privilegio de Java se han producido en su base de datos, tanto como medida de precaución como para el análisis forense después del incidente, con el fin de verificar si un ataque de esta naturaleza ha ocurrido o no.

En primer lugar veamos la situación en la que un atacante utiliza DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY para concederse a sí mismos cualquier privilegio Java de CREATE SESSION debido a ejecutar DBMS_JVM_EXP_PERMS.

Si su base de datos está recogiendo mensajes de error a continuación, busca errores del tipo ORA-29532:

SQL> DECLARE  
  2  POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;  
  3  CURSOR C1 IS SELECT 'GRANT','JAVATEST','SYS','java.io.FilePermission','$','execute',
                        'ENABLED' FROM DUAL;  
BEGIN  
OPEN C1;  
  4    5  FETCH C1 BULK COLLECT INTO POL;  
  6  CLOSE C1;  
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);  
  7    8  END;  
  9  / 10  
DECLARE  
*  
ERROR at line 1:  
ORA-29532: Java call terminated by uncaught Java exception:  
java.lang.SecurityException: policy table update java.lang.RuntimePermission,  
loadLibrary.*  
ORA-06512: at "SYS.DBMS_JVM_EXP_PERMS", line 189  
ORA-06512: at line 8 

La escalada de privilegios aún ha tenido éxito por lo que el mensaje de error es un poco engañoso, pero podría ser un indicador útil.

SQL>  SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';  
  
TYPE_NAME  
--------------------------------------------------------------------------------  
NAME  
--------------------------------------------------------------------------------  
ACTION  
--------------------------------------------------------------------------------  
java.io.FilePermission  
 $ 
execute  

Vamos a centrarnos en la identificación de la escalada de privilegios de Java. 
Una vez que se han asignado privilegios de Java existen múltiples formas de utilizar el privilegio de ganar SYSDBA, y una vez adquirido, el atacante tendría limpiar el rastro que habían dejado atrás, primero instalando un rootkit, y luego revocar privilegios y eliminando las cuentas que se crearon en el camino. 

Así, el reto de un investigador forense es buscar pistas que un atacante puede no haber sido lo suficientemente diligente para limpiar. 

Así, en primer lugar, ¿cómo podemos saber si un usuario se ha concedido privilegios Java? DBA_JAVA_POLICY es la vista fundamental, y esto muestra amablemente todos los privilegios concedidos por orden cronológico de Java utilizando el número de secuencia de incrementar…

SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';  
  
TYPE_NAME  
--------------------------------------------------------------------------------  
NAME  
--------------------------------------------------------------------------------  
ACTION  
--------------------------------------------------------------------------------  
java.io.FilePermission  
ALL FILES
execute 

Así que si un atacante sabe esto, es probable que ha ga drop de a cuenta de ataque y lo recrea si es necesario como parte de un ataque posterior. Sin embargo, si nos fijamos en la tabla base sys.java $ policy $ para la vista DBA_JAVA_POLICY, veremos que la tabla realmente persiste en las concesiones de Java, incluso después de que el usuario haya sido eliminado !!! Esto es útil para una investigación posterior a incidentes.

SELECT * FROM sys.java$policy$ ORDER BY key DESC;  
  
KIND#   GRANTEE#    TYPE_SCHEMA#    TYPE_NAME   NAME    ACTION  STATUS# KEY  
-----------------------------------------------------------------------------------------------------  
0   101 0   java.io.FilePermission  ALL FILES   execute 2   282  
0   100 0   java.io.FilePermission  ALL FILES   execute 2   262  
0   54  0   java.io.FilePermission  ALL FILES   execute 2   242  
  
--Note that the GRANTEE# correlates to the sys.user$.USER# column and we can see   
-- that user 101 and 100 both had execute on ALL FILE   
-- ,but these users no longer exist in sys.user$ and still the privs are recorded in sys.java$policy$ ~which could be very useful info..  
  
SQL> select name from sys.user$ where user# in (101, 100);  
  
no rows selected  
  
SQL> select name from sys.user$ where user# in (54);  
  
NAME  
------------------------------  
SCOTT  
  
--Of course a clever attacker that had gained SYS could delete from the base table..  
  
SQL> delete from sys.java$policy$ where key='242';  
  
1 row deleted.  
  
SQL> commit;  
  
Commit complete.  
  
--And the evidence of the escalation has gone.. How would an investigator see that the table had been modified in this case?   
--Tracing back further it would hopefully be possible to use the dba_tab_modifications view:  
  
SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$'  
  2  ;  
  
no rows selected  
--This empty result set is due to the fact that MONITORING is not set on this table by default. This could be rectified as follows in this example.  
SQL> exec dbms_stats.gather_table_stats ('SYS','JAVA$POLICY$');  
  
PL/SQL procedure successfully completed.  
  
SQL> delete from sys.java$policy$ where key='282';  
  
0 rows deleted.  
  
SQL>  delete from sys.java$policy$ where key='242';  
  
1 row deleted.  
  
SQL> execute dbms_stats.flush_database_monitoring_info;  
  
PL/SQL procedure successfully completed.  
  
SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$';  
  
TABLE_OWNER     TABLE_NAME      PARTITION_NAME      SUBPARTITION_NAME  INSERTS    UPDATES    DELETES TIMESTAMP TRU DROP_SEGMENTS  
------------------------------ ------------------------------ ------------------------------ ------------------------------ ---------- ----------   
SYS                 JAVA$POLICY$                                           0          0          1        31-MAR-10 NO              0  
  
--It is unlikely that a DB will have had this default setting changed beforehand though..   
--So what else can be done to see if the DBA_JAVA_POLICY table has been changed recently?  
  
SQL> select scn_to_timestamp(Max(ora_rowscn)) from sys.java$policy$;  
  
SCN_TO_TIMESTAMP(MAX(ORA_ROWSCN))  
-----------------------------------------------------  
30-MAR-10 06.10.06.000000000 PM  

Nota: esta consulta normalmente trabajará hasta 7 días después de que el cambio haya ocurrido, por lo que si obtiene este error ORA-08181 la tabla probablemente no ha tenido comandos de manipulación de datos (DML) en él durante ese tiempo.

ORA-08181: specified number is not a valid system change number

Nuevos parámetros SPFILE en base de datos Oracle 12.2.0.1

La Base de Datos Oracle 12.2.0.1 está disponible ahora en la nube de Oracle.

Y esta es la lista de los 46 nuevos parámetros init.ora / spfile comparados con la base de datos Oracle 12.1.0.2. Ojo que algunos de ellos están sin documentar a día de hoy.

Parameter	Description
allow_global_dblinks	ALLOW_GLOBAL_DBLINKS specifies whether LDAP lookup for database links is allowed for the database.
allow_group_access_to_sga	ALLOW_GROUP_ACCESS_TO_SGA controls group access to shared memory on UNIX platforms. The default value is false, which means that database shared memory is created with owner access only. In Oracle Database releases prior to Oracle Database 12c Release 2 (12.2.0.1), database shared memory was created with owner and group access.
approx_for_aggregation	APPROX_FOR_AGGREGATION replaces exact query processing for aggregation queries with approximate query processing. Data analysis applications heavily use aggregate function and analytic function queries. Aggregation functions and analytic functions require sorting of large volumes of data, and exact query answering requires lots of memory, and can be time consuming. With approximate query processing, the results of aggregate function and analytic function queries are returned much faster than with exact query processing.
approx_for_count_distinct	APPROX_FOR_COUNT_DISTINCT automatically replaces COUNT (DISTINCT expr) queries with APPROX_COUNT_DISTINCT queries. Query results for APPROX_COUNT_DISTINCT queries are returned faster than the equivalent COUNT (DISTINCT expr) queries. APPROX_COUNT_DISTINCT queries are useful for situations where a tolerable amount of error is acceptable in order to obtain faster query results than with a COUNT (DISTINCT expr) query.
approx_for_percentile	APPROX_FOR_PERCENTILE converts exact percentile functions to their approximate percentile function counterparts. Approximate percentile function queries are faster than their exact percentile function query counterparts, so they can be useful in situations where a tolerable amount of error is acceptable in order to obtain faster query results.
asm_io_processes	ASM_IO_PROCESSES specifies the number of I/O worker processes to be started in an Oracle Automatic Storage Management (Oracle ASM) IOServer instance. This parameter is applicable only in an Oracle ASM IOServer instance, which runs out of an Oracle Grid home. The default value should work in most cases
autotask_max_active_pdbs	AUTOTASK_MAX_ACTIVE_PDBS enables you to specify the maximum number of PDBs that can schedule automated maintenance tasks at the same time (during a maintenance window). This parameter only affects PDBs. The CDB$ROOT container (CDB root) for a CDB can always schedule and run maintenance tasks during a maintenance window. The default value is 2.
awr_pdb_autoflush_enabled	AWR_PDB_AUTOFLUSH_ENABLED enables you to specify whether to enable or disable automatic Automatic Workload Repository (AWR) snapshots for all the PDBs in a CDB or for individual PDBs in a CDB. Default value is false.
cdb_cluster	[undocumented]
cdb_cluster_name *	[undocumented]
clonedb_dir *	CLONEDB_DIR sets the directory path where CloneDB bitmap files should be created and accessed. By default the CloneDB bitmap file is created under the $ORACLE_HOME/dbs directory.
containers_parallel_degree	CONTAINERS_PARALLEL_DEGREE can be used to control the degree of parallelism of a query involving containers(). The value of containers_parallel_degree, if set, will override the default DOP for a containers() query. By default, a containers() query uses a degree of parallelism equal to (1 + number of open PDBs) in the case of CDB root and (1 + number of open application PDBs) in the case of application root. If the value of CONTAINERS_PARALLEL_DEGREE is lower than 65535, then this value is used as the degree of parallelism of a query involving  containers(). Otherwise (when the value is 65535), the default degree of parallelism is (1 + number of open PDBs) or (1 + number of open application PDBs) as described above.
cursor_invalidation	CURSOR_INVALIDATION controls whether deferred cursor invalidation or immediate cursor invalidation is used for DDL statements by default.
data_guard_sync_latency	Data Guard SYNC latency
data_transfer_cache_size	DATA_TRANSFER_CACHE_SIZE sets the size of the data transfer cache (in bytes) used to receive data blocks (typically from a primary database in an Oracle Data Guard environment) for consumption by an instance during execution of an RMAN RECOVER ... NONLOGGED BLOCK command
default_sharing	DEFAULT_SHARING sets the value of the sharing clause in statements creating objects in an application root. Specifying SHARING= in the create DDL overrides the value of the DEFAULT_SHARING parameter.
disable_pdb_feature *	[undocumented]
enable_automatic_maintenance_pdb	Enable/Disable Automated Maintenance for Non-Root PDB
enable_dnfs_dispatcher	Enable DNFS Dispatcher
enabled_PDBs_on_standby	List of Enabled PDB patterns
encrypt_new_tablespaces	whether to encrypt newly created tablespaces
exafusion_enabled	Enable Exafusion
external_keystore_credential_location	external keystore credential location
inmemory_adg_enabled	Enable IMC support on ADG
inmemory_expressions_usage	Controls which In-Memory Expressions are populated in-memory
inmemory_virtual_columns	Controls which user-defined virtual columns are stored in-memory
instance_abort_delay_time	time to delay an internal initiated abort (in seconds)
instance_mode	indicates whether the instance read-only or read-write or read-mostly
long_module_action	Use longer module and action
max_datapump_jobs_per_pdb	maximum number of concurrent Data Pump Jobs per PDB
max_idle_time	maximum session idle time in minutes
max_iops	MAX IO per second
max_mbps	MAX MB per second
max_pdbs	max number of pdbs allowed in CDB or Application ROOT
ofs_threads	Number of OFS threads
one_step_plugin_for_pdb_with_tde *	[undocumented] Facilitate one-step plugin for PDB with TDE encrypted data
optimizer_adaptive_plans	controls all types of adaptive plans
optimizer_adaptive_statistics	controls all types of adaptive statistics
outbound_dblink_protocols	Outbound DBLINK Protocols allowed
remote_recovery_file_dest	default remote database recovery file location for refresh/relocate
resource_manage_goldengate	RESOURCE_MANAGE_GOLDENGATE determines whether Oracle GoldenGate apply processes in the database are resource managed. To enable Resource Manager, set the RESOURCE_MANAGER_PLAN parameter. By default, Oracle GoldenGate apply processes in the database are not resource managed. Given that replication to a PDB requires a separate Oracle GoldenGate apply process,
sga_min_size	SGA_MIN_SIZE sets the guaranteed SGA size for a pluggable database (PDB). When SGA_MIN_SIZE is set for a PDB, it guarantees the specified SGA size for the PDB. Setting this parameter at the CDB level has no effect.
shrd_dupl_table_refresh_rate	duplicated table refresh rate (in seconds)
standby_db_preserve_states	STANDBY_DB_PRESERVE_STATES is meaningful on a physical standby database that is open in real-time query mode. The parameter controls whether user sessions and other internal states of the instance are retained when a readable physical standby database is converted to a primary database. The possible values for the parameter are NONE, SESSION, and ALL
target_pdbs*	[undocumented] Parameter is a hint to adjust certain attributes of the CDB
uniform_log_timestamp_format	UNIFORM_LOG_TIMESTAMP_FORMAT specifies that a uniform timestamp format be used in Oracle Database trace (.trc) files. When the value of UNIFORM_LOG_TIMESTAMP_FORMAT is TRUE, the format used for timestamps in trace files is standardized on universal time with millisecond precision.