http://en.kioskea.net/forum/affich-6398-my-laptop-won-t-start#p28637

Guys pls check link before you go with the HP Laptops and  Specially Nvdia drivers hp laptops are ditched and need to make you pay back for another one

Interview DB2 3

FEDERATED SYSTEMS(or Virtual Database) :  it is type of meta data management system. where apart  of data in other environment is made available in  one environment.

Steps in federated systems:

1)Catalog remote database REM_DB2 at instance db2inst2

db2 catalog TCPIP node RMDBNODE remote 172.16.128.151 server 60134

The CATALOG TCPIP NODE command completed successfully.

Directory changes may not be effective until the directory cache is

refreshed.

 

</db2ramana/db2inst2>db2 catalog db REM_DB2 at node RMDBNODE

The CATALOG DATABASE command completed successfully.

Directory changes may not be effective until the directory cache is

refreshed.

</db2ramana/db2inst2>db2 connect to REM_DB2 user testdb2 using testdb2

2)Configure instance db2inst2 for FEDERATED supoort

</db2ramana/db2inst2>db2 update dbm cfg using federated yes

DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed

successfully.

</db2ramana/db2inst2>db2 get dbm cfg | grep FED

Federated Database System Support           (FEDERATED) = YES

Bypass federated authentication            (FED_NOAUTH) = NO

Maximum Asynchronous TQs per query    (FEDERATED_ASYNC) = 0

3) Create wrapper which support DB2 database

Wrappers are mechanisms by which the federated database interacts with data sources. The federated database uses routines stored in a library called a wrapper module to implement a wrapper.

</db2ramana/db2inst2>db2 " create wrapper DRDA"

DB20000I  The SQL command completed successfully.

</db2ramana/db2inst2>db2 "select * from syscat.wrappers"

4)Create server and provide credential to access remote database, make sure correct version is given for DB2.

Normally as db2 create myser1 type db2/aix version 9.1 wrapper drda…

5) Mapped the user for authentication.

db2 => create user mapping for db2inst2 server myserv1 options (remote_authid 'testdb2',remote_password 'testdb2')

DB20000I  The SQL command completed successfully

6) Create nick name from remote table.

 

HADR: High Availability Disaster Recovery.. (ModesàSynchronous(from S.log buffer) ,asynchrouns(from send() of Primary),near synchrouns(Default in HADR ,from Receive())

Advanced of High availability data replication in Informix.

1. At primary server: Configure database for log shipping.

 

</db2inst1>db2 update db cfg for prod_Db using logretain on

The UPDATE DATABASE CONFIGURATION command completed successfully.

</db2inst1>db2 connect to prod_db

SQL1116N  A connection to or activation of database "PROD_DB" cannot be made

because of BACKUP PENDING.  SQLSTATE=57019

 

</db2inst1>db2 backup db prod_db

 

2)   Now perform the online back up for primary Database

</db2inst1>db2 connect to prod_db;;;;</db2inst1>db2 backup db prod_db online

3)Move that online backup file to the standby server. If that server is different server then use mount utilities.

4)***Restore database at secondary server and keep into roll forward pending mode****

5)Update the configuration parameters in both databases.

 

On Primary:

update db cfg for prod_db using HADR_LOCAL_HOST mcdb04

update db cfg for prod_db using HADR_REMOTE_HOST mcdb04

update db cfg for prod_db using HADR_LOCAL_SVC 18889

update db cfg for prod_db using HADR_REMOTE_SVC 18888

update db cfg for prod_db using HADR_REMOTE_INST db2inst2

update db cfg for prod_db using HADR_SYNCMODE SYNC

update db cfg for prod_db using LOGINDEXBUILD ON

On Secondary:

update db cfg for prod_db using HADR_LOCAL_HOST mcdb04

update db cfg for prod_db using HADR_REMOTE_HOST mcdb04

update db cfg for prod_db using HADR_LOCAL_SVC 18888

update db cfg for prod_db using HADR_REMOTE_SVC 18889

update db cfg for prod_db using HADR_REMOTE_INST db2inst1

update db cfg for prod_db using HADR_SYNCMODE SYNC

update db cfg for prod_db using LOGINDEXBUILD ON

 

6)***Start HADR on the standby server with the following command***

(on Secondary/Standby Server  First as Stanby)

7)Start HADR on the Primary server with the following command

</db2inst1>db2 start HADR on database PROD_DB as PRIMARY

8) For Verification you can check a db2reply application runs on Standby.

Using db2pd utility we can check the running of HADR on Primary and Seconday.

And By Using Take over command we can make the secondary/Standby into primary and vice versa

Pre Migration Tasks:

We will check whether Database is well for migration or not through db2ckmig command, and this db2ckmig gives information on Catalog Database, Inconsistent Database?, backup Pending State, Rollforward Pending state, Tablespace state Normal or not..?,

• A catalogued database actually exists.
  
• A database is not in an inconsistent state.
  
• A database is not in a backup pending state.
  
• A database is not in rollforward pending state. 
  
• Table spaces are in a normal state.
  
• A database does not contain user-defined types (UDTs) with the name XML, DATALINK, BINARY or VARBINARY.
  
• A database does not have orphan rows in system catalog tables.
  
• A database enabled as an HADR primary database allows successful connections.
  
• A database role is not standby for an HADR primary database.
  
• If SYSCATSPACE is a DMS table space and AUTORESIZE is not enabled, SYSCATSPACE has at least 50% free pages of total pages.
  
• A database must pass all of these checks to succeed at the migration process.
  
• The db2imigr calls the db2ckmig command. The db2imigr fails if the db2ckmig command finds any of the conditions listed above are not true, and returns the DBI1205E error code.

 

• Prerequisite: Ensure that you have SYSADM authority.

 

And the instance should be in stop mode(db2stop),for the db2ckmig

 

db2iupdt---Used to Update the instance(Migration of instance)

After updating of instance with this command use ipclean(used for system resource cleanup)

 

 

 

 

 

 

 

 

 

 

 

 

 

DB2 Tuning and Performance

Tuning should begin with the DB2 UDB registry variables, DB2 Database Manager instance configuration parameters, and database configuration parameters that can have the biggest impact on performance. From there, look at how buffer pools are being used and determine whether additional buffer pools or different buffer pool sizes would help. Choosing the proper tablespace type, extent size, and prefetch size — as well as keeping system catalog statistics up-to-date — round out the basics of performance tuning



The following registry variable recommendations apply to Linux, Unix, and Windows platforms.

DB2_APM_PERFORMANCE. OFF is the default value for this registry variable, which specifies whether or not performance-related changes in the access plan manager (APM) that will affect the behavior of the SQL cache (package cache) are to be made. It also specifies whether the global SQL cache will operate without the use of package locks, which are internal system locks that prevent cached package entries from being inadvertently removed.

This registry variable should only be set to ON in a nonproduction environment. When ON, you may see Out of package cache errors, and memory usage may increase. And PRECOMPILE, BIND, and REBIND operations can't be performed, nor can operations that invalidate packages or make them inoperable.

DB2_AVOID_PREFETCH. This registry variable specifies whether or not prefetching should be performed during crash recovery. The default is OFF; if set to ON, prefetching isn't performed.

DB2BPVARS. Supported parameters for DB2BPVARS, which specifies the location of a file that contains parameter values to be used when tuning buffer pools, include:

NO_NT_SCATTER
NT_SCATTER_DMSFILE
NT_SCATTER_DMSDEVICE
NT_SCATTER_SMS
NUMPREFETCHQUEUES
PREFETCHQUEUESIZE

more 081126-0035205.log | grep -i ^insert | wc -l

For each of the _SCATTER parameters, the default value is 0 (or OFF) and the possible values are: 0 (OFF) and 1 (ON). For NUMPREFETCHQUEUES, the default value is 1; the range of values is 1 to NUM_IOSERVERS. And for PREFETCHQUEUESIZE, the default value is whichever is the largest: 100 or 2 * NUM_IOSERVERS. The range is 1 to 32,767.

Each _SCATTER parameter is used to turn scatter read on or off for the respective type of tablespace containers used (or to turn scatter read off for all containers). The remaining parameters can be used to improve buffer pool data prefetching.

Note: The A _SCATTER parameter can only be set to ON if DB2NTNOCACHE is set to ON and the Windows operating system is being used.

DB2CHKPTR. This registry variable specifies whether or not pointer checking for input will be performed; the default value is OFF.

DB2_ENABLE_BUFPD. The default value is OFF for this registry variable, which specifies whether or not DB2 is to use intermediate buffering to improve query performance.

DB2_EXTENDED_OPTIMIZATION. This registry variable specifies whether or not the query optimizer will use optimization extensions to improve query performance; the default is OFF.

DB2MAXFSCRSEARCH. This variable can be set to -1, or a value from 1 to 33554 in order to specify the number of free-space control records to search when adding a record to a table. It allows you to balance insert speed with space reuse (small values optimize for insert speed, large values optimize for space reuse). If the registry variable is set to -1, the DB2 Database Manager will search all free-space control records. The default value is 5.

DB2MEMMAXFREE. This variable specifies the amount of free memory that each DB2 agent will retain; values range from 0 to 2.0e+32 bytes. The default is 8,388,608 bytes.

DB2_OVERRIDE_BPF. This registry variable, which can be set to a positive number of 4k pages, specifies the size of the buffer pool (in pages) that will be created at database activation or the first time a connection is established. DB2_OVERRIDE_BPF is useful when failures resulting from memory constraints occur during database activation or the first time a connection is established. Such a memory constraint could arise either because of a real memory shortage (which is rare) or because of an attempt by the DB2 Database Manager to allocate large, inaccurately configured buffer pools. The default value is null.

DB2PRIORITIES. The values for this registry variable are platform-dependent. DB2PRIORITIES controls the priorities of DB2 processes and threads.

DB2_SORT_AFTER_TQ. DB2_SORT_AFTER_TQ specifies how the DB2 optimizer works with directed table queues in a partitioned database environment when the receiving end requires the data to be sorted and the number of receiving nodes is equal to the number of sending nodes. When set to NO (which is the default), the DB2 optimizer tends to sort at the sending end and merge the rows at the receiving end. When set to YES, the optimizer transmits the unsorted rows and sorts them at the receiving end after receiving all the rows.

DB2_STPROC_LOOKUP_FIRST. This registry variable specifies whether or not the DB2 UDB server will perform a catalog lookup for all DARIs and stored procedures before looking in the function subdirectory of the sqllib subdirectory and in the unfenced subdirectory of the function subdirectory of the sqllib subdirectory. The default is OFF.

DB2_HASH_JOIN. A YES or NO value specifies whether or not a hash join can be used when compiling a data access plan. The default is NO.

DB2_PARALLEL_IO. Possible values include * and Null (the default) for this registry variable, which specifies whether or not DB2 can use parallel I/O when reading or writing data to and from tablespace containers (even in situations where the tablespace contains only one container).

DB2_STRIPED_CONTAINERS. This variable is set to ON or Null (the default) to specify whether or not the tablespace container ID tag will take up a partial or full RAID disk stripe. When using RAID devices, the tablespace should be created with an extent size that is equal to, or a multiple of, the RAID stripe size. However, because of the one-page container tag, the extents will not line up with the RAID stripes. It may be necessary to access more physical disks than would be optimal during an I/O request unless this registry variable is set to ON.