|
|
The CONNECT role in Oracle 10g has fewer system privileges than it had in earlier versions of Oracle. When migrating databases from versions below Oracle 10g and especially if the users are recreated in the 10g databases with the privileges from the old version, certain privileges are required to be granted so that the application users can connect to the database with proper privileges. This article discusses this special case on the occurrence of ORA-01031 error in Oracle 10g databases.
The ‘CONNECT’ role in Oracle 10g has only ‘CREATE SESSION’ privilege, whereas the previous version had some additional privileges. If the privileges are missing, the user won’t be able to create objects which will result in ‘ORA-01031 insufficient privileges’ messages to the user.
To fix the issue, grant the 8 privileges listed below to the users.
In Oracle 9i, the CONNECT role had the following privileges:
SQL> select * from dba_sys_privs where grantee='CONNECT';
GRANTEE PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
CONNECT CREATE VIEW NO
CONNECT CREATE TABLE NO
CONNECT ALTER SESSION NO
CONNECT CREATE CLUSTER NO
CONNECT CREATE SESSION NO
CONNECT CREATE SYNONYM NO
CONNECT CREATE SEQUENCE NO
CONNECT CREATE DATABASE LINK NO
8 rows selected.
In Oracle 10g, only the ‘CREATE SESSION’ privilege is granted to the CONNECT ROLE.
SQL> select * from dba_sys_privs where grantee='CONNECT';
GRANTEE PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
CONNECT CREATE SESSION NO
SQL>
Oracle export utility when used to export from a lower version of database may not work due to compatibility issues as the export utility expects a set of views that are not present in the database. Even patchset difference between the exp utility and the database can lead to similar issues.
The best bet to deal with the issue is to use the lowest version available at the source/target database.
If you are using Oracle client, opt for the lowest version available for taking the export.
The errors differ based on the version difference between exp utility and the database, the following errors are possible:
9i client against lower versions of 9i database or 10g clients against 9.2.0.4 database can cause the following messages in the export log:
EXP-00056 Oracle error 942 encountered
ORA-00942 table or view does not exist
EXP-00000 Export terminated unsuccessfully
On some 9i R2 versions, the error may be reported as below:
EXP-00008: ORACLE error 942 encountered
ORA-00942: table or view does not exist
EXP-00024: Export views not installed, please notify your DBA
EXP-00000: Export terminated unsuccessfully
9.2.0.6 export client against a 9.2.0.5 can cause the following messages in the export log during the export of partitioned tables.
EXP-00056: ORACLE error 6550 encountered
ORA-06550: line 1, column 48:
PLS-00302: component ‘CHECK_MATCH_TEMPLATE’ must be declared
ORA-06550: line 1, column 14:
PL/SQL: Statement ignored
10.2.0.4 client against a 10.2.0.3 database can cause the following messages in the export log during the export of operators.
. exporting operators
EXP-00008: ORACLE error 904 encountered
ORA-00904: “OLEVEL”: invalid identifier
EXP-00000: Export terminated unsuccessfully
Oracle provides a procedure to insert messages to the alert log and/or trace files for testing/development purposes. This can be used to check the effectiveness of the monitoring tools/scripts used in the environment, to understand how well the monitoring tool captures the messages in the alert log.
Usage:
SQL> exec dbms_system.ksdwrt(1, 'This message goes to trace file in the udump location');
PL/SQL procedure successfully completed.
SQL> exec dbms_system.ksdwrt(2, 'This message goes to the alert log');
PL/SQL procedure successfully completed.
SQL> exec dbms_system.ksdwrt(3, 'This message goes to the alert log and trace file in the udump location');
PL/SQL procedure successfully completed.
SQL>
To test whether your monitoring tool captures error messages such as an ORA-00600, try executing the below:
SQL> exec dbms_system.ksdwrt(2, 'ORA-00600: Testing monitoring tool');
PL/SQL procedure successfully completed.
SQL>
Setting this parameter to a specified timestamp will make the time constant for the database engine (the clock will not tick) FIXED_DATE is a dynamic parameter and can be changed using the ALTER SYSTEM command.
SQL> ALTER SYSTEM SET FIXED_DATE='2009-09-22-13:00:00';
Once you set parameter, the value will be returned when ’sysdate()’ is used in the queries/application.
To see the server time, you can use systimestamp.
Eg:
SQL> set lines 100
SQL> select sysdate, systimestamp from dual;
SYSDATE SYSTIMESTAMP
------- -------------------------
2009 09 22 13:00:00 10-DEC-09 03.01.41.142940 AM -06:00
This is usually used for testing/development purposes, when the application logic depends on a specific date/time combination.
To set the date back to the ’system’ clock, set the parameter to ‘none’
SQL> alter system set fixed_date='none';
The below query helps to identify the session that has locked the resource that your session is trying to lock.
You can try executing the query/job after some time (to allow the other session to complete) or kill the session that has locked the resource to proceed with this situation, use the below query to identify the session.
set linesize 140
set pages 100
col username format a20
col "SID,SESSION#" format a20
col sess_id format a10
col object format a30
col mode_held format a10
select oracle_username || ' (' || s.osuser || ')' username
, s.sid || ',' || s.serial# "SID,SESSION#"
, owner || '.' || object_name object
, object_type
, decode( l.block
, 0, 'Not Blocking'
, 1, 'Blocking'
, 2, 'Global') status
, decode(v.locked_mode
, 0, 'None'
, 1, 'Null'
, 2, 'Row-S (SS)'
, 3, 'Row-X (SX)'
, 4, 'Share'
, 5, 'S/Row-X (SSX)'
, 6, 'Exclusive', TO_CHAR(lmode)) mode_held
from v$locked_object v
, dba_objects d
, v$lock l
, v$session s
where v.object_id = d.object_id
and v.object_id = l.id1
and v.session_id = s.sid
order by oracle_username,session_id;
Sample output:
USERNAME SID,SESSION# OBJECT OBJECT_TYPE STATUS MODE_HELD
-------- ------------ ------------- ----------- ------ ---------
SCOTT (oracle) 86,30 SCOTT.LOCK_TEST TABLE Not Blocking Row-X (SX)
To kill the locking session, do as below:
SQL> alter system kill session '86,30';
To identify the locked rows, use the below query:
set lines 200
col object_name for a30
select do.object_name
, row_wait_obj#
, row_wait_file#
, row_wait_block#
, row_wait_row#
, dbms_rowid.rowid_create (1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#,
ROW_WAIT_BLOCK#, ROW_WAIT_ROW#) ROW_ID
from v$session s
, dba_objects do
where s.ROW_WAIT_OBJ# = do.OBJECT_ID
and do.object_name=upper('<object_name_from_above_query>')
;
OBJECT_NAME ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW# ROW_ID
----------- ------------- -------------- --------------- ------------- ------
LOCK_TEST 41862 4 70 0 AAAKOGAAEAAAABGAAA
To simulate the occurrence of this error for testing/learning purposes, do as below in 2 sessions:
Session 1:
SQL> conn scott/tiger;
Connected.
SQL> create table lock_test (x number);
Table created.
SQL> insert into lock_test values(100);
1 row created.
SQL> commit;
Commit complete.
SQL> update lock_test set x=500;
1 row updated.
-- Do not commit.
Session 2:
SQL> conn scott/tiger;
Connected.
declare
y number;
begin
select x into y from lock_test for update nowait;
end;
/
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
ORA-06512: at line 4
In scenarios where there is no disk space to hold the export dumps or when migrating schemas across different versions of Oracle, this script helps to do the export/import over the network or on the same server using the Unix pipe.
In this example, data is exported from the Oracle Database instance named PROD to the instance named DEV. The export utility connects to the PROD database using the Net Service name, writes the export dump to a Unix pipe, which is read by the import process that loads the data to the DEV database.
Create a file exp_imp.sh:
#!/usr/bin/ksh
export ORACLE_SID=DEV
export ORACLE_HOME=/oracle/product/10204
# make a unix pipe
export PIPE=exp_imp_pipe
mknod exp_imp_pipe p
# Start the Export and run it in background - Dont omit the '&' at the end.
exp scott/tiger@PROD file=exp_imp_pipe log=exp_PROD.log buffer=1024000 consistent=y OWNER=HR,APP direct=y statistics=none compress=n &
# Start the Import
imp scott/tiger ignore=y full=y file=exp_imp_pipe log=imp_DEV.log commit=y buffer=1024000 RESUMABLE=Y &
For big schemas, CONSISTENT=Y may not work as the export may fail with an ORA-01555 snapshot too old error, so you may need to revist the parameter. RESUMABLE=Y at the import side can help to make the session ‘resumable’ in case the import hits any space issues on the target database. The export/import logs can be monitored to view the progress of the activity.
In this example the user scott has enough privilege to exp/imp the data, make sure that you connect to the databases as a privileged user and needless to say, it is recommended to run the job in nohup mode to avoid issues in case connectivity to the server gets disturbed.
One of the most used script used by the DBA in day-to-day work, this script gives the space usage of each tablespace in the database.
set heading on
set pagesize 500
set lines 400
column tablespace format a30 heading "Tablespace"
column avail format 9,999,999,999,999 heading "MB Avail."
column used format 9,999,999,999,999 heading "MB Used"
column free format 9,999,999,999,999 heading "MB Free"
column pct format 999 heading "Pct"
compute sum of avail used free on report
break on report
select a.tablespace_name "Tablespace",
a.avail,
a.avail-b.free used,
b.free,
round(nvl((a.avail-b.free)/a.avail*100,0)) "Pct"
from
(select tablespace_name, round(sum(bytes)/1048576) avail
from sys.dba_data_files
group by tablespace_name
UNION
select tablespace_name,round(sum(bytes_free+bytes_used)/1048576)
from v$temp_space_header
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes)/1048576) free
from sys.dba_free_space
group by tablespace_name
UNION
select tablespace_name,round(sum(bytes_free)/1048576)
from v$temp_space_header
group by tablespace_name) b
where a.tablespace_name = b.tablespace_name (+);
The below query comes handy to understand the archivelog generation of an Oracle database on an hourly /daily basis, per thread – in case of RAC databases.
Archivelog generation on a daily basis:
set pages 1000
select trunc(COMPLETION_TIME,'DD') Day, thread#, round(sum(BLOCKS*BLOCK_SIZE)/1048576) MB,count(*) Archives_Generated from v$archived_log
group by trunc(COMPLETION_TIME,'DD'),thread# order by 1;
Archive log generation on an hourly basis:
set pages 1000
select trunc(COMPLETION_TIME,'HH') Hour,thread# , round(sum(BLOCKS*BLOCK_SIZE)/1048576) MB,count(*) Archives from v$archived_log
group by trunc(COMPLETION_TIME,'HH'),thread# order by 1 ;
Sample output:
HOUR THREAD# MB ARCHIVES
------------------- ---------- ---------- ----------
2009 08 20 12:00:00 1 31268 339
2009 08 20 13:00:00 1 4994 55
2009 08 20 14:00:00 1 4412 48
2009 08 20 15:00:00 1 4805 52
2009 08 20 16:00:00 1 3364 37
2009 08 20 17:00:00 1 22 1
2009 08 20 21:00:00 1 9 1
Also, the following script is useful to find the archivelog switches on an hourly basis that happened in the past one week, I got this from http://kubilaykara.blogspot.com/2008/02/redo-log-generation.html and is quite an useful one.
SELECT to_date(first_time) DAY,
to_char(sum(decode(to_char(first_time,'HH24'),'00',1,0)),'99') "00",
to_char(sum(decode(to_char(first_time,'HH24'),'01',1,0)),'99') "01",
to_char(sum(decode(to_char(first_time,'HH24'),'02',1,0)),'99') "02",
to_char(sum(decode(to_char(first_time,'HH24'),'03',1,0)),'99') "03",
to_char(sum(decode(to_char(first_time,'HH24'),'04',1,0)),'99') "04",
to_char(sum(decode(to_char(first_time,'HH24'),'05',1,0)),'99') "05",
to_char(sum(decode(to_char(first_time,'HH24'),'06',1,0)),'99') "06",
to_char(sum(decode(to_char(first_time,'HH24'),'07',1,0)),'99') "07",
to_char(sum(decode(to_char(first_time,'HH24'),'08',1,0)),'99') "08",
to_char(sum(decode(to_char(first_time,'HH24'),'09',1,0)),'99') "09",
to_char(sum(decode(to_char(first_time,'HH24'),'10',1,0)),'99') "10",
to_char(sum(decode(to_char(first_time,'HH24'),'11',1,0)),'99') "11",
to_char(sum(decode(to_char(first_time,'HH24'),'12',1,0)),'99') "12",
to_char(sum(decode(to_char(first_time,'HH24'),'13',1,0)),'99') "13",
to_char(sum(decode(to_char(first_time,'HH24'),'14',1,0)),'99') "14",
to_char(sum(decode(to_char(first_time,'HH24'),'15',1,0)),'99') "15",
to_char(sum(decode(to_char(first_time,'HH24'),'16',1,0)),'99') "16",
to_char(sum(decode(to_char(first_time,'HH24'),'17',1,0)),'99') "17",
to_char(sum(decode(to_char(first_time,'HH24'),'18',1,0)),'99') "18",
to_char(sum(decode(to_char(first_time,'HH24'),'19',1,0)),'99') "19",
to_char(sum(decode(to_char(first_time,'HH24'),'20',1,0)),'99') "20",
to_char(sum(decode(to_char(first_time,'HH24'),'21',1,0)),'99') "21",
to_char(sum(decode(to_char(first_time,'HH24'),'22',1,0)),'99') "22",
to_char(sum(decode(to_char(first_time,'HH24'),'23',1,0)),'99') "23"
from
v$log_history
where to_date(first_time) > sysdate -8
GROUP by
to_char(first_time,'YYYY-MON-DD'), to_date(first_time)
order by to_date(first_time)
/
Sample output:
DAY 00 01 02 03 04 05 06 09 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
--------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- -
01-NOV-09 0 1 1 0 1 0 1 0 1 4 1 1 0 1 0 1 1 0 1 1 1 1 1 1
02-NOV-09 0 1 1 1 1 0 1 1 1 1 0 1 1 7 1 1 1 1 1 2 1 1 1 1
03-NOV-09 1 2 2 1 1 1 1 1 1 1 1 2 1 1 1 1 1 2 1 1 2 1 1 2
04-NOV-09 1 1 8 1 7 2 1 1 1 2 1 1 2 1 2 1 2 1 2 1 2 1 2 2
05-NOV-09 2 1 2 1 2 2 1 2 1 2 2 1 2 2 1 2 2 2 1 2 2 2 2 2
06-NOV-09 2 1 2 2 2 2 1 2 2 2 2 2 1 2 2 1 0 2 0 0 0 0 1 0
09-NOV-09 0 0 1 7 0 0 1 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0
Quick reference to dataguard configuration for the DBAs. The table gives an easy reference on the main attributes of log_archive_dest_n parameter and gives quick concept on the setting. Also, the scenarios where standby redo logs are used to minimize data loss and also to enable real-time apply is discussed.
| Configuration |
Performance |
Availability |
Protection |
Meaning and Remarks |
| Standby redo logs |
Not required, but recommended |
Required |
Required |
Redo data from primary will be written to standby redo logs by LGWR process and real time apply can be enabled, LGWR/ARCH parameter can be set. |
LGWR
(Redo archival process) |
Not required |
Required |
Required |
Specifies the redo transport service uses LGWR to collect and transit redo data to standby. |
ARCH
(Redo archival process) |
Possible |
Not possible |
Not possible |
Specifies that redo transport services uses ARCn process to collect and transmit redo data to standby. |
| SYNC (Network transmission) |
Not required |
Required |
Required |
SYNC specifies Network I/O to standby is synchronous, that means the LGWR process on primary will wait for Network I/O to complete on the standby so that successful transfer of redo records to standby database is ensured. |
| ASYNC (Network transmission) |
Can be set |
Cannot be set |
Cannot be set |
ASYNC specifies the the LGWR will not wait for Network I/O to complete and proceeds asynchronously. Not valid if ARCH parameter is used |
AFFIRM
(Disk Writes) |
Not required |
Required |
Required |
Specifies that disk I/O to archived redo logs and standby redo logs on the standby are done synchronously and the LGWR process on primary will wait to continue its processing. |
| NOAFFIRM (Disk Writes) |
Can be set |
Cannot be set |
Cannot be set |
Specifies that disk I/O to archived redo logs and standby redo logs on the standby is done asynchronously and the LGWR process on primary will not wait to continue its processing. |
Step by Step
1) Activate Force logging on the primary database
In case of unlogged writes to primary database (NOLOGGING and DIRECT LOAD operations using SQL*Loader), redo data is not generated. As the redo required to synch the changes to the standby is not generated, the standby database will not be consistent with the primary. To prevent such issues, the primary database is forced to log operations. It may also be noted that it is recommended to take a backup of the database after UNRECOVERABLE/NOLOGGING operations as those operations are not recoverable as the redo data is not generated.Use the below command on the primary database to force logging on the database.
SQL> alter database force logging;
This must be done before building the standby database.
2) Prepare Initialization files for the primary and standby databases
# Initialization file for primary database – initorcl.ora
*.audit_file_dest='/oracle/app/oracle/admin/orcl/adump'
*.audit_trail='db'
*.compatible='11.1.0.0.0'
*.control_files='/oradata/orcl/control01.ctl','/oradata/orcl/control02.ctl'
,'/oradata/orcl/control03.ctl'
*.db_block_size=8192
*.db_name='orcl'
*.diagnostic_dest='/oracle/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.log_archive_dest_1='LOCATION=/oradata/arch/orcl/'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=104857600
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=316669952
*.undo_tablespace='UNDOTBS1'
##### Standby related parameters ########
*.db_unique_name='orcl'
*.fal_client='ORCL'
*.fal_server='STBY'
*.DB_FILE_NAME_CONVERT=('/oradata/stby/','/oradata/orcl/')
*.LOG_FILE_NAME_CONVERT=('/oradata/stby/','/oradata/orcl/') *.log_archive_config='dg_config=(orcl,stby)'
*.log_archive_dest_2='SERVICE=STBY valid_for=online_logfiles,primary_role)'
*.db_unique_name='STBY'
*.log_archive_dest_state_2=enable
*.standby_file_management=auto
##### End Standby related parameters #######
# Initialization file for standby database - initstby.ora
*.audit_file_dest='/oracle/app/oracle/admin/stby/adump'
*.audit_trail='db'
*.compatible='11.1.0.0.0'
*.control_files='/oradata/stby/control01.ctl','/oradata/stby/control02.ctl',
'/oradata/stby/control03.ctl'
*.db_block_size=8192
*.db_name='orcl'
*.diagnostic_dest='/oracle/app/oracle'
*.dispatchers='(PROTOCOL=TCP)(SERVICE=orclXDB)'
*.log_archive_dest_1='LOCATION=/oradata/arch/stby/'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=104857600
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=316669952
*.undo_tablespace='UNDOTBS1'
##### Standby related parameters#######
*.db_unique_name='stby'
*.log_archive_dest_2='SERVICE=ORCL valid_for=(online_logfile,primary_role)
*.DB_FILE_NAME_CONVERT=('/oradata/orcl/','/oradata/stby/')
*.LOG_FILE_NAME_CONVERT=('/oradata/orcl/','/oradata/stby/')
*.fal_server='ORCL'
*.fal_client='STBY'
*.log_archive_config='dg_config=(orcl,stby)'
*.standby_file_management=auto
##### End Standby related parameters #######
3) Configure Listener for Static service registration
Static service registrations is requierd for the RMAN active database duplication to work.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = dbapundits)(PORT = 1521)))) SID_LIST_LISTENER =
(
SID_LIST =
(SID_DESC = (ORACLE_HOME = /oracle/app/oracle/product/11.1.0) (SID_NAME = orcl))
(SID_DESC = (ORACLE_HOME = /oracle/app/oracle/product/11.1.0) (SID_NAME = stby))
)
4) Create service names in tnsnames.ora
Add tnsnames.ora entries for primary and standby databases.
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbapundits)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)))
STBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbapundits)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stby)))
5) Create password file for the standby database
The easiest way to do this is to copy the password file from the primary database and to rename it in proper format on the standby server.
$ pwd
/oracle/app/oracle/product/11.1.0/dbs
$ cp orapworcl orapwstby
6) Perform Oracle 11g standby creation using RMAN DUPLICATE command
run
{
duplicate target database for standby dorecover from active database;
}
The primary database is duplicated as a standby database on the target server (or on same server in this case) using the datafiles from the active database. There is no need of a backup and the datafiles are copied over the network to the target server and is recovered to the point when the duplication was fired.
7) Logs
11g-standby-database-creation-with-rman-duplicate-command – log
|
|