2009 單車挑戰太平山
全國共有99個車隊組團參加,比賽車友有720人, 比賽起程路線從(樂水運動場)到(見晴觀景臺),沿途連續上坡全長28公里,更從海拔300公尺爬升到標高1900公尺, 競賽分為公路車組、登山車組兩大組別,公路車組限使用彎把公路車,登山組限使用平把車,另外還開放推廣組…
▍活動日期: 98年6月7日(星期日)
▍集合地點:樂水(樂水運動場)(集合、出發及頒獎點)
▍比賽路線:宜51線(樂水運動場)轉宜專1線至見晴觀景台,沿途連續上坡全長28公里(自海拔300公尺起爬升至標高1900公尺)。
▍路線概況:活動自樂水運動場出發,沿太平山公路前進,沿途連續上坡23公里(自海拔300公尺起爬升至標高1900公尺),途中於14.5公里處(白嶺)設飲水及食物補給站,到終點後憑號碼牌至起點換「餐點」。
一路都被超…![]() |
當時還有些力氣…自拍一下…![]() |
一路風景不錯 … 只是爬坡很辛苦 … 通常就是一個轉彎後就是一個陡坡
![]() |
![]() |
這是整場的路徑/時間圖 , 落後太多了….得要好好的練 bike 了 …
透過 TOR 作 SSH / MSN 跳板 ( socks4 )
要先裝好 tor , 啟動 tor 後 , 用 putty 照下面的設定就好了
這是透過 tor network 的出口點的 traceroute
8 r02-s2.tp.hinet.net (220.128.4.42) 3.919 ms r02-s2.tp.hinet.net (220.128.4.38) 3.863 ms 3.812 ms
9 r12-pa.us.hinet.net (211.72.108.193) 133.255 ms 133.232 ms *
10 r11-ny.us.hinet.net (202.39.83.105) 253.503 ms 253.630 ms 253.790 ms
11 US-NY-RI-01.chello.com (198.32.160.48) 258.488 ms 255.308 ms 259.752 ms
12 213.46.190.93 (213.46.190.93) 252.272 ms us-nyc01b-rd1-10ge-3-0.aorta.net (213.46.190.177) 252.482 ms 252.557 ms
13 213.46.190.50 (213.46.190.50) 258.266 ms * 258.407 ms
14 fr-par02a-rd1-pos-2-0.aorta.net (213.46.160.105) 339.525 ms 339.944 ms 339.758 ms
15 ch-gva01a-ra1-xe-1-0-0.aorta.net (213.46.160.26) 352.450 ms 352.673 ms 352.191 ms
16 mlrZHZ006-xge-3-4.aorta.net (213.46.171.54) 357.266 ms 362.542 ms 355.218 ms
17 * * *
18 80-218-145-22.dclient.hispeed.ch (80.218.145.22) 505.819 ms 508.504 ms 544.136 ms
Oracle , full-table-scans (FTS) problem
http://www.dba-oracle.com/t_sql_like_clause_index_usage.htm
Indexing when using the SQL "like" clause can be tricky because the wildcard "%" operator can invalidate the index. For example a last_name index would be OK with a "like ‘SMI%’" query, but unusable with "like ‘%SMI%’.
Solutions to this issue of a leading wildcard can be addressed in several ways::
- Oracle text indexes to remove full-table scans when using the LIKE operator.
Burleson Consulting 說:
These unnecessary full-table scans are a problem:
1. Large-table full-table scans increase the load on the disk I/O sub-system2. Small table full table scans (in the data buffer) cause high consistent gets and drive-up CPU consumption
非必要的 full-table-scans 造成幾個問題 : 大的資料表會增加 disk I/O , 小的資料表則是增加 CPU 消耗. 所以這個現象可以拿來觀察資料庫系統的問題點.
Tuning Oracle Full-table Scans
Oracle hint 用法 , database 優化 tunning
常見Oracle HINT的用法:
1. /*+ALL_ROWS*/
表明對語句塊選擇基於開銷的優化方法,並獲得最佳吞吐量,使資源消耗最小化.
例如:
SELECT /*+ALL+_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO=’SCOTT’;
2. /*+FIRST_ROWS*/
表明對語句塊選擇基於開銷的優化方法,並獲得最佳響應時間,使資源消耗最小化.
例如:
SELECT /*+FIRST_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO=’SCOTT’;
3. /*+CHOOSE*/
表明如果數據字典中有訪問表的統計資料,將基於開銷的優化方法,並獲得最佳的吞吐量;
表明如果數據字典中沒有訪問表的統計資料,將基於規則開銷的優化方法;
例如:
SELECT /*+CHOOSE*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO=’SCOTT’;
4. /*+RULE*/
表明對語句塊選擇基於規則的優化方法.
例如:
SELECT /*+ RULE */ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO=’SCOTT’;
5. /*+FULL(TABLE)*/
表明對表選擇全局掃描的方法.
例如:
SELECT /*+FULL(A)*/ EMP_NO,EMP_NAM FROM BSEMPMS A WHERE EMP_NO=’SCOTT’;
6. /*+ROWID(TABLE)*/
提示明確表明對指定表根據ROWID進行訪問.
例如:
SELECT /*+ROWID(BSEMPMS)*/ * FROM BSEMPMS WHERE ROWID>=’AAAAAAAAAAAAAA’
AND EMP_NO=’SCOTT’;
7. /*+CLUSTER(TABLE)*/
提示明確表明對指定表選擇簇掃描的訪問方法,它只對簇對像有效.
例如:
SELECT /*+CLUSTER */ BSEMPMS.EMP_NO,DPT_NO FROM BSEMPMS,BSDPTMS
WHERE DPT_NO=’TEC304′ AND BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;
8. /*+INDEX(TABLE INDEX_NAME)*/
表明對錶選擇索引的掃描方法.
例如:
SELECT /*+INDEX(BSEMPMS SEX_INDEX) USE SEX_INDEX BECAUSE THERE ARE FEWMALE BSEMPMS */ FROM BSEMPMS WHERE SEX=’M’;
select /*+INDEX(TBL_TOP_KEYWORD_DAY TBL_TOP_KEYWORD_DAY_XDATE)*/
to_char(xdate,’YYYY-WW’) X1 , sum(val) Y1
from TBL_TOP_KEYWORD_DAY
9. /*+INDEX_ASC(TABLE INDEX_NAME)*/
表明對錶選擇索引升序的掃描方法.
例如:
SELECT /*+INDEX_ASC(BSEMPMS PK_BSEMPMS) */ FROM BSEMPMS WHERE DPT_NO=’SCOTT’;
10. /*+INDEX_COMBINE*/
為指定表選擇位圖訪問路經,如果INDEX_COMBINE中沒有提供作為參數的索引,將選擇出位圖索引的布爾組合方式.
例如:
SELECT /*+INDEX_COMBINE(BSEMPMS SAL_BMI HIREDATE_BMI)*/ * FROM BSEMPMS
WHERE SAL<5000000 emp_no=”SCOTT” sex=”M” dpt_no=”V.DPT_NO”>V.AVG_SAL;
20. /*+NO_MERGE(TABLE)*/
對於有可合併的視圖不再合併.
例如:
SELECT /*+NO_MERGE(V) */ A.EMP_NO,A.EMP_NAM,B.DPT_NO FROM BSEMPMS A (SELECT DPT_NO,AVG(SAL) AS AVG_SAL FROM BSEMPMS B GROUP BY DPT_NO) V WHERE A.DPT_NO=V.DPT_NO AND A.SAL>V.AVG_SAL;
21. /*+ORDERED*/
根據表出現在FROM中的順序,ORDERED使ORACLE依此順序對其連接.
例如:
SELECT /*+ORDERED*/ A.COL1,B.COL2,C.COL3 FROM TABLE1 A,TABLE2 B,TABLE3 C WHERE A.COL1=B.COL1 AND B.COL1=C.COL1;
22. /*+USE_NL(TABLE)*/
將指定表與嵌套的連接的行源進行連接,並把指定表作為內部表.
例如:
SELECT /*+ORDERED USE_NL(BSEMPMS)*/ BSDPTMS.DPT_NO,BSEMPMS.EMP_NO,BSEMPMS.EMP_NAM FROM BSEMPMS,BSDPTMS WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;
23. /*+USE_MERGE(TABLE)*/
將指定的表與其他行源通過合併排序連接方式連接起來.
例如:
SELECT /*+USE_MERGE(BSEMPMS,BSDPTMS)*/ * FROM BSEMPMS,BSDPTMS WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;
24. /*+USE_HASH(TABLE)*/
將指定的表與其他行源通過hash連接方式連接起來.
例如:
SELECT /*+USE_HASH(BSEMPMS,BSDPTMS)*/ * FROM BSEMPMS,BSDPTMS WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;
25. /*+DRIVING_SITE(TABLE)*/
強制與ORACLE所選擇的位置不同的表進行查詢執行.
例如:
SELECT /*+DRIVING_SITE(DEPT)*/ * FROM BSEMPMS,DEPT@BSDPTMS WHERE BSEMPMS.DPT_NO=DEPT.DPT_NO;
26. /*+LEADING(TABLE)*/
將指定的表作為連接次序中的首表.
27. /*+CACHE(TABLE)*/
當進行 full scan 時,CACHE提示能夠將表的檢索塊放置在緩衝區緩存中最近最少列表LRU的最近使用端
例如:
SELECT /*+FULL(BSEMPMS) CAHE(BSEMPMS) */ EMP_NAM FROM BSEMPMS;
28. /*+NOCACHE(TABLE)*/
當進行 full scan 時,CACHE提示能夠將表的檢索塊放置在緩衝區緩存中最近最少列表LRU的最近使用端
例如:
SELECT /*+FULL(BSEMPMS) NOCAHE(BSEMPMS) */ EMP_NAM FROM BSEMPMS;
29. /*+APPEND*/
直接插入到表的最後,可以提高速度.
insert /*+append*/ into test1 select * from test4 ;
30. /*+NOAPPEND*/
通過在插入語句生存期內停止並行模式來啟動常規插入.
insert /*+noappend*/ into test1 select * from test4 ;
sqlrelay sample code / prepare statement / bind value 寫法
include dirname(__FILE__) . '/local_config.php'; $__oradb=_fn_connect_sqlrelay(); $__oradb->setOption('portability', DB_PORTABILITY_LOWERCASE); $sql = ' select g_no,ctrl_rowid,g_storage,g_img from goods_file where g_no=? '; foreach ( $items as $g_no => $v ) { $prepare = $__oradb->prepare($sql); $result = $__oradb->execute($prepare,$g_no); if ( $result ) { $row = $result->fetchRow(DB_FETCHMODE_ASSOC); $items[ $g_no ]['ctrl_rowid'] = $row['ctrl_rowid']; $items[ $g_no ]['g_storage'] = $row['g_storage']; $items[ $g_no ]['g_img'] = $row['g_img']; $result->free(); } else continue; } $__oradb->disconnect();
2009 5/31 海上長泳 – 迎向龜山
又發生豬頭事件, 帶了 GPS logger 下水 , 但是忘記按 start …
約游 3000M , 1小時14分
今早上約 8:40 下水 , 以下氣象局的資料作為浪大小的參考, 因為今天的浪特大 , 連衝浪客都來了, 可想而知靠近沙灘的浪有多大 , 看到很多人一再被浪推回岸上… 游到一半竟然有水母, 被咬了幾次 @@ , 記得去年沒有水母呀? 發現我剛開始有游歪了但是沒有軌跡可證實, 一直往外海游去 , 直到發現怎麼靠最外側的救生艇太近才往內游.
龜山島浮標 | |||
---|---|---|---|
觀測 時間 |
浪高 (公尺) |
週期 (秒) |
浪向 (度) |
05/31
13:00 |
0.8
|
7.4
|
45
|
觀測時間
|
風力(級)
|
風向
|
陣風(級)
|
05/31
13:00 |
2
|
東北
|
3
|
觀測時間 | 氣溫:(°C) |
---|---|
05/31
13:00 |
25.1
|
觀測時間 | 海水表面溫度 (°C) |
---|---|
05/31
13:00 |
24.8
|
龜山島浮標 | |||
---|---|---|---|
觀測 時間 |
浪高 (公尺) |
週期 (秒) |
浪向 (度) |
06/01
12:00 |
0.4
|
4.9
|
78
|
06/01
11:00 |
0.5
|
5.1
|
56
|
06/01
10:00 |
0.5
|
5.4
|
33
|
06/01
09:00 |
0.6
|
5.5
|
45
|
06/01
08:00 |
0.6
|
5.7
|
90
|
06/01
07:00 |
0.5
|
6.0
|
78
|
06/01
06:00 |
0.5
|
5.5
|
146
|