西班牙奪冠

西班牙在延長賽 116  分鐘終於進球，1:0 擊敗荷蘭。
章魚哥神準再度命中，連季軍賽都猜德國獲勝。
德國以 3:2 贏烏拉圭。

荷蘭與西班牙爭冠

都是新手喔！其中西班牙第一次爭冠軍。

荷蘭 3:2 贏烏拉圭
西班牙 1:0 贏德國

德國的章魚保羅再度神準預測正確！

台股定期定額投資的報酬概算

約莫十一、二年前，台股第二次上萬點，當時有本投資暢銷書，提了一個傻瓜投資術「隨便買、隨時買、不要賣」後來隨著網路泡末，股市崩盤，死抱著股票的投資人通通陣亡之後，這個口訣也成了笑話一則。
不過真的沒有「只求溫飽」的傻瓜投資術嗎？其實我覺得那個口訣還是有用的。
「隨便買」股票，改成投資基金或指數型基金，因為夠分散，不怕一兩支股票變成壁紙。
「隨時買」，雖然上萬點的的確不是買股的好時機，但是跌到四千你反到不敢進場。對於呆呆的散戶來說，定期定額不失為強迫投資的方法。
「不要賣」，如果能看出股價漲的太超過，還是可以賣一下。如果當個呆呆的散戶，這部份的投資是省下來當作未來的退休金，繼續抱著也無妨。

只是這樣真的能賺到錢嗎？從萬點跌下來真的還可以存到退休金嗎？
找一些實際的資料來算算報酬吧。有兩個實際的基金，群益店頭與群益馬拉松，另外加上台股加權報酬指數、台灣五十報酬指數。這個「報酬指數」跟一般指數有何不同？主要是因為公司會發現金股息，指數就會因為股票的市值減少而減少點數。但是這個股息也是投資人的報酬，所以證交所另外編列所謂「報酬指數」，就是包含股息的報酬。所以一般基金公司跟大盤比較績效時，都用一般的指數，其實有點偷機取巧。

計算定期定額投資三年與五年的報酬率。計算的方式是模擬每個月的最後一個交易日投資固定金額，然後以最後一次投資之後的一個月的淨值，計算過往三年或五年的累積報酬率。
因為資料來源的關係，看四個時間點，第一個是2008年四月底的相對高點，第二個是2008年十一月的低點，第三個是2009年十二月底，反彈後的高點，第四個是最近的2010年六月底

五年定期定額

日期	加權 報酬指數	台灣五十 報酬指數	群益店頭 基金	群益馬拉松 基金
2008M04	50.06%	42.92%	45.81%	57.55%
2008M11	-25.66%	-27.53%	-26.75%	-21.70%
2009M12	34.69%	26.58%	50.06%	22.00%
2010M06	15.34%	7.1%	27.20%	-0.37%

三年定期定額

日期	加權 報酬指數	台灣五十 報酬指數	群益店頭基金	群益馬拉松 基金
2008M04	30.30%	25.30%	16.90%	23.67%
2008M11	-34.91%	-35.93%	-40.10%	-37.94%
2009M12	24.32%	19.34%	35.38%	9.44%
2010M06	9.76%	4.02%	21.58%	-3.73%

在2008年四月的高點，以加權指數來說，五年與三年分別有50.06%與30.3% 的報酬率，粗略換算平均投資2.5年與1.5年的年化報酬率，是 17.63% 與 19.3%，還不錯吧。
雖然2008年底跌得這麼慘，但是到了2009年五月左右，無論是三年或五年的投資都轉為正報酬，五年定期定額的負報酬時間約七個月，三年的負報酬時間長一點，約八到九個月。等到風暴過去，接著到了2009年年底，又有不錯的獲利率。

這樣的投報率雖然不會令人有中樂透的快感，但是卻可以看出，長期下來，股市的風險並不像大家想像這麼大，卻能提供遠高於定存的獲利。或許大家應該可以考慮不要把太多錢放在銀行，該拿出來投資投資了。

補充一下，實際上沒法投資「加權報酬指數」，目前台灣只有一檔「寶來加權股價基金」追蹤台股指數。但是與「加權報酬指數」的報酬有一些落差。而「台灣五十」就是去買台灣五十ETF。
至於一般基金，則有「時好時壞」的風險。像群益馬拉松，最近一年就落後大盤不少。

四強出列

烏拉圭、荷蘭、德國、西班牙。

其中荷蘭 2:1 贏巴西，德國 4:0 贏阿根廷，西班牙 1:0 贏巴拉圭。
烏拉圭跟迦納踢和，pk 賽 4:2 勝。

德國的防守很到位，阿根廷沒法像之前隨心所欲的進攻。反倒是阿根廷的防守鬆懈，德國逮到機會就進球了。

烏拉圭球員在120分鐘時以手球加紅牌阻止迦納進球，但是迦納的十二碼球踢到門柱，之後在pk賽又兩球未進。十二碼球真的是考驗球員的心理素質啊！

西班牙跟巴拉圭在一分鐘內各有一次十二碼球機會，都沒進。大家的確緊張。

巴西在下半場似乎被荷蘭弄的心浮氣躁，進攻節奏亂了章法，跟上半場差很多。在 1:2 落後時，還因為一時氣憤踹了對方一腳而吃了一張紅牌，這下子少一人就真的回天乏術了。

清除 SQL replication DB 的 log 檔案

MS SQL 的 log 檔很煩，一般情況下，可以用以下指令騰出空間：

backup log [dbname] with truncate_only

use [db]
dbcc shrinkfile ([dbname_log], size)

可是，如果這個 db 是從另一台 SQL server 複寫而來的，執行 backup log 指令時，會出現以下錯誤訊息：
"The log was not truncated because records at the beginning of the log are pending replication. Ensure the Log Reader Agent is running or use sp_repldone to mark transactions as distributed."
即使刪掉 replication 設定也沒用。

後來找了一下，發現以下方法：
(1) sp_replicationdboption 'database name','publish',true
(2) EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,    @time = 0, @reset = 1
(3) sp_replicationdboption 'database name','publish',false
確認沒有 replicated transactions :
(4) dbcc traceon(3604)
(5) dbcc opentran

就可以縮小 log 檔案了。

之後再重新設定 replication 就大功告成。

後記：似乎不是 replication 而來的 db 會有這個問題。因為今天可以直接執行 backup log 指令，另外一台 db 也可以。所以我也不知道原來為何不行。總之，之後如果再遇到一樣的問題，就這樣解決就對了，人生還有很多有趣的事情，不用在這裡浪費時間啊！