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
|
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
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
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
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.
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.
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,
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
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
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')
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.
|
Follow Me!!!