oracle

11gR2:What if Oracle gives you Kernel parameter fixup script

11gR2 database installation comes up with new  feature known as Installation Fixup scripts which aids you during Installation phase.  If a pre-requisite check fails, then it provides a click and generate fixup script option and then points you to script location which then need’s to be executed  with root permission. As per doc’s , it takes care of following things

– Checks and sets kernel parameters to values required for successful installation, including:Shared memory parameters,Semaphore parameters and Open file descriptor and UDP send/receive parameters

– Sets permissions on the Oracle Inventory directory.

– Reconfigures primary and secondary group memberships for the installation owner, if necessary, for the Oracle Inventory directory, and for the operating system privileges groups.

– Sets up virtual IP and private IP addresses in /etc/hosts.

– Sets shell limits to required values, if necessary.

– Installs the Cluster Verification Utility packages (cvuqdisk rpm).

Below are screenshot for error’s encountered as a result of missing kernel settings in sysctl.conf file

11g_install_fixup1

11g_install_fixup2

Below is output of running the script as root

cat orarun.log
This is the log file for orarun script
Timestamp: 090109150435
Response file being used is :/tmp/CVU_11.2.0.1.0_oracle/fixup.response
Enable file being used is :/tmp/CVU_11.2.0.1.0_oracle/fixup.enable
Setting Kernel Parameters...
file-max in response file:6815744
file-max in /etc/sysctl.conf:6815744
The value for file-max in response file is not greater than value for file-max in /etc/sysctl.conf file. Hence not changing it.
file-max for current session:6553600
ip_local_port_range in response file:9000 65500
ip_local_port_range in /etc/sysctl.conf:9000 65000
ip_local_port_range for current session:1024 65000
aio-max-nr in response file:1048576
aio-max-nr in /etc/sysctl.conf:1048576
The value for aio-max-nr in response file is not greater than value for aio-max-nr in /etc/sysctl.conf file. Hence not changing it.
aio-max-nr for current session:65536

Before running the script, I had modified the file without executing sysctl -p to implement the changes.  Fixup script log  shows that it checks the file again and replaces parameter if required and then executes sysctl command to  make changes persistent.

Oracle 11gR2 on linux is out

Oracle 11gR2 has been released for linux x86 and x86-64 platform. Software can be downloaded at http://www.oracle.com/technology/software/products/database/index.html

Guys start downloading..:) ..

Note: – As of now documentation link  is not available on http://tahiti.oracle.com (13:30 G.M.T)

Update : – Thanks to H.Tonguç , documentation can be accesed at http://www.oracle.com/pls/db112/homepage?remark=tahiti

Cheers
Amit

OCFS2 Configuration Issue

While setting up ocfs2 for OCR and Voting disk storage with following commad:
# ocfs2console

After clicking on ==>cluster ==> configure nodes, I got a pop-up saying:

<span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">"Could not start cluster stack. This must be resolved before any OCFS2 filesystem can be mounted."</span></span>

Soon I realized that the thing which takes few minutes to get installed, is going to give me a tough time.

/var/log/messages shows following details:

<span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">Aug 17 14:53:40 rac1 modprobe: FATAL: Module configfs not found.
Aug 17 14:55:23 rac1 modprobe: FATAL: Module configfs not found.
Aug 17 14:56:56 rac1 modprobe: FATAL: Module configfs not found.
</span></span>

This prevents the configuration of OCFS2’s cluster stack, but it is mandatory to have OCFS2 cluster stack “O2CB” running, before
we can start anything with OCFS2 filesystem.

The stack includes the following services:

<span style="font-size: small;"><span style="font-family: arial,helvetica,sans-serif;">    * NM: Node Manager that keep track of all the nodes in the cluster.conf
    * HB: Heart beat service that issues up/down notifications when nodes join or leave the cluster
    * TCP: Handles communication between the nodes
    * DLM: Distributed lock manager that keeps track of all locks, its owners and status
    * CONFIGFS: User space driven configuration file system mounted at /config
    * DLMFS: User space interface to the kernel space DLM
</span></span>

Error : modprobe: FATAL: Module configfs not found” can occur because of following reasons:

1. SELINUX is enabled.
2. Mismatch between the Kernel and OCFS2 module.

1. To check for selinux:
# sestatus
Or
# vi /etc/sysconfig/selinux

Make sure that selinux is DISABLED here.

2. To check for Mismatch:
# uname -a (It will give the exact kernel version of the OS)
2.6.9-42.ELsmp
# rpm -qa |grep ocfs2 (It will tell us the ocfs2 package currently installed)
ocfs2-2.6.9-89.EL

Here it can be seen that ocfs2 is for kernel version 89 not for kernel version 42.

So I downloaded the correct OCFS2 kernel modules from:
http://oss.oracle.com/projects/ocfs2/files/
and the tools from
http://oss.oracle.com/projects/ocfs2-tools/files/

After installing the correct module and disabling the selinux settings, I got the cluster stack running.


GATHER_STATS_JOB – Is it enabled?

Few days back , Martin had posted a series of post on a issue where GATHER_STATS_JOB was failing silently for a large object. If you have missed it, you can check following links

Automated statistics gathering silently fails http://mwidlake.wordpress.com/2009/07/20/automated-statistics-gathering-silently-fails/
Automated Statistics Gathering Silently Fails #2 http://mwidlake.wordpress.com/2009/07/23/automated-statistics-gathering-silently-fails-2/
Automatic Statistics Gathering Fails #3   http://mwidlake.wordpress.com/2009/07/29/automatic-statistics-gathering-fails-3/

Automated statistics gathering silently fails

Automated Statistics Gathering Silently Fails #2

Automatic Statistics Gathering Fails #3

This post is based on some of the discussions on the thread. Please note that this is not intended to discuss bugs (if any) associated with the job

Gather_stats_job was introduced with Oracle 10g to gather statistics for database objects which has stale statistics (10% of data has changed, you can query dba_tab_modifications) or the tables for which the statistics has not been gathered (new tables created/truncated). This job runs during the maintenance window i.e every night from 10 P.M. to 6 A.M. and all day on weekends. This schedule can be though changed and process is documented in Metalink aka My Oracle Support Note 579007.1 –

This feature brought relief to lot of DBA’s as they did not have to write shell scripts to gather stats and could rely on this job to do the work. But slowly people realized that it does not fit in their environment and slowly recommendation turned from “Enabled ” to “Disabled “

Issues/Misconceptions

1) Should I schedule job run for every night?

As documented this job gathers stats on the tables which have got 10% of data changes since last run. So this will not touch the tables for which the data changes are less then 10%. Also due to rolling invalidation feature , sql cursors will not be immediately invalidated (Refer to oracle forums discussion and Fairlie Rego’s post)

If you are still not happy , you can change the maintenance window timings to suit the schedule (say on weekends)

In 11g, there is no GATHER_STATS_JOB. It has been now incorporated into DBMS_AUTO_TASK_ADMIN job along with Automatic segment advisor and Automatic tuning advisor. All these 3 run in all maintenance windows. New maintenance windows introduced with 11g are
You can check the name and state of this job using following query

SQL> SELECT client_name, status FROM dba_autotask_operation;

CLIENT_NAME							 STATUS
---------------------------------------------------------------- --------
auto optimizer stats collection 				 ENABLED
auto space advisor						 ENABLED
sql tuning advisor						 ENABLED

Window – Description

MONDAY_WINDOW – Starts at 10 p.m. on Monday and ends at 2 a.m.
TUESDAY_WINDOW – Starts at 10 p.m. on Tuesday and ends at 2 a.m.
WEDNESDAY_WINDOW -Starts at 10 p.m. on Wednesday and ends at 2 a.m.
THURSDAY_WINDOW – Starts at 10 p.m. on Thursday and ends at 2 a.m.
FRIDAY_WINDOW -Starts at 10 p.m. on Friday and ends at 2 a.m.
SATURDAY_WINDOW – Starts at 6 a.m. on Saturday and is 20 hours long.
SUNDAY_WINDOW -Starts at 6 a.m. on Sunday and is 20 hours long.

To enable the job (in case it is disabled)

BEGIN
  DBMS_AUTO_TASK_ADMIN.ENABLE(
    client_name => 'auto optimizer stats collection',
    operation => NULL,
    window_name => NULL);
END;
/

You can check history/run duration of these jobs by using following query

select client_name,JOB_NAME,JOB_STATUS,JOB_START_TIME,JOB_DURATION from DBA_AUTOTASK_JOB_HISTORY where JOB_START_TIME >systimestamp -7 and client_name='sql tuning advisor'

CLIENT_NAME		       JOB_NAME 		      JOB_STATUS      JOB_START_TIME					 JOB_DURATION
------------------------------ ------------------------------ --------------- -------------------------------------------------- --------------------
sql tuning advisor	       ORA$AT_SQ_SQL_SW_521	      SUCCEEDED       30-MAR-12 04.00.01.698038 PM AMERICA/LOS_ANGELES	 +000 00:22:13
sql tuning advisor	       ORA$AT_SQ_SQL_SW_493	      SUCCEEDED       01-APR-12 04.00.02.701398 PM AMERICA/LOS_ANGELES	 +000 00:42:26
sql tuning advisor	       ORA$AT_SQ_SQL_SW_522	      SUCCEEDED       31-MAR-12 04.00.07.642613 PM AMERICA/LOS_ANGELES	 +000 00:00:37

2) I do not want gather_stats_job to gather stats on some of my tables.

This requirement can arise due to following points

a)There are tables for which you have set the stats manually
b) There are queries for which you know your old stats will work fine
c) Tables are big and gather_stats_job is silently failing ( Again refer to Martin’s Post)
d) Tables for which histograms cannot not be gathered or vice versa
e) Tables for which you would like to estimate fixed percent of blocks

For all these situations. you can use DBMS_STATS.LOCK_TABLE_STATS and gather stats manually with force =>true to override locked statistics. For big partitioned tables you can use COPY_TABLE_STATS and APPROX_GLOBAL AND PARTITION feature. 

Oracle 11g also has enhancement to gathering stats on partitioned tables where in you can gather INCREMENTAL stats for partitions and oracle will automatically update global stats for table.This approach has advantage as we don’t scan table twice and reduces the time to gather stats drastically. You need to use DBMS_STATS.set_table_prefs procedure to set Incremental stats gathering to true. 

EXEC DBMS_STATS.SET_TABLE_PREFS('SCOTT','EMP_PART','INCREMENTAL','TRUE');

Note that first time, stats gathering will take more time as oracle will create object called synposes for each paritition. Subsequent runs of gather_stats_job will be faster. Refer to Optimizer group post for more info on copy_table_stats and 11g incremental stats feature. ( Due to bug copy_table_stats does not alter low/high value. Details can be found here )

To fix histogram issue, DBMS_STATS.SET_PARAM can be used to modify the default attributes e.g By default, GATHER_STATS_JOB will gather histograms, which can be confirmed by running below query

select dbms_stats.get_param('method_opt') method_opt from dual;

METHOD_OPT
--------------------------------------------------------------------
FOR ALL COLUMNS SIZE AUTO

To disable histogram capture, use

exec dbms_stats.set_param('method_opt', 'FOR ALL COLUMNS SIZE 1');

In case you wish to capture histograms for some of the tables, then you can use

exec dbms_stats.set_param('method_opt', 'FOR ALL COLUMNS SIZE REPEAT')

i.e Collects histograms only on the columns that already have histograms


Starting Oracle 11g database you can use DBMS_STATS.SET_*_PREFS to take care of point (d) and (e) i.e you can change the default gather options for particular table. Details can be found here

This is not exhaustive list and I hope that this will grow so that we can have Recommendation for GATHER_STATS_JOB status to be set to  “SCHEDULED” 🙂


Failed dependencies error: lib* needed by unixODBC-devel-2.2.11-7.1.i386

While trying to install 11gR1 on Oracle Enterprise Linux (OEL5), runInstaller failed for unixODBC* packages. To solve the issue , I started following OTN article

http://www.oracle.com/technology/pub/articles/smiley-11gr1-install.html

When trying to install RPM from CD3, faced following errors for unixODBC* rpm

#rpm -ivh compat-libstdc++-33* libaio-devel* sysstat* unixODBC*
warning: compat-libstdc++-33-3.2.3-61.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
error: Failed dependencies:
libboundparam.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libesoobS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libgtrtst.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libmimerS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libnn.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbccr.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbcdrvcfg1S.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbcdrvcfg2S.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbcinst.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbcminiS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbcnnS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbctxtS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
liboplodbcS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
liboraodbcS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libsapdbS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libtdsS.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libtemplate.so.1 is needed by unixODBC-devel-2.2.11-7.1.i386
unixODBC = 2.2.11-7.1 is needed by unixODBC-devel-2.2.11-7.1.i386
libodbc.so.1 is needed by unixODBC-kde-2.2.11-7.1.i386
libodbcinst.so.1 is needed by unixODBC-kde-2.2.11-7.1.i386
unixODBC = 2.2.11-7.1 is needed by unixODBC-kde-2.2.11-7.1.i386

Issue is because of missing rpm unixODBC-2.2.11-7.1.i386.rpm which is present in CD2 . Install it first and then the other RPM i.e
unixODBC-devel-2.2.11-7.1.i386 and unixODBC-kde-2.2.11-7.1.i386
can be installed without errors

Mount CD2
#cd /media/E*/Server
#rpm -ivh unixODBC-2.2.11-7.1.i386.rpm

Once rpm is successfully installed, mount CD3 and install unixODBC* rpm

Mount CD3
#cd /media/E*/Server
#rpm -ivh unixODBC*

Update
=====

Frits Hoogland commented on the post and pointed me to Oracle yum (Yellowdog updater modified) for taking care of dependencies. I had heard of yum but I had never tried it earlier. But as I checked today, it is very easy to setup. Process is listed at http://public-yum.oracle.com/
I am documenting the steps for setting it up on OEL5

<span style="font-family: arial, helvetica, sans-serif;">#</span> cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo

Edit the copied file based on your OEL5 release and set enabled=1. e.g

cat /etc/enterprise-release
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)

[el5_u3_base]
name=Enterprise Linux $releasever U3 - $basearch - base
baseurl=http://public-yum.oracle.com/repo/EnterpriseLinux/EL5/3/base/$basearch/
gpgkey=http://public-yum.oracle.com/RPM-GPG-KEY-oracle-el5
gpgcheck=1
enabled=1

To check

[rroot@db11g ~]# yum list ocfs2
Loaded plugins: security
Error: No matching Packages to list

ocfs2 packages are not available. Let’s install it now

[root@db11g ~]# yum install ocfs2
Loaded plugins: security
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package ocfs2-2.6.18-128.el5.i686 0:1.2.9-1.el5 set to be updated
--> Processing Dependency: ocfs2-tools >= 1.2.6 for package: ocfs2-2.6.18-128.el5
--> Running transaction check
---> Package ocfs2-tools.i386 0:1.2.7-1.el5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                   Arch      Version             Repository        Size
================================================================================
Installing:
 ocfs2-2.6.18-128.el5      i686      1.2.9-1.el5         el5_u3_base      272 k
Installing for dependencies:
 ocfs2-tools               i386      1.2.7-1.el5         el5_u3_base      1.1 M

Transaction Summary
================================================================================
Install      2 Package(s)
Update       0 Package(s)
Remove       0 Package(s)         

Total download size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): ocfs2-2.6.18-128.el5-1.2.9-1.el5.i686.rpm         | 272 kB     00:03
(2/2): ocfs2-tools-1.2.7-1.el5.i386.rpm                  | 1.1 MB     00:08
--------------------------------------------------------------------------------
Total                                           102 kB/s | 1.4 MB     00:13
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : ocfs2-tools                                       [1/2]
  Installing     : ocfs2-2.6.18-128.el5                              [2/2] 

Installed: ocfs2-2.6.18-128.el5.i686 0:1.2.9-1.el5
Dependency Installed: ocfs2-tools.i386 0:1.2.7-1.el5
Complete!

It’s cool..:)
There is one more method using which all the validated oracle packages can be installed during OEL5 installation.This also creates the oracle user/groups, sets up sysctl.conf, limits.conf, etc. Check out the article
here

Mview Complete Refresh and Atomic_refresh parameter

This post discusses issue faced by me while working on Materialized view (mview) creation at new site(database). Starting Oracle 10g, how atomic_refresh works with complete refresh has undergone a change.
Atomic_refresh parameter is to allow either all of the tasks of a transaction are performed or none of them (Atomicity). If set to TRUE, then all refreshes are done in one transaction. If set to FALSE, then the refresh of each specified materialized view is done in a separate transaction.
In case of 9i if a single mview was refreshed , it used to be truncated and then refreshed (which actually was not atomic). In case of multiple mviews being refreshed (part of refresh group), rows were deleted and then the insert was done.
As part of change in 10g, if atomic_refresh is set to true (By defualt) , rows will be deleted one by one and then insert will take place for both single mview or multiple mviews in refresh group. So if you need to truncate the mview before then set atomic_refresh =>false (default True) while doing a complete refresh.
Due to this change you will find many issues like high redo generation and longer time for complete refresh of mviews using dbms_mview.refresh as now in 10g it will go for deleting the rows and not truncate.
In our case a DBA issued a complete refresh for  mview with size of 195Gb (having around 8 indexes ). After 16 hours of running, refresh job was still deleting the rows and had not started inserting the rows. At this moment we decided to kill the refresh session. As this session had generated a lot of undo, smon kicked in to recover the transaction.
On checking the V$FAST_START_TRANSACTION , it reported that it will take around 2 months to perform the rollback.

This post discusses issue faced by me while working on Materialized view (mview) creation at new site(database). Starting Oracle 10g, how atomic_refresh works with complete refresh has undergone a change.

Atomic_refresh parameter is to allow either all of the tasks of a transaction are performed or none of them (Atomicity). If set to TRUE, then all refreshes are done in one transaction. If set to FALSE, then the refresh of each specified materialized view is done in a separate transaction.If set to FALSE, Oracle can optimize refresh by using parallel DML and truncate DDL on a materialized views.

In case of 9i  (atomic_refresh =>true), if a single mview was refreshed , it used to be truncated and then refreshed (which actually was not atomic). In case of multiple mviews being refreshed (part of refresh group), rows were deleted and then the insert was done.

As part of change in 10g, if atomic_refresh is set to true (By defualt) , rows will be deleted one by one and then insert will take place for both single mview or multiple mviews in refresh group. So if you need to truncate the mview before then set atomic_refresh =>false (default True) while doing a complete refresh.

Due to this change you will find many issues like high redo generation and longer time for complete refresh of mviews using dbms_mview.refresh as now in 10g it will go for deleting the rows and not truncate.

In our case a DBA issued a complete refresh without setting atomic_refresh to false for  mview with size of 195Gb (plus 8 indexes ). After 16 hours of running, refresh job was still deleting the rows and had not started inserting the rows. At this moment we decided to kill the refresh session. As this session had generated a lot of undo, smon kicked in to recover the transaction.

On checking the V$FAST_START_TRANSACTION , it reported that it will take around 2 months to perform the rollback.

SQL> select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo",   decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400))   "Estimated time to complete"
  2     from v$fast_start_transactions;

       USN STATE                 Total       Done       ToDo Estimated time to co
---------- ---------------- ---------- ---------- ---------- --------------------
        51 RECOVERING          3514498        354    3514144 12-SEP-2009 02:52:36

SQL> select * from V$fast_start_servers;

STATE       UNDOBLOCKSDONE        PID XID
----------- -------------- ---------- ----------------
RECOVERING             354         32 0033000200001C81
RECOVERING               0         33 0033000200001C81
RECOVERING               0         85 0033000200001C81
RECOVERING               0         38 0033000200001C81
RECOVERING               0         39 0033000200001C81
RECOVERING               0         40 0033000200001C81
RECOVERING               0         42 0033000200001C81
RECOVERING               0         43 0033000200001C81
RECOVERING               0         44 0033000200001C81
RECOVERING               0         45 0033000200001C81
RECOVERING               0         46 0033000200001C81
---- some output truncated -------
RECOVERING               0         68 0033000200001C81
RECOVERING               0         69 0033000200001C81
RECOVERING               0         53 0033000200001C81
RECOVERING               0         78 0033000200001C81
RECOVERING               0         79 0033000200001C81
RECOVERING               0         80 0033000200001C81
RECOVERING               0         81 0033000200001C81
RECOVERING               0         82 0033000200001C81
RECOVERING               0         83 0033000200001C81

fast_start_parallel_rollback was set to value of low. We see 50 processes were spawned and only one of the parallel server was doing the recovery indicating that the parallel servers might be interfering with each other. Metalink Note 144332.1 (- Parallel Rollback may hang database, Parallel query servers get 100% cpu) discusses this behavior. Now I decided to use the serial recovery by changing fast_start_parallel_rollback to false. But to do this , we had to disable the SMON to do transaction recovery using event 10513 at level 2.

SQL> oradebug setorapid  22
Unix process pid: 2728024, image: oracle@ods1 (SMON)
SQL> oradebug Event 10513 trace name context forever, level 2
Statement processed.
SQL> select 'kill -9 '||spid||' ' from V$process where pid in (select pid from V$FAST_START_SERVERS);

'KILL-9'||SPID||''
---------------------
kill -9 3014818
kill -9 3010772
kill -9 2916434
kill -9 2887716
kill -9 2678958
kill -9 2511030
kill -9 2224314
kill -9 2142210
kill -9 2822282
kill -9 2625696
kill -9 2506808
kill -9 2486520
kill -9 2314492
kill -9 2310186
kill -9 2752764
kill -9 2445478
kill -9 2326692
kill -9 2457716
kill -9 2654394
kill -9 2621630
kill -9 2580502
kill -9 2633960
kill -9 2412686

alter system set fast_start_parallel_rollback=false;

SQL>   select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo",   decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400))   "Estimated time to complete"
  2     from v$fast_start_transactions;

       USN STATE                 Total       Done       ToDo Estimated time to co
---------- ---------------- ---------- ---------- ---------- --------------------
        51 RECOVERING          3513444       6002    3507442 06-JUL-2009 17:58:03

SQL> select * from V$FAST_START_SERVERS;

no rows selected

Using serial recovery reduced estimated time to 5 hours.

To summarize, if you are still in process of upgrading 9i database to 10g database, then revisit your shell scripts and oracle dbms_jobs used for performing complete refresh of mviews and set atomic_refresh =>false explicitly to truncate the mview before refresh.