Monday, April 23, 2012

Silent Installation of Oracle Patchset

Sometimes you are tired of doing next-next-next when performing Oracle patchset installation. Luckily Oracle is smart enough to allow you to do silent installation and it’s very easy to do:

[TEST] $ ./runInstaller -silent -force \ 

FROM_LOCATION="/mnt/backup/dba/software/oracle/database/10.2.0.5/Disk1/stage/products.xml" \ 

ORACLE_HOME="/oracle/product/10.2.0/db_2" \ 

ORACLE_HOME_NAME="db_2" \ 

TOPLEVEL_COMPONENT='{"oracle.patchset.db","10.2.0.5.0"}' \ 

DECLINE_SECURITY_UPDATES="true" 

... skippppp ...  

Install successful 

Linking in progress (Wednesday, January 26, 2011 4:58:27 PM CET) 

..                                                               75% Done. 

Link successful 

Setup in progress (Wednesday, January 26, 2011 4:59:18 PM CET) 

.........                                                       100% Done. 

Setup successful 

End of install phases.(Wednesday, January 26, 2011 4:59:24 PM CET) 

WARNING: 

The following configuration scripts need to be executed as the "root" user. 

#!/bin/sh 

#Root script to run 

/oracle/product/10.2.0/db_2/root.sh 

To execute the configuration scripts: 

    1. Open a terminal window 

    2. Log in as "root" 

    3. Run the scripts 

The installation of Oracle Database 10g Release 2 Patch Set 4 was successful. 

Please check '/oracle/oraInventory/logs/silentInstall2011-01-26_04-56-13PM.log' for more details. 

[root@test ~]# /oracle/product/10.2.0/db_2/root.sh 

Running Oracle 10g root.sh script... 

The following environment variables are set as: 

    ORACLE_OWNER= oracle 

    ORACLE_HOME=  /oracle/product/10.2.0/db_2 

Enter the full pathname of the local bin directory: [/usr/local/bin]: 

The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n) 

[n]: 

The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 

[n]: 

The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 

[n]: 

Entries will be added to the /etc/oratab file as needed by 

Database Configuration Assistant when a database is created 

Finished running generic part of root.sh script. 

Now product-specific root actions will be performed.

And you are done!

Thursday, April 19, 2012

Migrate Dictionary managed Tablespaces to locally managed

Like any other object, the data dictionary manages space allocation to a tablespace. That means Oracle updates the appropriate tables in the data dictionary whenever an extent is allocated or freed for reuse. Oracle also stores rollback information about each update of the dictionary tables.

Because dictionary tables and rollback segments are part of the database, the space that they occupy is subject to the same space management operations as all other data.
This method of space management is called extent management by the data dictionary. These tablespaces are also called as Dictionary managed tablespaces. This was the only option available prior to release 8.1.
In Oracle release 8.1 and above you have an option to manage the space allocation called extent management by the tablespace.

Locally Managed Tablespaces

A tablespace that can manage extent allocation by itself is called locally managed tablespace. These tablespaces maintain a bitmap in each datafile to keep track of the freed or used status of blocks in that datafile. Each bit in the bitmap corresponds to a block or a group of blocks. When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the blocks. These changes do not generate rollback information because they do not update tables in the data dictionary (except for special cases such as tablespace quota information).

NOTE: The storage parameters NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and DEFAULT STORAGE are not valid for extents that are managed locally .

Extent Allocation

Locally managed tablespaces can have uniform extent sizes or variable extent sizes that are determined by the system. Any of the options, UNIFORM or AUTOALLOCATE can be mentioned while creating the tablespace. For UNIFORM extents you can specify an extent size. The default size is 1MB. For AUTOALLOCATE extents you can specify the size of the initial extent and Oracle determines the optimal size of the additional extents, with a minimum extent size of 64KB. That is why these are called system-managed extents.

How Extents are Allocated

Oracle looks for free space to allocate to a new extent by first determining a candidate datafile in the tablespace and then searching the datafile's bitmap for the required number of adjacent free blocks. If that datafile does not have enough adjacent free space, Oracle looks in another datafile. When extents are deallocated, Oracle modifies the bitmap in the datafile.

Create A Locally Managed Tablespace

CREATE TABLESPACE users
DATAFILE 'users.dbf'
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 256K;

Advantages

Local management of extents avoids recursive space management operations, which can occur in dictionary managed tablespaces.

Local management of extents automatically tracks adjacent free space, eliminating the need to coalesce free extents.

Reliance on data dictionary is reduced.

Notes

Temporary tablespaces that manage their extents locally can only use UNIFORM extent allocation.

For permanent tablespaces the default extent size for system managed extents is 64KB.

The storage parameters NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and DEFAULT STORAGE are not valid for locally managed tablespaces.

Change normal tablespaces to locally managed

Check extent management of the tablespaces with following command:

SQL> SELECT tablespace_name,extent_management
FROM dba_tablespaces;
TABLESPACE_NAME                EXTENT_MAN
------------------------------ ----------
SYSTEM                         DICTIONARY
TEMP                           LOCAL
USERS                          DICTIONARY
TAB                            DICTIONARY
IDX                            DICTIONARY
SYSAUX                         LOCAL
UNDO                           LOCAL
First change first all dictionary managed tablespaces except tablespace SYSTEM to locally managed with the following procedure:

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('USERS');

PL/SQL procedure successfully completed.

The tablespace must be kept online and read/write during migration. Note that temporary tablespaces cannot be migrated.

Change SYSTEM tablespaces to locally managed

Before the SYSTEM tablespace can be migrated to locally managed format, you should ensure the following:

The database has a default temporary tablespace which is not SYSTEM

There are not any rollback segments in dictionary managed tablespaces

There is at least one online rollback segment in a locally managed tablespace, or an undo tablespace (if using automatic undo management mode) should be online.

All tablespaces other than the tablespace containing the undo space (undo tablespace or the tablespace containing the rollback segment) and the default temporary tablespace are in read-only mode.

There is a complete backup of the system.

The system is in restricted mode.

Notr, that we already have an UNDO Tablespace. The following query determines whether the SYSTEM tablespace is locally managed:

SQL> SELECT ts# FROM ts$ WHERE ts# = 0 AND bitmapped <> 0;

If 0 rows are returned, then the SYSTEM tablespace is dictionary managed. Otherwise, the SYSTEM tablespace is locally managed.

SQL> shutdown immediateSQL> startup restrict

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

ERROR at line 1:
ORA-10644: SYSTEM tablespace cannot be default temporary tablespace
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 227
ORA-06512: at line 1

SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

ERROR at line 1:
ORA-10647: Tablespace other than SYSTEM, UNDO, TEMP not
found in read only mode
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 227
ORA-06512: at line 1

SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
TEMP
USERS
TAB
IDX
SYSAUX
UNDO

SQL> alter tablespace USERS read only;
SQL> alter tablespace TAB read only;
SQL> alter tablespace IDX read only;

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');

ERROR at line 1:
ORA-10648: Tablespace SYSAUX is not offline
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 227
ORA-06512: at line 1

SQL> alter tablespace SYSAUX offline;

SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('SYSTEM');
PL/SQL procedure successfully completed

Friday, April 6, 2012

to increase Swap space in a linux box

These are the steps to increase the swap size in Linux:

===============================================================================

Please follow the steps:

1. Check how much swap space you already have by typing the command “swapon –s”.

2. Now use data dump (dd) command to create the extra swap file. Command  dd if=/dev/zero of=/extraswap bs=1M count=512

replace 512 with the number of megabytes you want in your auxiliary swap file.

3. Type the command mkswap /extraswap to make our file swap-consumable for the Linux kernel.

4. Now open /etc/fstab and find a line about swapfile that looks something like:

/dev/vg00/lvol1 swap swap defaults 0 0

5. Now, add one entry in /etc/fstab below ,above shown line. Add  /extraswap swap swap defaults 0 0

6. Restart the VM and perform step 1 to see increased swap.

===============================================================================

Hope this will solve your problem. 

M.N.V Sudhakar