Subscribe to Posts by Email

Subscriber Count

    705

Disclaimer

All information is offered in good faith and in the hope that it may be of use for educational purpose and for Database community purpose, but is not guaranteed to be correct, up to date or suitable for any particular purpose. db.geeksinsight.com accepts no liability in respect of this information or its use. This site is independent of and does not represent Oracle Corporation in any way. Oracle does not officially sponsor, approve, or endorse this site or its content and if notify any such I am happy to remove. Product and company names mentioned in this website may be the trademarks of their respective owners and published here for informational purpose only. This is my personal blog. The views expressed on these pages are mine and learnt from other blogs and bloggers and to enhance and support the DBA community and this web blog does not represent the thoughts, intentions, plans or strategies of my current employer nor the Oracle and its affiliates or any other companies. And this website does not offer or take profit for providing these content and this is purely non-profit and for educational purpose only. If you see any issues with Content and copy write issues, I am happy to remove if you notify me. Contact Geek DBA Team, via geeksinsights@gmail.com

Pages

Administration : How to distinguish you are seeing rows on CDB or PDB

Hi,

In view of multiple databases sharing single SGA how to distinguish which database you will need to see.

Now all dynamic views has two new columns for example:- V$process

	SQL> desc v$process
	Column			Datatype
	ADDR 			RAW(4 | 8)  
	PID 			NUMBER  
	SOSID 			VARCHAR2(24)  
	SPID 			VARCHAR2(24)  
	STID 			VARCHAR2(24)  
	EXECUTION_TYPE 		VARCHAR2(10)  
	PNAME 			VARCHAR2(5)  
	USERNAME 		VARCHAR2(15)
	SERIAL#  	 	NUMBER  
	TERMINAL	 	VARCHAR2(30) 
	PROGRAM 	 	VARCHAR2(48) 
	TRACEID 	 	VARCHAR2(255) 
	TRACEFILE	 	VARCHAR2(513) 
	BACKGROUND	 	VARCHAR2(1) 1 
	LATCHWAIT 	 	VARCHAR2(16)  
	LATCHSPIN 	 	VARCHAR2(16)  
	PGA_USED_MEM 	 	NUMBER PGA  
	PGA_ALLOC_MEM 	 	NUMBER PGA  
	PGA_FREEABLE_MEM 	NUMBER  
	PGA_MAX_MEM 		NUMBER  
	CON_ID 			NUMBER 	



	SQL> desc DBA_HIST_SQLTEXT  
	Name                                      Null?    Type  
	----------------------------------------- -------- ----------------------------  
	DBID                                      NOT NULL NUMBER  
	SQL_ID                                    NOT NULL VARCHAR2(13)  
	SQL_TEXT                                           CLOB  
	COMMAND_TYPE                                       NUMBER  
	CON_DBID                                           NUMBER  
	CON_ID                                             NUMBER  
	

As you see, the CON_ID,

The ID of the container to which the data pertains. Possible values include:

0: This value is used for rows containing data that pertain to the entire CDB. This value is also used for rows in non-CDBs.
1: This value is used for rows containing data that pertain to only the root
n: Where n is the applicable container ID for the rows containing data

So we have to always filter the con_id when using v$session or v$process where con_id=container_id

-Thanks
Geek DBA

Administration : 12c Deprecated parameters

Here is the list of deprecated parameters as of 12.1.0.1

	SQL> SELECT name from v$parameter WHERE isdeprecated = 'TRUE' ORDER BY name;
	active_instance_count
	background_dump_dest
	buffer_pool_keep
	buffer_pool_recycle
	commit_write
	cursor_space_for_time
	fast_start_io_target
	global_context_pool_size
	instance_groups
	lock_name_space
	log_archive_local_first
	log_archive_start
	max_enabled_roles
	parallel_automatic_tuning
	parallel_io_cap_enabled
	parallel_server
	parallel_server_instances
	plsql_v2_compatibility
	remote_os_authent
	resource_manager_cpu_allocation
	sec_case_sensitive_logon
	serial_reuse
	sql_trace
	standby_archive_dest
	user_dump_dest

Administration : Restrict PGA using PGA_AGGREGATE_LIMIT

Until 12c we cannot restrict the PGA memory, even though you set pga_aggregate_target its just a soft limit, sessions can go beyond that.

However, we can restrict PGA using PGA_AGGREGATE_TARGET parameter and limiting the memory access, This is extremely useful in consolidated databases running on a host, but again the baseline should be done before setting this parameter. Even there is a default value for this parameter

PGA_AGGREGATE_LIMIT initialization parameter can be set dynamically; a database restart is not necessary. You can set the value of PGA_AGGREGATE_LIMIT regardless of whether automatic memory management is being used.

SQL> Alter system set pga_aggregate_limit = 5G;

If the PGA_AGGREGATE_LIMIT value is exceeded, Oracle Database aborts or terminates the sessions or processes that are consuming the most untunable PGA memory in the following order:

  • Calls for sessions that are consuming the most untunable PGA memory are aborted.
  • If PGA memory usage is still over the PGA_AGGREGATE_LIMIT, then the sessions and processes that are consuming the most untunable PGA memory are terminated.
  • In determining the sessions and processes to abort or terminate, Oracle Database treats parallel queries as a single unit.

  • Default Values
    PGA_AGGREGATE_LIMIT parameter is set to the greater of 2 GB, 200% of the PGA_AGGREGATE_TARGET value, or 3 MB times the value of the PROCESSES parameter. However, it will not exceed 120% of the physical memory size minus the total SGA size. The default value is printed into the alert log. A warning message is printed in the alert log if the amount of physical memory on the system cannot be determined

    -Thanks
    Geek DBA

  • Administration : Invisible Columns in 12c

    Starting 12c you can make columns invisible as like you make indexes invisible.

    The following actions can be applicable on invisible columns
    SELECT * FROM statements in SQL
    DESCRIBE commands in SQL*Plus
    %ROWTYPE attribute declarations in PL/SQL
    Describes in Oracle Call Interface (OCI)

    Few Notes:-

    When using select, when you dont select the invisible column in the list, it wont display that column
    When using select, When you select the invisible column in the list, it will display that column
    When using insert, if you specify the invisible column in the insert list it will insert the value
    When using insert, if you dont specify the invisible column in the insert list it will not insert the value indeed only visible columns will have insertions

    Restrictions:-
    External tables
    Cluster tables
    Temporary tables
    Attributes of user defined tables

    How you can make column invisible

    	SQL> CREATE TABLE mytable (a INT, b INT INVISIBLE, c INT);
    
    	SQL> Alter table mytable modify b invisible;
    
    	SQL> Alter table mytable modify b visible;
    

    Very Very Important Note

    Column order will be changed when you switch the columns between visible and invisible. Since the column number will not be stored for invisible columns

    For example:-

    SQL> CREATE TABLE mytable (a INT, b INT INVISIBLE, c INT);

    SQL> Select table_name,column_position from dba_tab_columns where table_name='MYTABLE';

    	TABLE_NAME	COLUMN_POSITION
    	----------	--------------
    	A		1
    	C		2
    	

    SQL> Alter table mytable modify b visible;

    The order of column now will be

    SQL> Select table_name,column_position from dba_tab_columns where table_name='MYTABLE';

    		TABLE_NAME	COLUMN_POSITION
    		----------	--------------
    		A		1
    		C		2
    		B		3
    		

    As you see the above the column though in the second list, the order moved to 3rd position, we need to be very careful if you hurrying to use this feature.

    Administration : THREADED_EXECUTION new param and new model for BG processes

    By default, some background processes on UNIX and Linux always use threaded execution; the remaining Oracle processes run as operating system processes. Thus, an "Oracle process" is not always equivalent to an "operating system process."

    Parameter THREADED_EXECUTION specifies whether to enable the multithreaded Oracle model. Starting in Oracle Database 12c, the multithreaded Oracle model enables Oracle processes on UNIX and Linux to run as operating system threads in separate address spaces.

    There is new column stid in v$process which provides the threads that spawned for the oracle process ID,

    Further you may also observed there are process LG00, LG01 which are lgwr threads works for PDB's if threaded execution set to true. However there are benefits and also some considerations which updated below.

    Source Jonathan Lewis Blog for this query and output

    	select
    	    spid, stid, program, background
    	from
    	    V$process
    	where
    	    spid != stid
    	and spid in (
    		select spid
    		from v$process
    		group by spid
    		having count(*) > 1
    	    )
    	order by
    	    spid, stid, program
    	;
    
    	SPID       STID       PROGRAM                        B
    	---------- ---------- ------------------------------ -
    	813        817        oracle@linux01 (GEN0)          1
    		   820        oracle@linux01 (MMAN)          1
    		   834        oracle@linux01 (DBRM)          1
    		   844        oracle@linux01 (LGWR)          1
    		   847        oracle@linux01 (CKPT)          1
    		   850        oracle@linux01 (LG00)          1
    		   853        oracle@linux01 (LG01)          1
    		   856        oracle@linux01 (SMON)          1
    		   862        oracle@linux01 (LREG)          1
    
    	827        1022       oracle@linux01
    		   1025       oracle@linux01 (QM02)          1
    		   1031       oracle@linux01 (Q002)          1
    		   1034       oracle@linux01 (Q003)          1
    		   831        oracle@linux01 (DIAG)          1
    		   837        oracle@linux01 (DIA0)          1
    		   859        oracle@linux01 (RECO)          1
    		   865        oracle@linux01 (MMON)          1
    		   868        oracle@linux01 (MMNL)          1
    		   871        oracle@linux01 (D000)
    		   874        oracle@linux01 (S000)
    		   877        oracle@linux01 (N000)
    		   898        oracle@linux01 (P000)
    		   901        oracle@linux01 (P001)
    		   904        oracle@linux01 (TMON)          1
    		   907        oracle@linux01 (TT00)          1
    		   910        oracle@linux01 (SMCO)          1
    		   913        oracle@linux01 (FBDA)          1
    		   916        oracle@linux01 (AQPC)          1
    

    Issues:-
    1) You cannot connect to database with sys / as sysdba, you will need to provide the password for sys connection

    2) when this initialization parameter is set to TRUE, the DEDICATED_THROUGH_BROKER_listener-name=ON parameter should be added to the listener.ora file, where listener-name is the name of the database listener. This enables the server to spawn threads when connections to the database are requested through the listener.

    Administration : Undo stores in Temporary tablespace?

    Yes for for Temporary Tables.

    Here is the excerpt from the documentation:-

    By default, undo records for temporary tables are stored in the undo tablespace and are logged in the redo, which is the same way undo is managed for persistent tables. However, you can use the TEMP_UNDO_ENABLED initialization parameter to separate undo for temporary tables from undo for persistent tables. When this parameter is set to TRUE, the undo for temporary tables is called temporary undo.

    Benefits

    	Temporary undo reduces the amount of undo stored in the undo tablespaces.
    
    	Less undo in the undo tablespaces can result in more realistic undo retention period requirements for undo records.
    	Temporary undo reduces the size of the redo log.
    
    	Performance is improved because less data is written to the redo log, and components that parse redo log records, such as LogMiner, perform better because there is less redo data to parse.
    
    	Temporary undo enables data manipulation language (DML) operations on temporary tables in a physical standby database with the Oracle Active Data Guard option. However, data definition language (DDL) operations that create temporary tables must be issued on the primary database.
    

    You can enable temporary undo for a specific session or for the whole system

    Set the TEMP_UNDO_ENABLED initialization parameter:

    	To enable temporary undo for a session, run the following SQL statement:
    	ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE;
    
    
    
    	To disable temporary undo for a session, run the following SQL statement:
    	ALTER SESSION SET TEMP_UNDO_ENABLED = FALSE;
    
    
    	To enable temporary undo for the system, run the following SQL statement:
    	ALTER SYSTEM SET TEMP_UNDO_ENABLED = TRUE;
    
    	After temporary undo is enabled for the system, a session can disable temporary undo using the ALTER SESSION statement.
    
    
    	To disable temporary undo for the system, run the following SQL statement:
    	ALTER SYSTEM SET TEMP_UNDO_ENABLED = FALSE;
    

    After temporary undo is disabled for the system, a session can enable temporary undo using the ALTER SESSION statement.

    Note: By default the temporary undo is enabled for dataguard

    Views:- V$TEMPUNDOSTAT,

    Administration : Hiding rows with ROW ARCHIVAL VISIBILITY

    An direct example from documentation with clear explanation

    In-Database Archiving enables you to archive rows within a table by marking them as inactive. These inactive rows are in the database and can be optimized using compression, but are not visible to an application. The data in these rows is available for compliance purposes if needed by setting a session parameter.

    With In-Database Archiving you can store more data for a longer period of time within a single database, without compromising application performance. Archived data can be compressed to help improve backup performance, and updates to archived data can be deferred during application upgrades to improve the performance of upgrades.

    To manage In-Database Archiving for a table, you must enable ROW ARCHIVAL for the table and manipulate the ORA_ARCHIVE_STATE hidden column of the table. Optionally, you specify either ACTIVE or ALL for the ROW ARCHIVAL VISIBILITY session parameter.

    	ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;
    
    	CREATE TABLE employees_indbarch 
    	 (employee_id NUMBER(6) NOT NULL, 
    	  first_name VARCHAR2(20), last_name VARCHAR2(25) NOT NULL, 
    	  email VARCHAR2(25) NOT NULL, phone_number VARCHAR2(20), 
    	  hire_date DATE NOT NULL, job_id VARCHAR2(10) NOT NULL, salary  NUMBER(8,2),
    	  commission_pct NUMBER(2,2), manager_id NUMBER(6), department_id NUMBER(4)) ROW ARCHIVAL;
    
    	INSERT INTO employees_indbarch(employee_id, first_name, last_name, email,
    	  hire_date, job_id, salary, manager_id, department_id) 
    	  VALUES (251, 'Scott', 'Tiger', 'scott.tiger@example.com', '21-MAY-2009',
    	 'IT_PROG', 50000, 103, 60);
    
    	INSERT INTO employees_indbarch(employee_id, first_name, last_name, email,
    	  hire_date, job_id, salary, manager_id, department_id) 
    	  VALUES (252, 'Jane', 'Lion', 'jane.lion@example.com', '11-JUN-2009', 
    	  'IT_PROG', 50000, 103, 60);
    
    	SELECT SUBSTR(COLUMN_NAME,1,22), SUBSTR(DATA_TYPE,1,20), COLUMN_ID AS COL_ID,
    	  SEGMENT_COLUMN_ID AS SEG_COL_ID, INTERNAL_COLUMN_ID AS INT_COL_ID, HIDDEN_COLUMN, CHAR_LENGTH
    	  FROM USER_TAB_COLS WHERE TABLE_NAME='EMPLOYEES_INDBARCH';
    
    	SELECT SUBSTR(COLUMN_NAME,1,22) NAME, SUBSTR(DATA_TYPE,1,20) DATA_TYPE, COLUMN_ID AS COL_ID,
    	  SEGMENT_COLUMN_ID AS SEG_COL_ID, INTERNAL_COLUMN_ID AS INT_COL_ID, HIDDEN_COLUMN, CHAR_LENGTH 
    	  FROM USER_TAB_COLS WHERE TABLE_NAME='EMPLOYEES_INDBARCH';
    
    	NAME                   DATA_TYPE                COL_ID SEG_COL_ID INT_COL_ID HID CHAR_LENGTH
    	---------------------- -------------------- ---------- ---------- ---------- --- -----------
    	ORA_ARCHIVE_STATE      VARCHAR2                                 1          1 YES        4000
    	EMPLOYEE_ID            NUMBER                        1          2          2 NO            0
    	FIRST_NAME             VARCHAR2                      2          3          3 NO           20
    	LAST_NAME              VARCHAR2                      3          4          4 NO           25
    	EMAIL                  VARCHAR2                      4          5          5 NO           25
    	PHONE_NUMBER           VARCHAR2                      5          6          6 NO           20
    	HIRE_DATE              DATE                          6          7          7 NO            0
    	JOB_ID                 VARCHAR2                      7          8          8 NO           10
    	SALARY                 NUMBER                        8          9          9 NO            0
    	COMMISSION_PCT         NUMBER                        9         10         10 NO            0
    	MANAGER_ID             NUMBER                       10         11         11 NO            0
    	DEPARTMENT_ID          NUMBER                       11         12         12 NO            0
    
    
    	COLUMN ORA_ARCHIVE_STATE FORMAT a18;
    	/* The default value for ORA_ARCHIVE_STATE is '0', which means active */
    
    	SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
    
    	EMPLOYEE_ID ORA_ARCHIVE_STATE
    	----------- ------------------
    		251 0
    		252 0
    
    	/* Update a value into ORA_ARCHIVE_STATE to set inactive , updating any value other than 0 makes the row visibility archival inactive*/
    
    	UPDATE employees_indbarch SET ORA_ARCHIVE_STATE = '20' WHERE employee_id = 252;
    
    	/* Only active records are in the following query, you see that 252 id is not visible since the visibility is not set to all */
    
    	SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
    
    	EMPLOYEE_ID ORA_ARCHIVE_STATE
    	----------- ------------------
    		251 0
    
    	/* Set visibility to ALL to display all records */
    
    	ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;
    
    	SELECT employee_id, ORA_ARCHIVE_STATE FROM employees_indbarch;
    
    	EMPLOYEE_ID ORA_ARCHIVE_STATE
    	----------- ------------------
    		251 0
    		252 20
    

    As you see the setting the row archival visibility to all displays all records. this is especially useful to filter out the historical data

    Administration : Enable DDL Logging

    In 12c you can enable DDL logging, before to that there was no way to know who has done the DDL on that object unless auditing enabled.

    The ENABLE_DDL_LOGGING initiation parameter must be configured in order to turn on this feature.

    The parameter can be set at the database or session levels.

    When this parameter is enabled, all DDL commands are logged in an xml and a log file under the $ORACLE_BASE/diag/rdbms/DBNAME/log|ddl location.

    An xml file contains information, such as DDL command, IP address, timestamp etc.

    This helps to identify when a user or table dropped or when a DDL statement is triggered.

    To enable DDL logging

    	SQL> ALTER SYSTEM|SESSION SET ENABLE_DDL_LOGGING=TRUE;
    

    The following DDL statements are likely to be recorded in the xml/log file:

    	CREATE|ALTER|DROP|TRUNCATE TABLE
    
    	DROP USER
    
    	CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE
    

    Security : Privilege Capture – Helps to Audit

    Privilege capture is a feature to track the privileges that is used for a user,
    This is very useful in auditing and show results of privileges has used during the capture period.

    In 12c the Separate user duties are as below

    SQL> select username from dba_users where username like '%SYS%';
    
     USERNAME
     ----------------------------------
     SYS  : Super user
     SYSKM : Key magament tasks
     SYSDG : Data Guard Managment
     SYSBACKUP : backup management
    

    There is a new DBMS api called , DBMS_PRIVILEGE_CAPTURE which is used to capture the privileges

    The Privilege Analysis feature allows you to:

    	Define a privilege capture
    	Start a privilege analysis during a period of time
    

    Delete capture analysis

    The Capture can be Done on Three level :

    	User
    	Role
    

    Context

    to understand this new package check the below examples :

    	sqlplus / as sysdba
    
    	SQL> create user Geek DBA identified  by Geek DBA ;
    
    	SQL> grant create session to Geek DBA ;
    
    	Grant succeeded.
    
    	SQL> grant select any table to Geek DBA ;
    
    	Grant succeeded.
    

    Create new Capture using this package :

    	exec SYS.DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE ( -
    		 name           =>  'Geek DBA_capture', -
    		description    =>  'Capture_all_thing', -
    		type           =>   dbms_privilege_capture.g_database)
    
    Where 
    
    	 Name : Package name
    	 Description : What this package fo
    	 type : depend on level users ( g_database ) , role (g_role )  , Context : (g_role_and_context)
    
    

    we need to enable this package to start capture :

    	 SQL> exec SYS.DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE (name => 'Geek DBA_capture');
    

    PL/SQL procedure successfully completed.

    Test:-

    	SQL> conn Geek DBA/Geek DBA ;
    	Connected.
    
    	SQL> select * from Geek DBA.Geek DBA ;
    	no rows selected
    
    	SQL> select * from Geek DBA.Geek DBA2 ;
    	   TEST_ID TEST_NAME
    	---------- --------------------
    	  1 KUMAR
    

    again reconnect as / as sysdba to disable capture then generate results like the following :

    
    	SQL> exec SYS.DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE (name => 'Geek DBA_capture');
    	PL/SQL procedure successfully completed.
    

    Generate the Result

    	SQL> exec SYS.DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT (name => 'Geek DBA_capture');
    	PL/SQL procedure successfully completed.
    

    View the Result

    	SQL> select username, object_owner, object_name, obj_priv  from   dba_used_objprivs
    	 where  username in ('OSAMA', 'TEST') 
    
    	USERNAME   OBJECT_OWNER OBJECT_NAME         OBJ_PRIV
    	---------- ------------ ------------------------------ -------------------------
    	TEST    SYS  ORA$BASE                     USE
    	TEST    SYS  DBMS_APPLICATION_INFO        EXECUTE
    	TEST    SYS  DUAL			  SELECT
    	TEST    SYS  DUAL                         SELECT
    	TEST    SYSTEM PRODUCT_PRIVS              SELECT
    

    Drop the Privilge Capture :

    	SQL> exec SYS.DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE (name => 'Geek DBA_capture')
    

    Administration: Change of Varchar2 to 32K

    Oracle has made a few changes to the database to allow organizations to reduce the cost of migrating to Oracle 12c.  One of these changes is with the size limits that have been placed on the VARCHAR2, NVARCHAR2 and RAW data types.  In past versions of Oracle database the maximum size for these data types were 4,000 bytes.  In Oracle 12c, these data types can now  be increased to 32,767 bytes.

    In order to set these data types to use the larger setting, the MAX_STRING_SIZE parameter needs to be set.  The only values that this parameter can take is STANDARD and EXTENDED.  Once the parameter has been set to EXTENDED, you cannot go back to STANDARD.

    Note: Altering MAX_STRING_SIZE will update database objects and possibly invalidate them

    To increase the size of the VARCHAR2, NVARCHAR2 and RAW columns for a non-CDB database,  these steps need to be followed:

                      1. Shutdown the database

                      2. Restart in UPGRADE mode

                      3. Change the setting of MAX_STRING_SIZE to EXTENDED

                      4. Run $OH/rdbms/admin/utl32k.sql  <- must be connected as SYSDBA

                      5. Restart in NORMAL mode.

    The same procedure can be followed and applied against an Oracle PDB, Oracle RAC database, Oracle Data Guard Logical Standby Databases.