Usando el "Last Login Time" para mejorar la seguridad de la base de datos

Es bastante común que en una base de datos Oracle tengamos la necesidad de saber si se están realizando conexiones con determinados usuarios. Esto puede ser por diferentes motivos, esquemas o usuarios creados y que nunca se han utilizado, empleados desvinculados, aplicaciones que se han migrado de base de datos pero sus esquemas originales aún permanecen, etc. Pueden existir muchas y variada razones.

Para poder detectar esto, sin necesidad de recurrir a la auditoria, desde la versión 12c Oracle comenzó a registrar el último inicio de sesión exitoso.

Esta información es almacenada en la tabla  SYS.USER $ y pueder ser consultada en la columna LAST_LOGIN de la vista DBA_USERS. Como ya mencioné, esta funcionalidad es independiente de la auditoria.

Cuando iniciamos sesión utilizando SQL*Plus, podemos ver esta información en el texto del banner.

[oracle@server01 ORADB12C][~]$ sqlplus test01

SQL*Plus: Release 12.1.0.2.0 Production on Sat Feb 13 06:31:51 2021

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password:

Last Successful login time: Sat Feb 13 2021 06:31:01 -05:00

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Advanced Analytics, Real Application Testing and Unified Auditing options

Monitoreando el uso de indices de otros esquemas

La vista v$object_usage permite ver información de la utilización de indices sobre los cuales se ha activado la opción de monitoreo con:

alter index index_name monitoring usage;

Esta vista nos brinda info de aquellos indices monitoreados pertenecientes al propio schema con el cual se está corriendo la consulta.

 SQL> select index_name, table_name, monitoring, used from v$object_usage;

INDEX_NAME                     TABLE_NAME                     MONITORING USED
------------------------------ ------------------------------ ---------- ----
T1_IDX1                        T1                             YES        NO

Si queremos ver información de todos los indices monitoreados en la base de datos, o si simplemente necesitamos verificar uno o varios owners en particular. 

Podemos utilizar la siguiente consulta:

SQL> select
           u.name "owner",
           io.name "index_name",
           t.name "table_name",
           decode(bitand(i.flags, 65536), 0, 'no', 'yes') "monitoring",
           decode(bitand(nvl(ou.flags,0), 1), 0, 'no', 'yes') "used",
           ou.start_monitoring "start_monitoring",
           ou.end_monitoring "end_monitoring"
         from
           sys.obj$ io,
           sys.obj$ t,
           sys.ind$ i,
           sys.object_usage ou,
           sys.user$ u
        where
           t.obj# = i.bo#
           and
          io.owner# = u.user#
          and
          io.obj# = i.obj#
          and
          u.name in ('<OWNER>')
          and
          i.obj# = ou.obj#(+);

 owner      index_name     table_name        monitoring used start_monitoring    end_monitoring

---------- -------------  ----------------- ---------- ---- ------------------- -------------------

TST1       T1_IDX1        T1                        no  yes 11/06/2018 13:09:24 11/06/2018 13:14:04

Nota: Lógicamente necesitaremos los privilegios necesarios de SELECT para acceder a las tablas de "sys" utilizadas y que la consulta se ejecute correctamente. 

Oracle Database 12.2: Gestión de memoria a nivel PDB en ambientes multitenant

Artículo publicado en Oracle Technology Network (OTN) en español -  mayo de 2018 

Introducción

En Oracle Database 12.1 un CDB (“Container Database”) tiene una única asignación de memoria SGA (“System Global Area”), la cual es compartida por todos los contenedores, el root container y todas las PDBs.

Lo mismo ocurre con la PGA (“Program Global Area”), donde el parámetro PGA_AGGREGATE_TARGET especifica el objetivo de memoria “target” para la PGA compartida por todos los “server process” conectados a la instancia.

Gran parte de la SGA actúa como una memoria cache que favorece a los objetos accedidos con mayor frecuencia, esto ocurre por ejemplo con el “data buffer cache”, la “shared pool”  y otras estructuras de memoria. Se dá entonces una suerte de competencia entre las distintas sesiones y procesos por la utilización de este espacio en la SGA y sus distintas estructuras asociadas.  Por tal motivo, en versión 12.1 es probable que una PDB con mucha actividad, pueda llegar a tener un dominio claramente marcado en la utilización del espacio de SGA, generando problemas de performance en otras PDBs.

Algo similar a lo anteriormente comentado, ocurre con la utilización de la PGA.

En Oracle Database 12.2 se introduce una nueva manera de gestionar la memoria permitiendo que tanto la SGA como la PGA puedan ser controladas a nivel PDB.

Obteniendo un "transaction ID" en nuestra propia sesión

En el siguiente post vamos a ver como obtener el ID de una transacción(XID) activa en nuestra propia sessión en la base de datos.

El "Transaction ID"(XID) esta conformado por los siguientes datos: 

• nro. de Undo Segment     
• nro. de Slot 
• nro. de SEQ.

Para obtener este identificador, vamos a utilizar el procedure
local_transaction_id  del package dbms_transaction (dbms_transaction.local_transaction_id)
  
Voy a ejemplificar el uso de este procedimiento utilizando una tabla creada para el caso, llamada T1, sobre la cual  luego voy a abrir una transacción (insert).

SQL> create table t1 (c1 number, c2 varchar2(20));

Table created

Una vez creada la tabla, podemos verificar si hay transacciones activas utilizando el procedure. Vemos que aún no hay ninguna en nuestra sesión:

SQL> select dbms_transaction.local_transaction_id from dual;

LOCAL_TRANSACTION_ID
--------------------------------------------------------------------------------

Cloud DBA - La metamorfosis

En este "Oracle White Paper" de Julio 2017:  The Rise of the Renaissance DatabaseAdministrator se hace un insteresante análisis de la transformación que está ocurriendo con el rol del DBA en las organizaciones, en el contexto de la acelerada evolución de la tecnología Cloud y la incorporación de soluciones DBaaS.

Aqui un breve extacto:

Clouds and DBA Tasks

For years, the roles and responsibilities of DBAs were well defined and contained within the confines of the data center or IT department. DBAs were the ultimate caretakers for their corporate databases, making sure everything was running smoothly, managing the loading and extraction of data, setting access rights and data security, and ensuring that everything was backed up. 
As cloud computing is accelerating the growth of data and the ability to move organizations into the digital race, it is also shifting DBAs’ roles and responsibilities. Cloud services – both from databases connected to the cloud, as well as databases run within clouds -- make the role of DBA more important than ever. Cloud services may help automate the management, installation, troubleshooting, performance, patching, backing up and security of data, but DBAs are needed to ensure that data environments continue to run efficiently and line up with business requirements.

A survey of members of the Independent Oracle Users Group, conducted by Unisphere research, a division of Information Today, documents the relentless growth of data – as well as its increasing importance to the business – demonstrates the increasing value of DBAs as they engage new avenues of the business. A majority, 62%, report their company’s data volume has grown more than 10% annually, and 74% state their companies’ requirements for secure, well-governed data environments that meet compliance mandates is growing as well. Many organizations are turning to data to help make better business decisions, engage with customers, and increase speed to market. 

Cloud frees up valuable DBA time and resources to provide this value to the business. Cloud-born services can help DBAs in a number of ways, handling much of the lower-level or infrastructure maintenance concerns, including the provisioning of disk space, increasing high availability, providing failover, integrating data, and enhancing security. An additional IOUG-Unisphere survey finds growing interest in Database as a Service (DBaaS) as a viable approach to serving enterprises’ needs for greater agility and faster time to market with cloud computing. DBaaS is taking off, with adoption expected to triple between 2016 and 2018. There will be a significant amount of enterprise data shifting to the cloud over that same time period as well, as enterprises rethink data management in the cloud.

Seventy-three percent of managers and professionals expect to be using DBaaS within their enterprises by that time, versus 27% at the present time. 

Creación de un Listener utilizando NETCA en modo texto

(Artículo original en portugués de Franky Weber Faust)

En el siguiente post voy a mostrar como crear un Listener con NETCA en modo texto usando un response file.



Antes de crear una base de datos, hay ocaciones en que resulta conveniente crear primero un Listener. 
Un ejemplo de esto, es si vamos a configurar el Enterprise Manager, ya que requiere que el listener  esté creado previamente y en ejecución.

Transformando vistas en tablas con el parámetro views_as_tables de Datapump en Oracle 12c

Datapump en 12c, incorpora un nuevo parámetro "VIEWS_AS_TABLES". Con este parámetro, podemos exportar una vista desde una base de datos origen e importarla como tabla en una base destino. 

Veamos como funciona esto:

Creamos primero una vista:

SQL> create view dba_view( emp_number) as select emp from dbatool;
View created.

Verificamos:

SQL> select owner,object_name,object_type from dba_objects where object_name='DBA_VIEW';
 
              OWNER OBJECT_NAM             OBJECT_TYPE
 ------------------ ---------- -----------------------
               SYS    DBA_VIEW                    VIEW

Realizamos un export de la vista, como tabla, utilizando el parámetro: views_as_tables

[oracle@localhost ~]$ expdp dumpfile=view.dmp logfile=view.log directory=DUMP views_as_tables=DBA_VIEW

Export: Release 12.1.0.2.0 - Production on Sat Aug 22 07:07:54 2015

Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.

Username: sys/oracle@ORCL as sysdba

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYS"."SYS_EXPORT_TABLE_01": sys/********@ORCL AS SYSDBA dumpfile=view.dmp logfile=view.log directory=DUMP views_as_tables=DBA_VIEW
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/VIEWS_AS_TABLES/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type TABLE_EXPORT/VIEWS_AS_TABLES/TABLE
. . exported "SYS"."DBA_VIEW" 5.117 KB 8 rows
Master table "SYS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
/home/oracle/DUMP/view.dmp
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at Sat Aug 22 07:08:17 2015 elapsed 0 00:00:11

Lock automático de cuentas con INACTIVE_ACCOUNT_TIME

En Oracle  Release 12.2 podemos usar el parámetro INACTIVE_ACCOUNT_TIME en un profile, para bloquear automáticamente una cuenta de usuario con la cual no se ha iniciado sesión en los últimos "n "días. Número especificado por el parámetro. 

1-  Por default está seteado en UNLIMITED
2-  La configuración  mínima es de 15 dias y la máxima de 24855

col RESOURCE_NAME for a43
col limit for a23
set lines 299
SQL> select RESOURCE_NAME,limit from dba_profiles where profile='DEFAULT';

RESOURCE_NAME                               LIMIT
------------------------------------------- -----------------------
COMPOSITE_LIMIT                             UNLIMITED
SESSIONS_PER_USER                           UNLIMITED
CPU_PER_SESSION                             UNLIMITED
CPU_PER_CALL                                UNLIMITED
LOGICAL_READS_PER_SESSION                   UNLIMITED
LOGICAL_READS_PER_CALL                      UNLIMITED
IDLE_TIME                                   UNLIMITED
CONNECT_TIME                                UNLIMITED
PRIVATE_SGA                                 UNLIMITED
FAILED_LOGIN_ATTEMPTS                       10
PASSWORD_LIFE_TIME                          180
PASSWORD_REUSE_TIME                         UNLIMITED
PASSWORD_REUSE_MAX                          UNLIMITED
PASSWORD_VERIFY_FUNCTION                    NULL
PASSWORD_LOCK_TIME                          1
PASSWORD_GRACE_TIME                         7
INACTIVE_ACCOUNT_TIME                       UNLIMITED ----------- > This is the resource_name introduced in oracle 12.2.

17 rows selected.

col RESOURCE_NAME for a43
col limit for a23
set lines 299
SQL> select RESOURCE_NAME,limit from dba_profiles where profile='DEFAULT';

RESOURCE_NAME                               LIMIT
------------------------------------------- -----------------------
COMPOSITE_LIMIT                             UNLIMITED
SESSIONS_PER_USER                           UNLIMITED
CPU_PER_SESSION                             UNLIMITED
CPU_PER_CALL                                UNLIMITED
LOGICAL_READS_PER_SESSION                   UNLIMITED
LOGICAL_READS_PER_CALL                      UNLIMITED
IDLE_TIME                                   UNLIMITED
CONNECT_TIME                                UNLIMITED
PRIVATE_SGA                                 UNLIMITED
FAILED_LOGIN_ATTEMPTS                       10
PASSWORD_LIFE_TIME                          180
PASSWORD_REUSE_TIME                         UNLIMITED
PASSWORD_REUSE_MAX                          UNLIMITED
PASSWORD_VERIFY_FUNCTION                    NULL
PASSWORD_LOCK_TIME                          1
PASSWORD_GRACE_TIME                         7
INACTIVE_ACCOUNT_TIME                       UNLIMITED ----------- > This is the resource_name introduced in oracle 12.2.

17 rows selected.

Quien está generando tanto redo?

Comparto aqui una consulta que puede sacarnos de un apuro cuando alguna FRA "explota" por la continua generación de "redo" y no sabemos bien el origen de esas transacciones.
La consulta muestra los "top" generadores de redo.
Espero les resulte útil.

set linesize 150
set pages 9999

column sid format 9999
column serial# format 99999
column name format a20
column username format a15
column logon format a20
column idle format a10
column value format 9G999G999G999
column program format a50

select sid, serial#, username, program, name, value, logon, idle
from ( select sess.sid, sess.serial#, sess.username, program, statn.name, sesst.value,
              to_char(sess.logon_time, 'DD/MM/YYYY HH24:MI:SS') logon,
              floor(sess.last_call_et/3600)||':'|| floor(mod(sess.last_call_et,3600)/60)||':'|| mod(mod(sess.last_call_et,3600),60) idle,
              row_number() over
                ( partition by statn.name
                  order by sesst.value desc
                 ) rn
       from v$session sess, v$sesstat sesst, v$statname statn
       where sess.sid = sesst.sid
             and sesst.statistic# = statn.statistic#
             and statn.name in
                ('redo blocks written', 'redo size', 'redo wastage')
             and sesst.value > 0
     )
where rn <= 5
order by name, value desc;

Consulta para verificar el "timestamp" de la última DDL y DML

A continuación les muestro una consulta útil para conocer el momento ("timestamp") de las últimas sentencias DML y DDL ejecutadas sobre una tabla determinada:

select
      (select to_char(last_ddl_time,'DD-MM-YYYY HH24:MI:SS') from dba_objects where object_name='{tabla}' and owner='{schema}') "Last DDL",
        decode(maxscn,0,'N/A',scn_to_timestamp(maxscn)) "Last DML"
 from
      (select nvl(max(ora_rowscn),0) maxscn from {schema}.{tabla});

Demostración:
Creamos una tabla nueva:

SQL> create table USER01.T1 (c1 number, c2 varchar2(10));

Table created.

Corremos la consulta y podemos ver que se actualizó el timestamp del "Last DDL" y "Last DML" todavía  nos muestra N/A, ya que no se ejecutó aún ninguna sentencia.

Moviendo tablas ONLINE en Oracle Database 12cR2 (12.2)

Una de las "new features" de 12cR2 que me resulta particularmente atractiva, es sin dudas la de poder mover tablas de manera ONLINE.
No tanto por lo novedosa y compleja, sino por como esto puede simplificarnos un poco la vida a los DBAs. Evitandonos tal vez, horarios extraños, madrugones o fines de semanas cortados para realizar tareas de mantenimiento en ambientes críticos.

De que se trata?
Tanto el "move" de la tabla como el "rebuild" del indice es ONLINE. Y puede ser realizado en una misma operación.

Veamos un ejemplo:

Creamos primero una tabla con un indice primary key: 

SQL> create table T1 (c1 number, c2 varchar2(20));

Table created

Invisible Columns en Oracle Database 12C

In Oracle Database 12c, you can set a column in table as invisible either during CREATE TABLE or modifying existing table via ALTER TABLE command. By default, table columns are always visible. When you make it invisible, the COL# column in COL$ dictionary is updated to 0, and so is not included in the “SELECT *” or “INSERT INTO VALUES” statements unless specifically selected – it can be reverted back to visible by using ALTER TABLE command.

When you change an invisible column in Oracle 12c database to visible, the COL# assigned will be the highest available, so the column becomes the last column in the table (not storage, only display). So, if you accidentally make a column invisible and correct this by changing it to visible, the column order changes. Therefore, if the application uses “SELECT *” or “INSERT” without column names, they might break!

Once a table’s column is set to invisible, the following key statements will not work for the invisible column:

• SELECT * FROM in SQL Statement
• DESCRIBE statement
• %ROWTYPE in PL/SQL variable declaration
• Invisible columns will still available for indexing and such indexes can be used for cost-based optimizer purposes. Don’t confuse an invisible index with an index on invisible column, as they are entirely different concepts.

  Continuar leyendo aqui

Fuente: http://allthingsoracle.com/invisible-columns-in-oracle-database-12c/

Errores y bugs relacionados con el DBWn (Database Writer Process)

The primary responsibility of DBWn is to write data blocks to disk. DBWn also handles checkpoints, file open synchronization, and logging of Block Written records.

In many cases the blocks that DBWn writes are scattered throughout the disk. Thus, the writes tend to be slower than the sequential writes performed by LGWR. DBWn performs multiblock writes when possible to improve efficiency. The number of blocks written in a multiblock write varies by operating system.

The DB_WRITER_PROCESSES initialization parameter specifies the number of DBWn processes (DBW0-DBW9 and DBWa-DBWz). The database selects an appropriate default setting for this parameter or adjusts a user-specified setting based on the number of CPUs and processor groups.

Issues Specific to DBWn

Note 243248.1 - Database Startup fails with ORA-443 Background Process "DBW0" did not Start

Note 1065267.6 - ORA-445 Background Process DBW0 Did Not Start After 120 Seconds

Note 1461704.1 - ORA-00600 [kcbbxsv_2] Errors And DBW0: Terminating Instance Due To Error 471 (

Note 6005113.8 - Bug 6005113 - OERI[kclrwrite_7] in DBWn process followed by instance crash in RAC

Errores y bugs relacionados con el LGWR (Log Writer Process)

Algunos issues relacionados con el Log Writer y notas asociadas:

Redo log entries are generated in the redo log buffer of the system global area (SGA). LGWR writes the redo log entries sequentially into a redo log file. If the database has a multiplexed redo log, then LGWR writes the redo log entries to a group of redo log files.

Issues Specific to LGWR

Note 470.1 - Error ORA-00470: LGWR process terminated with error

Note 431246.1 - Pmon terminated instance due to LGWR termination ORA-470

Note 1089733.1 - ORA-00494: enqueue [CF] held for too long (more than 900 seconds); LGWR:Terminating Instance Due to Error 2103

Note 9556189.8 - Bug 9556189 - LGWR hangs for long periods using DNFS - CF waits likely

Note 6193945.8 - Bug 6193945 - High LGWR CPU use and long 'log file sync' latency in RAC

Note 6074620.8 - Bug 6074620 - LGWR unconditionally writes to trace file

Note 5896963.8 - Bug 5896963 - High LGWR CPU and longer "log file sync" with fix for bug 5065930

Note 5118272.8 - Bug 5118272 - Instance crash with ORA-600 [1433], [60] due to lgwr filling up msg blocks (Messages could be for LGWR or ARCH)

Note 813473.1 - LGWR Uses Async I/O Inspite Of Setting _lgwr_async_io=False

Note 1278149.1 - Intermittent Long 'log file sync' Waits, LGWR Posting Long Write Times, I/O Portion of Wait Minima

Issues relacionados con el controlfile y como resolverlas

A continuación un compilado de notas referidas a issues relacionadas al control file y como resolverlas:

Note 429943.1 Summary Of Bugs On ORA-00600 [2103] Error
Note 1084048.6 ORA-01503, ORA-01161: on Create Controlfile
Note 881082.1 Unable to Restore Controlfile From RMAN Autobackup
Note 1072417.1 Performance Degradation as a Result of 'enq: CF - contention'
Note 1058851.6 EXCESSIVE I/O CONTROLFILE PERFORMANCE PROBLEMS
Note 265599.1 ORA-600 [2130] REPORTED With RMAN RESTORE CONTROLFILE VALIDATE
Note 849071.1 10.2.0.3 Instance Crash With ORA-600 [2103] Error
Note 28045.1 ORA-600 [2103] "Timeout on 'Control file' or 'Checkpoint Progress' Enqueue"
Note 1308378.1 After Upgrade To 11.2.0.2 We Recieve Ora-00245 During Autobackup Of The Controlfile
Note 10317487.8 Bug 10317487 - RMAN controlfile backup fails with ODM error ORA-17500 or ORA-245
Note 9145541.8 Bug 9145541 - OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g
Note 342696.1 Rman-20033: Control File Sequence# Too Low Rman-20033
Note 1265103.1 RMAN DUPLICATE fails with ORA-600 [KGEADE_IS_0] while creating controlfile

Notas MOS relacionadas con controlfile

Notas relacionadas con controlfile:

Note 735106.1 How to Recreate a Controlfile
Note 881082.1 Unable to Restore Controlfile From RMAN Autobackup
Note 580414.1 RMAN - How to restore the controlfile using RMAN
Note 345180.1 How to duplicate a controlfile when ASM is involved
Note 329981.1 10gR2 New Feature: Eliminate Control File Re-Creation
Note 305565.1 Persistent Controlfile configurations for RMAN in 9i and 10g

Note 1056057.1 HOW TO MONITOR CONTROLFILE SECTION EXPANSION OVER TIME

Note 1086496.1 HOW DO CIRCULAR CONTROLFILE SECTIONS EXPAND? (LOG HISTORY / ARCHIVED LOG ETC)

Note 470463.1 How To Catalog Backups / Archivelogs / Datafile Copies / Controlfile Copies
Note 403883.1 How To Restore Controlfile From A Backupset Without A Catalog Or Autobackup
Note 406191.1 Diagnosing ORA-600 [2103] Issues in a NON RAC environment

Errores ORA- relacionados con Background Processes

A continuación algunos errores relacionados con background processes y las MOS Notes asociadas:

ORA-443 background process did not start
          See Note 18442.1 - OERR: ORA 443 background process <name> did not start

ORA-444 background process failed while starting
          See Note 18443.1 - OERR: ORA 444 background process <name> failed while starting

ORA-445 background process did not start after seconds
          See Note 18444.1 - OERR: ORA 445 background process <name> did not start after <num> seconds

ORA-446 background process started when not expected
          See Note 18445.1 - OERR: ORA 446 background process started when not expected

ORA-447 fatal error in background process
          See Note 18446.1 - OERR: ORA 447 fatal error in background process

Parámetros de inicio en 12c cuando se utiliza arquitectura de bases de datos CDB/PDB (multitenant)

A text initialization parameter file (PFILE) cannot contain PDB-specific parameter values. 

A CDB uses an inheritance model for initialization parameters in which PDBs inherit initialization parameter values from the root. In this case, inheritance means that the value of a particular parameter in the root applies to a particular PDB.

A PDB can override the root's setting for some parameters, which means that a PDB has an inheritance property for each initialization parameter that is either true or false. The inheritance property is true for a parameter when the PDB inherits the root's value for the parameter. The inheritance property is false for a parameter when the PDB does not inherit the root's value for the parameter.

The inheritance property for some parameters must be true. For other parameters, you can change the inheritance property by running theALTER SYSTEM SET statement to set the parameter when the current container is the PDB. If ISPDB_MODIFIABLE is TRUE for an initialization parameter in the V$SYSTEM_PARAMETER view, then the inheritance property can be false for the parameter. When the current container is the root, the CONTAINER clause of the ALTER SYSTEM SET statement controls which PDBs inherit the parameter value being set.

Como saber si la instancia arrancó con PFILE o SPFILE?

Hay 3 maneras:

1) From V$SPPARAMETER View.

V$SPPARAMETER view lists the contents of the SPFILE. The view returns NULL values if a PFILE was used to start up the instance.

2) Using SHOW PARAMETER:

SQL> show parameter spfile;

This query returns the spfile name if the database was started with spfile.
It shows no value if the database is started with pfile.

 3) Using the alert.log file:

- When a pfile is used, it shows something similar to:
Starting ORACLE instance (normal)
...
Using parameter settings in server-side pfile D:\APP\MREHEEM\PRODUCT\11.2.0\DBHOME_4\DATABASE\INITORCL.ORA

- When an spfile is used, it shows something similar to:
Starting ORACLE instance (normal)
...
Using parameter settings in server-side spfile D:\APP\MREHEEM\PRODUCT\11.2.0\DBHOME_4\DATABASE\SPFILEORCL.ORA

Ref: How to Find Whether database Instance Started with PFILE or SPFILE? (Doc ID 444775.1)

Ver hidden parameters

Para ver los parametros ocultos, ejecutar la siguiente consulta como SYSDBA:

SELECT a.ksppinm "Parameter",

       b.ksppstvl "Session Value",

       c.ksppstvl "Instance Value",

       decode(bitand(a.ksppiflg/256,1),1,'TRUE','FALSE') IS_SESSION_MODIFIABLE, 

       decode(bitand(a.ksppiflg/65536,3),1,'IMMEDIATE',2,'DEFERRED',3,'IMMEDIATE','FALSE') IS_SYSTEM_MODIFIABLE

FROM   x$ksppi a,

       x$ksppcv b,

       x$ksppsv c

WHERE  a.indx = b.indx

AND    a.indx = c.indx

AND    a.ksppinm LIKE '/_%' escape '/'

/