How to Change the Timezone in Linux?
Most modern Linux distributions have user-friendly programs to set the timezone, often accessible through the program menus or right-clicking the clock in a desktop environment such as KDE or GNOME. Failing that it’s possible to manually change the system timezone in Linux in a few short steps.
1. Logged in as root. Check which timezone your machine is currently using by executing `date`:
Mon 17 Jan 2005 12:15:08 PM PST
PST in this case is the current timezone.
2. Change to the directory /usr/share/zoneinfo. Here you will find a list of time zone regions. Choose the most appropriate region. For example if you live in Canada or the US this directory is the “America” directory.
3. If you wish, backup the previous timezone configuration by renaming it:
# mv /etc/localtime /etc/localtime.old
4. Create a symbolic link to the appropriate timezone from /etc/localtime. Example:
# ln -sf /usr/share/zoneinfo/Asia/Tehran /etc/localtime
5. Set the TIMEZONE, HWCLOCK entries in the file /etc/sysconfig/clock file to the appropriate values:
TIMEZONE="Asia/Tehran" HWCLOCK="--localtime"
6. Set the hardware clock:
# hwclock --localtime
Reference: How to Change the Timezone in Linux
LVMRECNMTCH problem during varyonvg on AIX
Have you ever encountered the following error on AIX?
# varyonvg testvg PV Status: hdisk1 000af0ffc5f038cb PVACTIVE hdisk2 000af0ffc254e591 LVMRECNMTCH 0516-056 varyonvg: The volume group is not varied on because a physical volume is marked missing. Run diagnostics.
In my case, the testvg had two disks and all the filesystems were mirrored. So, a copy of mirrors on hdisk1 were corrupted. How can we solve this problem? How can we varyonvg and mount the filesystems again?
To varyon the testvg again we just need to force the varyonvg using the following command:
# varyonvg -f testvg
Using the -f flag in varyonvg command allows a volume group to be made active that does not currently have a quorum of available disks. All disks that cannot be brought to an active state will be put in a removed state. At least one disk must be available for use in the volume group.
Now that the testvg is varied on we can mount all the filesystems:
# mount -a
For mirroring the testvg again, we can use the following scenario:
# unmirrorvg testvg hdisk1 # reducevg testvg hdisk1 # rmdev -dl hdisk1
Now replace the disk drive hdisk1, if it is corrupted, then let the newly added drive be renamed hdisk1. Then do the following:
# extendvg testvg hdisk1 # mirrorvg testvg
How to get unrestricted root access to HMC?
!ksh (for HMC v5)
Using NFS in AIX
Overview
The Networked File System (NFS) is one of a category of filesystems known as distributed filesystems. It allows users to access files resident on remote systems without even knowing that a network is involved and thus allows filesystems to be shared among computers. These remote systems could be located in the same room or could be miles away.
In order to access such files, two things must happen. First, the remote system must make the files available to other systems on the network. Second, these files must be mounted on the local system to be able to access them. The mounting process makes the remote files appear as if they are resident on the local system. The system that makes its files available to others on the network is called a server, and the system that uses a remote file is called a client.
NFS Server
NFS consists of a number of components including a mounting protocol, a file locking protocol, an export file and daemons (mountd, nfsd, biod, rpc.lockd, rpc.stad) that coordinate basic file services.
Systems using NFS make the files available to other systems on the network by “exporting” their directories to the network. An NFS server exports its directories by putting the names of these directories in the /etc/exports file and executing the exportfs command. In its simplest form, /etc/exports consists of lines of the form:
pathname -option, option ...
where pathname is the name of the file or directory to which network access is to be allowed; if pathname is a directory, then all of the files and directories below it within the same filesystem are also exported, but not any filesystems mounted within it. The next fields in the entry consist of various options that specify the type of access to be given and to whom. For example, a typical /etc/exports file may look like this:
/cyclop/users -access=homer:bart, root=homer /usr/share/man -access=marge:maggie:lisa /usr/mail
This export file permits the filesystem /cyclops/users to be mounted by homer and bart, and allows root access to it from homer. In addition, it lets /usr/share/man be mounted by marge, maggie and lisa. The filesystem /usr/mail can be mounted by any system on the network. Filesystems listed in the export file without a specific set of hosts are mountable by all machines. This can be a sizable security hole.
When used with the -a option, the exportfs command reads the /etc/exports file and exports all the directories listed to the network. This is usually done at system startup time.
# exportfs -a
If the contents of /etc/exports change, you must tell mountd to reread it. This can be done by re-executing the exportfs command after the export file is changed.
The exact attributes that can be specified in the /etc/exports file vary from system to system. The most common attributes are:
-access=list : Colon-separated list of hostnames and netgroups that can mount the filesystem
-ro : Export read-only; no clients may write on the filesystem
-rw=list : List enumerates the hosts allowed to mount for writing; all others must mount read-only.
-root=list : Lists hosts permitted to access the filesystem as root. Without this option, root access from a client is equivalent to access by the user nobody (usually UID=-2).
-anon : Specifies UID that should be used for requests coming from an unknown user. Defaults to nobody.
-hostname : Allow hostname to mount the filesystem.
For example:
/cyclop/users -rw=moe,anon=-1 /usr/inorganic -ro
This allows moe to mount /cyclop/users for reading and writing, and maps anonymous users (users from other hosts that do not exist on the local system and the root user from any remote system) to the UID=-1. This corresponds to the nobody account, and it tells NFS not to allow such users access to anything. On some systems, the UID=-2 may be used to allow anonymous users access only to world-readable files. The read-only access is referred to as read-mostly.
NFS Clients
After the files, directories and/or filesystems have been exported, an NFS client must explicitly mount them before it can use them. It is handled by the mountd daemon (sometimes called rpc.mountd). The server examines the mount request to be sure the client has proper authorization.
The following syntax is used for the mount command. Note that the server’s name is followed by a colon and the directory to be mounted:
# mount server1:/usr/src /src
Here, the directory structure /usr/src resident on the remote system server1 is mounted on the /src directory on the local system.
When the remote filesystem is no longer needed, it is unmounted with the umount:
# umount server1:/usr/src
The mount command can be used to establish temporary network mounts, but mounts that are part of a system’s permanent configuration should be either listed in /etc/filesystems (for AIX) or handled by an automatic mounting service such as automount or amd.
NFS Commands
lsnfsexp : Displays the characteristics of directories that are exported with the NFS
# lsnfsexp software -ro
mknfsexp -d path -t ro : Exports a read-only directory to NFS clients and add it to /etc/exports
# mknfsexp -d /software -t ro /software ro Exported /software # lsnfsexp /software -ro
rmnfsexp -d path : Unexports a directory from NFS clients and remove it from /etc/exports
# rmnfsexp -d /software
lsnfsmnt : Displays the characteristics of NFS mountable file systems
showmount -e : List exported filesystems
# showmount -e
export list for server:
/software (everyone)
showmount -a : List hosts that have remotely mounted local systems
# showmount -a server2:/sourcefiles server3:/datafiles
Start/Stop/Status NFS daemons
In the following discussion, reference to daemon implies any one of the SRC-controlled daemons (such as nfsd or biod).
The NFS daemons can be automatically started at system (re)start by including the /etc/rc.nfs script in the /etc/inittab file.
They can also be started manually by executing the following command:
# startsrc -s Daemon or startsrc -g nfs
where -s option will start the individual daemons and -g will start all of them.
These daemons can be stopped one at a time or all at once by executing the following command:
# stopsrc -s Daemon or stopsrc -g nfs
You can get the current status of these daemons by executing the following commands:
# lssrc -s Daemon or lssrc -a
If the /etc/exports file does not exist, the nfsd and the rpc.mountd daemons will not start. You can get around this by creating an empty/etc/exports file. This will allow the nfsd and the rpc.mountd daemons to start, although no filesystems will be exported.
References:
- Using Network File System in AIX – a primer
- man pages of NFS commands
How to Change IP, Hostname, Domain and Ports of a single node Oracle E-Business Suite
Oracle E-Business Suite is not dependent to IP address, so one can easily change the IP address of nodes without any effect on E-Business Suite.
What about Hostname, Domain and Ports? Oracle E-Business Suite is dependent to these. So, we couldn’t change theme without coordination of E-Business Suite itself.
There are two methods for changing Hostname, Domain and Ports of Oracle E-Business Suite. The first method, that will be discussed here, is using autoconfig and another method is by cloning. It is easier to use autoconfig method to change hostname, domain and ports and use cloning method for changing other configurations of Oracle E-Business Suite.
In this document we assume that our E-Business Suite has just one node so that all Tiers and Servers reside on this node. For changing hostname, domain and ports of a multinode Oracle E-Business Suite, refer to the documents listed in the refrences section of this post.
1. DB Tier: Deregister the current database server
As the database hostname and domain will be changed, the current database server node needs to be de-registered.
SQL> select NAME, SERVER_TYPE from FND_APP_SERVERS, FND_NODES
where FND_APP_SERVERS.NODE_ID = FND_NODES.NODE_ID and
SERVER_TYPE='DB' and FND_NODES.NODE_NAME=UPPER('oldhost');
NAME SERVER_TYPE
--------------- -----------
oldhost_PROD_DB DB
# cd $ORACLE_HOME/appsutil
# perl ./bin/adgentns.pl appspass=<APPSpwd> contextfile=./PROD_oldhost.xml -removeserver
SQL> select NAME, SERVER_TYPE from FND_APP_SERVERS, FND_NODES
where FND_APP_SERVERS.NODE_ID = FND_NODES.NODE_ID and
SERVER_TYPE='DB' and FND_NODES.NODE_NAME=UPPER('oldhost');
no rows selected
2. DB Tier: Create a new Context file
You can create the new context file using whichever of the following methods:
a. Manuall Method:
# cd $ORACLE_HOME/appsutil
# cp PROD_oldhost.xml PROD_newhost.xml
Edit PROD_newhost.xml manually:
Replace all oldhost with newhost
Replace all olddomain with newdomain
b. Script Method:
# cd $ORACLE_HOME/appsutil
# perl ./bin/adclonectx.pl contextfile=./PROD_oldhost.xml
Provide the values required for creation of the new Database Context file.
Do you want to use a virtual hostname for the target node (y/n) [n] ?:
Target hostname [oldhost]:newhost
Target System database name [PROD]:
Target instance is a Real Application Cluster (RAC) instance (y/n) [n]:
Target system domain name [olddomain]:newdomain
Oracle OS User [oraprod]:
Oracle OS Group [dba]:
Target system RDBMS ORACLE_HOME directory [/gldb/apps/d02/oracle/proddb/9.2.0]:
Target system utl_file accessible directories list [/usr/tmp]:
Number of DATA_TOP's on the target system [4]:1
Target system DATA_TOP 1:/gldb/apps/d03/oracle/proddata
Do you want to preserve the Display set to oldhost:0.0 (y/n) [y] ?:n
Target system Display [newhost:0.0]:
Target system JAVA_TOP location [null]:/gldb/apps/d01/oracle/prodcomn/java
Do you want to preserve the port values from the source system on the target system (y/n) [y] ?:
Database port is 1521
New context path and file name [PROD_newhost.xml]:
Creating the new Database Context file from :
/gldb/apps/d02/oracle/proddb/9.2.0/appsutil/template/adxdbctx.tmp
The new database context file has been created :
/gldb/apps/d02/oracle/proddb/9.2.0/appsutil/PROD_newhost.xml
Note: The command above will create a new Context file of the format PROD_newhost.xml in the current working directory.
3. APPS Tier: Deregister the current Applications server
As the Applications hostname and domain will be changed, the current Applications server node needs to be de-registered.
SQL> select NAME, SERVER_TYPE from FND_APP_SERVERS, FND_NODES
where FND_APP_SERVERS.NODE_ID = FND_NODES.NODE_ID and
SERVER_TYPE='APPS' and FND_NODES.NODE_NAME=UPPER('oldhost');
NAME SERVER_TYP
----------------- ----------
oldhost_PROD_APPS APPS
# cd $APPL_TOP/admin
# perl $AD_TOP/bin/adgentns.pl appspass=<APPSpwd> contextfile=./PROD_oldhost.xml -removeserver
SQL> select NAME, SERVER_TYPE from FND_APP_SERVERS, FND_NODES
where FND_APP_SERVERS.NODE_ID = FND_NODES.NODE_ID and
SERVER_TYPE='APPS' and FND_NODES.NODE_NAME=UPPER('oldhost');
no rows selected
4. APPS Tier: Create a new Context file
You can create the new context file using whichever of the following methods:
a. Manuall Method:
# cd $APPL_TOP/admin
# cp PROD_oldhost.xml PROD_newhost.xml
Edit PROD_newhost.xml manually:
Replace all oldhost with newhost
Replace all olddomain with newdomain
b. Script Method:
# cd $APPL_TOP/admin
# perl $AD_TOP/bin/adclonectx.pl contextfile=./PROD_oldhost.xml
Provide the values required for creation of the new APPL_TOP Context file.
Do you want to use a virtual hostname for the target node (y/n) [n] ?:
Target hostname [oldhost]:newhost
Target system database SID [PROD]:
Target system domain name [olddomain]:newdomain
Username for the applications file system owner [applprod]:
Group for the applications file system owner [dba]:
Target system database server node [oldhost]:newhost
Does the target system have more than one application tier server node (y/n) [n] ?:
Is the target system APPL_TOP divided into multiple mount points(y/n)[n]?:
Target system APPL_TOP mount point [/gldb/apps/d01/oracle/prodappl]:
Target system COMMON_TOP directory [/gldb/apps/d01/oracle/prodcomn]:
Target system 8.0.6 ORACLE_HOME directory [/gldb/apps/d01/oracle/prodora/8.0.6]:
Target system iAS ORACLE_HOME directory [/gldb/apps/d01/oracle/prodora/iAS]:
Do you want to preserve the Display set to oldhost:0.0 (y/n) [y] ?:n
Target system Display [newhost:0.0]:
Location of JDK 1.3.1 on the target system [/usr/java14]:
Do you want to preserve the port values from the source system on the target system (y/n) [y] ?:
Web Listener port is 8000
Complete port information available at /gldb/apps/d01/oracle/prodappl/admin/out/PROD_newhost/portpool.lst
New context path and file name [PROD_newhost.xml]:
Creating the new APPL_TOP Context file from :
/gldb/apps/d01/oracle/prodappl/ad/11.5.0/admin/template/adxmlctx.tmp
The new APPL_TOP context file has been created :
/gldb/apps/d01/oracle/prodappl/admin/PROD_newhost.xml
Note: The command above will create a new Context file of the format PROD_newhost.xml in the current working directory.
5. APPS Tier: Shutdown the Application Tier Services
# $COMMON_TOP/admin/scripts/PROD_oldhost/adstpall.sh apps/<appspasswd>
6. Change the hostname and domain
Change the hostname and domain at OS level.
# hostname -s newhost
# edit /etc/hosts as follow:
OLD: IP-Address oldhost.olddomain oldhost
NEW: IP-Address newhost.newdomain newhost
7. DB Tier: Reseed the Net Services Topology Model
# cd $ORACLE_HOME/appsutil
# ./bin/adconfig.sh contextfile=./PROD_newhost.xml
8. APPS Tier: Reseed the Net Services Topology Model
The Net Services Topology Model is automatically updated by running AutoConfig.
# $AD_TOP/bin/adconfig.sh contextfile=$APPL_TOP/admin/PROD_newhost.xml appspass=<appspasswd>
9. DB Tier: Shutdown the database and listener
# $ORACLE_HOME/appsutil/scripts/PROD_oldhost/addbctl.sh stop
# $ORACLE_HOME/appsutil/scripts/PROD_oldhost/addlnctl.sh stop PROD
10. DB Tier: Start the listener and database
# $ORACLE_HOME/appsutil/scripts/PROD_newhost/addlnctl.sh start PROD
# $ORACLE_HOME/appsutil/scripts/PROD_newhost/addbctl.sh start
11. APPS Tier: Start the Application Tier Services
# $COMMON_TOP/admin/scripts/PROD_newhost/adstrtal.sh apps/<appspasswd>
Notes:
- Q: Do you encounter the following errors when you start the listener?
Error listening on: (ADDRESS=(PROTOCOL=TCP)(Host=newhost)(Port=1521))
TNS-12532: TNS:invalid argument
TNS-12560: TNS:protocol adapter error
TNS-00502: Invalid argument
IBM/AIX RISC System/6000 Error: 515: Error 515 occurred.
A: Check $ORACLE_HOME/network/admin/PROD_newhost/sqlnet.ora to insure it is using new values:
OLD: tcp.invited_nodes=(oldhost.olddomain, newhost.newdomain)
NEW: tcp.invited_nodes=(newhost.newdomain)
2. Q: Do you encounter the following errors in Jinitiator console when you try to start form applications?
java.lang.NoClassDefFoundError: org/apache/regexp/RESyntaxException
at oracle.ewt.lwAWT.lwText.LWTextField.getText(LWTextField.java:196)
at oracle.ewt.lwAWT.lwText.LWTextField._getDisplayString(LWTextField.java:787)
A: Check $OA_HTML/bin/appsweb_PROD_newhost.cfg for the value of ‘archive2′. It should be as follow:
archive2=,/OA_JAVA/regexp.jar
3. Q: Do you encounter the following errors in Jinitiator console when you try to start form applications?
java.lang.Error: RE internal error: Corrupt program
at org.apache.regexp.RE.internalError(RE.java:820)
at org.apache.regexp.RE.matchNodes(RE.java:1414)
A: Made the following change:
# cd $JAVA_TOP
# mv org org.back
References:
1. How to change the hostname of an Applications Tier using AutoConfig [Metalink 341322.1]
2. How to change the hostname and/or port of the Database Tier using AutoConfig [Metalink 338003.1]
Shared server vs. Dedicated in Oracle
If you are running in 9i or above, there are two parameters (not one) which govern whether or not you are capable of running in shared server mode.
DISPATCHERS governs whether a job dispatcher runs. You have to have at least one of them configured before shared server is possible. However, the mere fact that a dispatcher runs does NOT mean your database is running in shared server mode. There also have to be shared server processes capable of handling the work dispatched by the dispatcher(s), and those are configured with the SHARED_SERVERS parameter. If that’s set to any number greater than 1, you have shared server processes running on your instance. But that STILL doesn’t mean you’re running in shared server mode! If you have SHARED_SERVERS=57 and no dispatcher, you simply have 57 processes sitting around doing nothing whatsoever (and incapable of doing useful work!)
In short, you have to have DISPATCHERS and SHARED_SERVERS set.
Note, for example, that 10g configures a single dispatcher for all databases by default (if they’re created with DBCA and you don’t get in there to stop it happeneing), but it does NOT configure SHARED_SERVERS, so by default a 10g database does not run in shared server mode.
The other thing I’d clarify is that a database doesn’t really run in shared server mode anyway! The fact that your instance has a dispatcher and shared server processes running doesn’t necessarily mean your users will end up connected to the dispatcher and having shared server processes handling their job requests. They will by default, but if the tnsnames.ora they use to connect (or its centralised equivalent) contains the line SERVER=DEDICATED, then they will get to use dedicated server processes, no matter what the dispatcher or shared server processes might think about it!
With dispatchers and shared server processes configured, in other words, an instance can “support shared server connection requests”. That’s rather different than “running in shared server mode”. The distinction is important because privileged actions (startup, shutdown, backup and recover commands) cannot be processed by a shared server process, so it’s important for an instance that is configured for normal users to use shared server processes to still support the connection to dedicated server processes by suitably credentialled users.
If a user does end up connected to a shared server process, there is usually a performance penalty to pay compared to using a dedicated server process. A user submits a query and instead of it being immediately processed by a server process, it gets submitted to a dispatcher …which promptly sticks it on a job queue! You then have to wait for a shared server process to become free and decide to pick your job off the queue. That’s inevitably slower than doing it the dedicated way.
People use shared server as the first line of scaling up their databases… and you’re right that it primarily depends on the number of users connected to the server concurrently. In dedicated server mode, a new connection means a new process gets spawned (or a new thread on Windows) and a new connection socket is opened. Servers can only handle so many connection sockets, processes or threads before they start to keel over under the strain. Shared server, as the name suggest, means that new connections do not cause new server processes to be spawned. So 300 users can be processed with, maybe, 30 or 40 processes in total. If your box would normally keel over handling 300 dedicated connections, then clearly with that sort of sharing ratio, you’d be able to scale to nearer 3000 users before it starts wilting by using shared processes.
But it’s also a bit subtler than that: a data warehouse would be daft to implement shared server, even if it did have 300+ concurrent users. That’s because the users of such systems typically run queries that run for hours… and a shared process that is nabbed to perform one job for hours on end isn’t really a shared process any more, is it?! So the rule of thumb as to when to implement shared server is yes, (a) when your concurrent user count starts reaching levels that your server just doesn’t seem able to sustain any more AND (b) when you can be sure that the users tend to issue short, sharp queries -say, about 3 seconds or so to process, max.
Again, there are mixed states to get through, too. You might have lots of OLTP-type sub-3-second transactions on the same database on which one or two users regularly run big reports. In that case, you make sure the reporters have a tnsnames.ora that says SERVER=DEDICATED and the OLTP-type people use one that has SERVER=SHARED in it; configure the DISPATCHERS and SHARED_SERVER parameters for the instance and then those that can benefit from shared servers can do so and those that wouldn’t won’t be stealing shared processes from those that can!
The alternative approach for those with more cash is to go and buy better server hardware that can cope with the user community numbers! Shared Server configuration, however, comes free. You pays your money and you takes your choices!
Reference: http://forums.oracle.com/forums/thread.jspa?messageID=2114775#2114775
Using parallel execution in Oracle
Using Parallel execution, Oracle can divide the work of processing an SQL statement among multiple parallel processes. The execution of many SQL statements can be parallelized. The degree of parallelism is the number of parallel execution servers that can be associated with a single operation.
The ALTER SESSION statement can be used to control parallel execution for a session. You can force parallel execution of all subsequent DML, DDL or query statements for which parallelization is possible.
The syntax of ALTER SESSION statement for parallel execution is as follow:
ALTER SESSION {ENABLE|DISABLE|FORCE} PARALLEL {DML|DDL|QUERY} [PARALLEL int]
Example:
SQL> set time on
18:31:10 SQL> Select count(*) from GL_JE_LINES
18:31:12 2 Where trunc(last_update_date) <= to_date('091017','YYMMDD');
COUNT(*)
----------
132161754
18:49:20 SQL> alter session force parallel query parallel 4;
Session altered.
18:49:25 SQL> Select count(*) from GL_JE_LINES
18:49:27 2 Where trunc(last_update_date) <= to_date('091017','YYMMDD');
COUNT(*)
----------
132161754
18:53:11 SQL>
As we can see, using parallel feature, the query has finished more then 4 times faster. The first query run as a single process and just use of 1 CPU, whereas oracle creates 4 separate OS processes to service the second query and so the second query have been served by 4 CPU.
What about running a SQL statement in parallel from a stored procedure? For this SQL statement we can use parallelizm as the following example:
CREATE OR REPLACE PROCEDURE ... BEGIN EXECUTE IMMEDIATE 'alter session force parallel DML parallel 4'; Copy SQL Statement body here ... EXECUTE IMMEDIATE 'alter session disable parallel DML'; END ... /
Reference: Oracle9i Database Administrator’s Guide
aio errors after installing AIX using mksysb
We have installed a new AIX using a mksysb backup, and then restored user volume groups and filesystems. But, after finishing the installation, while we run the programs (sqlplus, lsnrctl, …) that need aio servers, we encounter the following error?
exec(): 0509-036 Cannot load program sqlplus because of the following errors:
0509-130 Symbol resolution failed for /usr/lib/libc_r.a(aio.o) because:
0509-136 Symbol kaio_rdwr (number 0) is not exported from
dependent module /unix.
0509-136 Symbol listio (number 1) is not exported from
dependent module /unix.
0509-136 Symbol acancel (number 2) is not exported from
dependent module /unix.
0509-136 Symbol iosuspend (number 3) is not exported from
dependent module /unix.
0509-136 Symbol aio_nwait (number 4) is not exported from
dependent module /unix.
0509-150 Dependent module libc_r.a(aio.o) could not be loaded.
0509-026 System error: Cannot run a file that does not have a valid format.
0509-192 Examine .loader section symbols with the
'dump -Tv' command.
What is the problem?
The problem is related to aio0 device! After installing AIX using mksysb backup, aio0 device becomes Defined, and the problem is just because of this! So, we should just make it available. To make aio0 available without need to restart the system do the following:
# lsdev -l aio0 aio0 Defined Asynchronous I/O (Legacy) # mkdev -l aio0 aio0 Available # lsdev -l aio0 aio0 Available Asynchronous I/O (Legacy)
And now we can run the programs (sqlplus, lsnrctl, …) without any error.
The changes above will made aio0 available, but just temporarily and not permanently. After rebooting the system, the state of aio0 will be changed to defined again. To make it available permanently, we must do the following:
# lsattr -El aio0 autoconfig defined STATE to be configured at system restart True fastpath enable State of fast path True kprocprio 39 Server PRIORITY True maxreqs 4096 Maximum number of REQUESTS True maxservers 10 MAXIMUM number of servers per cpu True minservers 1 MINIMUM number of servers True # chdev -l aio0 -a autoconfig='available' -P aio0 changed # lsattr -El aio0 autoconfig available STATE to be configured at system restart True fastpath enable State of fast path True kprocprio 39 Server PRIORITY True maxreqs 4096 Maximum number of REQUESTS True maxservers 10 MAXIMUM number of servers per cpu True minservers 1 MINIMUM number of servers True
How to get table and index DDL in Oracle?
To punch off all table and indexes for the EMP table, we execute dbms_metadata. get_ddl, select from DUAL, and providing all required parameters.
set heading off;
set echo off;
Set pages 999;
set long 90000;
spool dept_ddl.sql
select dbms_metadata.get_ddl('TABLE','DEPT','SCOTT') from dual;
select dbms_metadata.get_ddl('INDEX','DEPT_IDX','SCOTT') from dual;
spool off;
Now we can modify the syntax to punch a whole schema. It us easily done by selecting dbms_metadata. get_ddl and specifying USER_TABLES and USER_INDEXES. :
set pagesize 0
set long 90000
set feedback off
set echo off
spool scott_schema.sql
SELECT DBMS_METADATA.GET_DDL('TABLE',u.table_name)
FROM USER_TABLES u;
SELECT DBMS_METADATA.GET_DDL('INDEX',u.index_name)
FROM USER_INDEXES u;
spool off;
Reference: Get table and index DDL the easy way (Don Burleson)
Oracle’s db_file_multiblock_read_count
How can we use of oracle’s db_file_multiblock_read_count parameter? For me, it has being a big question for a while and now I think I know a little about the answer!
We should know that the parameter db_file_multiblock_read_count is only applicable for tables/indexes that are full scanned. This parameter controls how much data Oracle thinks it can retrieve from the disks in a single trip (during a table/index scan). The important part of this statement is the “how much Oracle thinks”. It is relatively easy to manufacture a circumstance where Oracle thinks it can achieve a much higher read size than can actually be serviced by the operating system. Unfortunately, this discrepancy can have an negative impact on performance, since the cost optimizer evaluates costs based on what Oracle thinks, not what is actually achievable.
According to Oracle, the following is the formula for setting db_file_multiblock_read_count:

According to the formula above, because for a database the parameter db_block_size is fixed, the maximum amount for parameter db_file_multiblock_read_count is directly proportional to the maximum of I/O chunk size.
But how do we know the value of the max I/O chunk size? Each version of Oracle is shipped with a preset maximum of how much data can be transferred in a single read. For 8i and 9i this is 1Mb and is referred to as SSTIOMAX. To determine it for your Oracle version, simply set db_file_multiblock_read_count to a very big value and you will see that Oracle will size it down for you! The following is an example:
$ sqlplus "/as sysdba"
SQL*Plus: Release 9.2.0.5.0 - Production on Tue Sep 29 14:06:52 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
SQL> col NAME format a30
SQL> col VALUE format a10
SQL> select NAME, VALUE from v$parameter
where NAME in ('db_file_multiblock_read_count','db_block_size');
NAME VALUE
------------------------------ ----------
db_block_size 8192
db_file_multiblock_read_count 16
SQL> alter session set db_file_multiblock_read_count = 32000;
Session altered.
SQL> select NAME, VALUE from v$parameter
where name in ('db_file_multiblock_read_count','db_block_size');
NAME VALUE
------------------------------ ----------
db_block_size 8192
db_file_multiblock_read_count 128
As you can see from the example above, for Oracle9i when db_block_size is 8KB, the maximum value of parameter db_file_multiblock_read_count is 128, and it means that Max I/O Chunk size is 1MB.
OK. Now for our example the parameter db_file_multiblock_read_count has set to its maximum value and Oracle thinks it can retrieve 1MB data in a single read from disk in case of table/index scan. However we set maximum value of db_file_multiblock_read_count, it still isn’t an effective maximum value because the maximum size of an I/O passed from an application to underlying disk, is OS and disk dependent!
My Oracle is installed on AIX 5.2, so I will continue with this OS. To set LTG and max_transfer sizes on AIX please refer to my previouse post:”LTG and max_transfer on AIX“. For other platforms please refer to their documents.
Now it seems everything is ready. The database is set to use 1MB I/O chunks and OS and disks are also configured to support this I/O size. But can this configuration deliver 1MB I/O that Oracle think? In the following we will try to find the maximum effective db_file_multiblock_read_count.
We will create a table and will insert so many records into it, and then while event 10046 is enabled at level 8, will scan it. Finally, we will examine the trace file to find the largest multiblock_read_count that actually performed for this full table scan. Bear in mind that the table should not have any blocks in Oracle’s buffer cache, so we will restart the database after inserting data into table.
SQL> CREATE TABLE T1 ("N1" NUMBER, "N2" NUMBER, "V1" VARCHAR2(215))
STORAGE(INITIAL 1024k next 1024);
Table created.
SQL> insert into T1
select trunc((rownum-1)/15) n1,
trunc((rownum-1)/15) n2,
rpad('x', 215) v1
from all_objects
where rownum <= 3000;
3000 rows created.
SQL> insert into T1 select * from T1;
3000 rows created.
...
SQL> insert into T1 select * from T1;
192000 rows created.
SQL> insert into T1 select * from T1;
384000 rows created.
SQL> commit;
SQL> startup force
ORACLE instance started.
Total System Global Area 2.7511E+10 bytes
Fixed Size 782008 bytes
Variable Size 4647288832 bytes
Database Buffers 2.2549E+10 bytes
Redo Buffers 314847232 bytes
Database mounted.
Database opened.
SQL> alter session set events '10046 trace name context off';
Session altered.
SQL> alter session set events '10046 trace name context forever, level 8';
Session altered.
SQL> select /*+ FULL(t) */ count(*) from T1;
COUNT(*)
----------
768000
SQL> alter session set events '10046 trace name context off';
Session altered.
SQL>
$cd $ORACLE_HOME/admin/udump/
$sed -n '/scattered/s/.*p3=//p' prod_ora_3760204.trc|sort -n|tail -1
16
And thus, we couldn’t achieve more than 16 for db_file_multi_block_read_count! It means we could just retrieve 128KB I/O chunks (8KB * 16 = 128KB). But why?!
After investigating and googling the internet, I realized that it’s because of the table’s extent size! Because oracle read maximally by EXTENT size (a read never spans extents)!
The tablespace that was contains the table was locally managed and its extent allocation type was “UNIFORM SIZE 128K”. UNIFORM allocation type for a tablespace means that all extents are of fixed size in the tablespace. By the following query we can see the extents size of the table:
SQL> select bytes/1024, count(*) from USER_EXTENTS
where segment_name='T1'
group by bytes/1024
order by 1;
BYTES/1024 COUNT(*)
---------- ----------
128 1525
And we see that all the extents are fixed 128kB.
To be continued…
10gR2 Note: Oracle Database 10g Release 2 automatically selects the appropriate value for this parameter depending on the operating system optimal I/O size and the size of the buffer cache. For more details, see Automatically tuned multi-block reads in 10gR2 by Don Burleson.
References: