The load utility of DB2 is a strange thing as it does certain things much faster than using the command line processor but on the other hand goes different transactional ways to complete its work.
One outcome of a load process gone wild (or rather: being interrupted before completing its work) could be that it leaves the tablespace in the state "Backup Pending. Load in Progress" (0x0820) with which DB2 notifies that it still needs a backup, recovery or rollforward usually done by load.
You still can access the tablespace, but any structural/transactional change will be denied due to the status (note that the status of all the associated tables could be "normal") of the tablespace.
For a concise overview of the backup/recovery levels and strategies of DB2 you could have a look at this page.
Mittwoch, 25. November 2009
DB2 buffer pool "4096" has no more pages
Yesterday, we found a customer´s database in a strange state. Whenever doing some of the more bandwith-demanding ETL operations, we were presented with the annoying error message:
After some internet search, we found out that these ids belong to buffer pools (so called hidden, for most serious cases under-dimensioned buffer pools - kind of replacement tires) that are not officially assigned to the relevant tablespaces, but that get used once the memory manager cannot start the actually assigned pools, e.g., due to memory shortage.
The database finally had to be restarted (online activation of the buffer pools did not work) in order to get the state back to normal.
Operation could not be performed, because buffer poolhas no more pages left.
After some internet search, we found out that these ids belong to buffer pools (so called hidden, for most serious cases under-dimensioned buffer pools - kind of replacement tires) that are not officially assigned to the relevant tablespaces, but that get used once the memory manager cannot start the actually assigned pools, e.g., due to memory shortage.
The database finally had to be restarted (online activation of the buffer pools did not work) in order to get the state back to normal.
Date Type Conversion When Federating Oracle into DB/2
Federation (or DB-Link depending on the target DWH platform) is a most convenient way to connect your staging area to your data sources.
There is the golden rule not to stretch the tempting, modern capabilities of that feature to much, hence to first replicate, then transform the data.
There are nevertheless a few issues left that may still hurt you mostly around the builtin data type conversions, especially when formulating the mostly temporally constrained replication conditions.
So, DB2 9.5 represents oracle´s DATE as a TIMESTAMP - hence be sure to use CURRENT_TIMESTAMP instead of CURRENT_DATE!
There is the golden rule not to stretch the tempting, modern capabilities of that feature to much, hence to first replicate, then transform the data.
There are nevertheless a few issues left that may still hurt you mostly around the builtin data type conversions, especially when formulating the mostly temporally constrained replication conditions.
So, DB2 9.5 represents oracle´s DATE as a TIMESTAMP - hence be sure to use CURRENT_TIMESTAMP instead of CURRENT_DATE!
Abonnieren
Posts (Atom)