I have changed the PGA and SGA in my system like below. after which we restarted the dB but the changes are not reflected.
This is a RAC DB and has 4 instances
scope=spfile
is there any problem?
SQL> alter system set sga_max_size=90g scope=spfile sid = 'OFSAA';
System altered.
SQL> alter system set sga_target=90g scope=spfile sid = 'OFSAA';
System altered.
SQL> alter system set pga_aggregate_target=90G scope =spfile sid='OFSAA';
System altered.
SQL> alter system set pga_aggregate_limit=50G scope =spfile sid='OFSAA';
This can happen if sid parameter is incorrectly specified.
Check it with this command:
select instance_name from v$instance;
Note that the sid parameter is case sensitive.
For example:
OFSAA != ofsaa
After changing the sizes of PGA SGA, The OS parameter may restrict the DB on the usage of 100% SGA. To validate this, please check the SGA PGA values from the AWR report.
Related
My query is the following :
ALTER TABLE EMPLOYEE MODIFY LOB(DOCUMENT) (SHRINK SPACE);
The parallel degree for the table is 1 :
SELECT DEGREE FROM USER_TABLES WHERE TABLE_NAME = 'EMPLOYEE';
Result : 1
Table EMPLOYEE is not partitioned.
If I launch the same query with a parallel degree, the system does not complain, but is it silently ignored ?
ALTER TABLE EMPLOYEE MODIFY LOB(DOCUMENT) (SHRINK SPACE) PARALLEL 8;
Any chance that the query will be faster ?
DDL operations will run in parallel when:
The degree of the table is not 1
OR
The session parallel ddl has been enabled by alter session enable parallel ddl
Anyway, you should always run the alter session enable parallel ddl before running any DDL operation that can run in parallel. Although the documentation did not say that shrink can run in parallel, the syntax is allowed, so I guess you can test whether it runs faster or not.
The parallel DDL statements for nonpartitioned tables and indexes are:
CREATE INDEX
CREATE TABLE AS SELECT
ALTER INDEX REBUILD
The parallel DDL statements for partitioned tables and indexes are:
CREATE INDEX
CREATE TABLE AS SELECT
ALTER TABLE {MOVE|SPLIT|COALESCE} PARTITION
ALTER INDEX {REBUILD|SPLIT} PARTITION
Example
SQL> create table t ( c1 clob ) ;
Table created.
SQL> alter table t MODIFY LOB(c1) (SHRINK SPACE) PARALLEL 8 ;
Table altered.
Instead of SHRINK you can always move the segment lob, which I can assure 100% will run in parallel and faster. The problem is that if you have indexes, there will become invalid.
UPDATE
To move the lob segment, you must do the following
Moving LOB:
SQL> spoolmovelob.sql
SET HEADING OFF
SET pagesize 200
SET linesize 200
select 'ALTER TABLE <owner>.'||TABLE_NAME||' MOVE LOB('||COLUMN_NAME||') STORE AS (TABLESPACE <Tablespace_name>) parallel 5 nologging;' from dba_lobs where TABLESPACE_NAME='<Tablespace_name>';
Note: The above query will include all the LOB,LOBSEGMENT,LOBINDEXES
Moving Table:
SQL> spool /home/oracle/moveTables.sql
SET HEADING OFF
SET PAGESIZE 200
SET LINESIZE 200
select ' ALTER TABLE <owner>.'||TABLE_NAME||' MOVE TABLESPACE <Tablespace_name>) parallel 5 nologging;' from dba_tables where owner='<owner name>';
Moving Indexes:
SQL> spool /home/oracle/moveIndex.sql
SET HEADING OFF
SET long 9999
SET linesize 200
select 'alter index <owner>.'||index_name||' from dba_indexes 'rebuild tablespace <Tablespace_name>) online parallel X nologging;' where owner='<owner>.';
Remember to replace X with the specific degree.
Did you enable parallel ddl?
alter session force parallel ddl parallel 8
Show us your session parameters:
select *
from v$ses_optimizer_env e
where e.sid=userenv('sid')
and (
name like '%parallel%'
or name like '%cpu%'
or name like '%optim%'
)
order by name
Accroding to the Oracle documentation
the ALTER TABLE MODIFY operation cannot be run in parallel.
If I launch the same query with a parallel degree, the system does not complain, but is it silently ignored ?
Depending on how your database in general and your specific seession are configured, it may be ignored.
Any chance that the query will be faster ?
This will very much depend on your specific dataset, your available system resources, and how you set up your parallelism. Pay attention to the parallel_degree_policy setting; it controls default behavior.
See the Oracle whitepaper, "Parallel Execution with Oracle Database" for a more complete understanding. In particular, read the section on "Controlling Parallel Execution" beginning on page 21.
I enabled auditing on my Oracle XE server via the following run by the sys user:
SQL> ALTER SYSTEM SET audit_sys_operations=true SCOPE=spfile;
SQL> ALTER SYSTEM SET audit_trail=XML,EXTENDED SCOPE=spfile;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP
When I run queries as the sys user, an xml file records the queries in the default location (e.g., /u01/app/oracle/admin/XE/adump/xe_ora_2339_1.xml). However, if I run a query as a different user (e.g., test_user), no updates occur in any of the files in the adump directory.
I've confirmed that the parameter is set for the test_user:
SQL> show parameter audit;
NAME TYPE VALUE
------------------------ ------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/XE/adump
audit_sys_operations boolean TRUE
audit_syslog_level string
audit_trail string XML, EXTENDED
I also tried restarting my sqlplus session (i.e., reconnecting with the test_user), as well as disabling audit_sys_operations, and the issue remains.
Version info: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production (via this docker image).
My issue was that, in addition to enabling auditing, I also needed to specify what to audit with the AUDIT command. In my case, I wanted everything, so I added the following (commands mentioned in this tutorial):
SQL> AUDIT ALL; # note: it seems like the next two statements would be included with "all", but I didn't verify this.
SQL> AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE;
SQL> AUDIT EXECUTE PROCEDURE;
Note that with AUDIT_TRAIL=XML,EXTENDED (and maybe all the file-based auditing settings?), it looks there is some buffering of writing the XML file, as I didn't get a query showing up until my test user disconnected, so if you are missing a log entry, try logging the user out to see if it shows up.
I was under the impression that when one uses the ALTER SYSTEM statement, the new setting is in effect as long as the instance is up / database is mounted:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm#SQLRF00902
After a reboot the setting should revert to its old value.
I have done the below change, shut down and started the instance back up and the new setting is still in effect. Any ideas?
SQL> show parameter SEC_CASE_SENSITIVE_LOGON
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon boolean TRUE
SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
System altered.
-------Restarted the database---------------------------
SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
System altered.
In that link you provided, you have to look for the SCOPE parameter. By default is Both, if you're using SPFILE (which is the most common), means it will save on the SPFILE and change in memory as well.
Hugepage and SGA change require reboot.
su - oracle
sqlplus / as sysdba
alter system set memory_max_target=11520m scope=spfile;
--assuming an spfile is used
alter system set memory_target=11520m scope=spfile;
--assuming an spfile is used
shutdown the DB
start the DB
I have a Oracle stored procedure that queries data through database link, sometimes it takes a while, and got Oracle error as below:
ORA-02399: exceeded maximum connect time, you are being logged of
Is there any way to reconnect the database link if it got disconnected?
Thank you for the help
If you have SYSDBA access you can give a try with increasing the CONNECT_TIME parameter in DEFAULT profile( You can also create your own profile and do the following. I am considering only default profile). See below steps:
SQL> conn / as sysdba
Connected.
SQL> alter profile default
2 limit connect_time 10 --10 refers to 10 minutes
3 /
Profile altered.
Set RESOURCE_LIMIT to TRUE so that limits would be enforced:
SQL> alter system set resource_limit = true
2 /
System altered.
SQL>
Then give DEFAULT profile to the user(Like Scott) you are using to connect Oracle Session.
SQL> alter user SCOTT profile DEFAULT;
User altered.
SQL> grant create session to SCOTT
2 /
Grant succeeded.
I want to activate an audit operation on a table or two in my oracle db,
and for that I need to set the audit parameters.
alter system set AUDIT_SYS_OPERATIONS=true scope=spfile;
alter system set AUDIT_TRAIL=db, extended scope=spfile;
But those parameters not realy changed becuase startup of DB is needed.
Is there a way to skip over the startup to apply those changes?
This is realy important DB in production Env, and startup is almost-impossible.
Thank you.
If you just want to enable auditing on a selected objects then you can do it without bouncing your database instance. Audit trail is set to DB by default.
SQL> show parameter audit
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/orcl/adu
mp
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string DB
All you need to do is to enable required auditing on that object.
SQL> conn jay
Enter password:
Connected.
SQL> audit select on my_table;
Audit succeeded.
SQL> conn system
Enter password:
Connected.
SQL> select * from jay.my_table;
no rows selected
Audit information can be accessed from USER_AUDIT_OBJECT view.
SQL> conn jay
Enter password:
Connected.
SQL> select username, action_name from user_audit_object where obj_name='MY_TABLE';
USERNAME ACTION_NAME
------------------------------ ----------------------------
SYSTEM SESSION REC
However, if you need to enable auditing for sysdba/sysoper privileged users such as sys then you need to set audit_sys_operations parameter to true which in turn requires database shutdown.
Moreover, if you are using Oracle 12c then AUDIT_SYS_OPERATIONS is set to true by default.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> show parameter audit
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/orcl/adump
audit_sys_operations boolean TRUE
audit_syslog_level string
audit_trail string DB
you cant use it with no startup
look this (Auditing Administrative Users)