How to find the 32 bit / 64 bit Linux?

Command to find the linux installation is 32 bit or 64 bit os?

getconf LONG_BIT 

:-)

Keep alive/active of a Putty session

Keeping idle sessions active.




Another frustrating problem is induced by the time-to-live of inactive or idle TCP sessions on firewall or switch configurations.

At some companies this is put aggressively low so that TCP sessions that have no activity for 1 minute or even 30 seconds are being dropped.

If you are using an SSH connection over such a network device, you have to take care to send keep-alive packets over your idle session.

To do this go to Category: Connection and set Seconds between keepalives (0 to turn off) to 30.



-----------------------------------------------------------------------------------------------------------------------------------------------------------------------



You need to load every Solution in Putty.

Steps are :-

1. Load any solution.

2. Go to Connection.

3. Change SECONDS BETWEEN KEEPALIVES from 0 to 30.

4. Go to Session again and SAVE the settings.



Also see my settings from putty. I have no TIMEOUT ISSUE now.

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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

[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!

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. Steps to change SYSTEM tablespaces to 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

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. 