1.系统表SYSIBM.SYSCOLUMNS

可获得表的字段类型，长度等信息

SELECT * FROM SYSIBM.SYSCOLUMNS WHERE TBNAME = '表名' AND TBCREATOR = 'schma名' ORDER BY COLNO FOR FETCH ONLY WITH UR

?

2. FOR FETCH ONLY WITH UR

UR stays for Uncommited Read. If you use it, you may get some pieces of information that are "out of date". DB2 will not lock the pages you're reading.
With FOR FETCH ONLY, you're saying to DB2, that you do not intend to update the rows you are reading. DB2 will try to avoid locking the pages you are reading, but will only give you "clean" pages, i.e., pages that are allready commited.

?

3. 索引系统表

?

4. command line 建立远程数据库连接

?

5. OPTIMIZE FOR n ROWS

Example: Suppose that you query the employee table regularly to determine the employees with the highest salaries. You might use a query like this:

SELECT LASTNAME, FIRSTNAME, EMPNO, SALARY
  FROM EMP
  ORDER BY SALARY DESC;

An index is defined on column EMPNO, so employee records are ordered by EMPNO. If you have also defined a descending index on column SALARY, that index is likely to be very poorly clustered. To avoid many random, synchronous I/O operations, DB2 would most likely use a table space scan, then sort the rows on SALARY. This technique can cause a delay before the first qualifying rows can be returned to the application.

If you add the OPTIMIZE FOR n ROWS clause to the statement, DB2 will probably use the SALARY index directly because you have indicated that you expect to retrieve the salaries of only the 20 most highly paid employees.

Example: The following statement uses that strategy to avoid a costly sort operation:

SELECT LASTNAME,FIRSTNAME,EMPNO,SALARY
  FROM EMP
  ORDER BY SALARY DESC
  OPTIMIZE FOR 20 ROWS;

Effects of using OPTIMIZE FOR n ROWS:

• The join method could change. Nested loop join is the most likely choice, because it has low overhead cost and appears to be more efficient if you want to retrieve only one row.
• An index that matches the ORDER BY clause is more likely to be picked. This is because no sort would be needed for the ORDER BY.
• List prefetch is less likely to be picked.
• Sequential prefetch is less likely to be requested by DB2 because it infers that you only want to see a small number of rows.
• In a join query, the table with the columns in the ORDER BY clause is likely to be picked as the outer table if there is an index on that outer table that gives the ordering needed for the ORDER BY clause.

z

?

?