alert加斷行符號

找了很久 ，但是...沒錯只要下面這樣子...

alert('您有＊欄位未填，請回上頁填寫。\r\nItem(s) with ＊ unfilled. Please return to the previous page.');

告知網路搜索引的文件 Robots.txt - 網路搜尋技術

今天在跟朋友聊天的時候聊到了，最近google 就是因為搜尋功能太強了，反而造成小網站入口網，流量不大，但是內容都被google 搜尋出來，大家都只看內頁，反而造成小網站的可見度降低，但是內容都暴光的問題，因此得知了一種網路默許搜索文件「robots.txt」

以下是簡單的說明：

robots.txt 是以簡單的 ASCII文字檔 robots.txt 以此小寫字母的文件檔案存放於網站根目錄中，告知進入的網路搜尋引擎，網站裡面可以被搜詢和禁止的內容部份，下面稍微簡單列一下用法：

1. 最簡單的網頁告知禁止抓取內容
<meta name="robots" content="noindex,nofollow" />

這個協定也不是一個規範，而只是約定俗成的，通常搜索引擎會識別這個元資料，不索引這個頁面，以及這個頁面的鏈出頁面。

2. 使用robots.txt 規範

讓所有機器人訪問所有檔因為通配符"*"明所有機器人：
User-agent: *
Disallow:

攔截所有的機器人：
User-agent: *
Disallow: /

禁止所有機器人訪問特定目錄：
User-agent: *
Disallow: /cgi-bin/
Disallow: /images/
Disallow: /tmp/
Disallow: /private/

僅禁止壞爬蟲訪問特定目錄：
User-agent: BadBot
Disallow: /private/

相關資料
‧維基百科
‧Googlebot

html 轉unicode 顯示

最近在網站中要顯示中文，於是上網找了轉碼的方式，
以下是資料來源：

Unicode and HTML

來源：JavaWorld

//將中文轉成 16 進位 unicode 表示法,會得到像是 \u4E2D
out.print("
中 16 ="+"\\u"+Integer.toHexString("中華".charAt(0) & 0xffff));

//將中文轉成 10 進位 unicode 表示法(中括弧請自行拿掉,這裡加中括號是怕此處網頁顯示不出unicode)會得到像是 [&#]20013[;] 的結果
out.print("
中 10 ="+"[&#]"+("中華".charAt(0) & 0xffff)+"[;]");
//或是 Integer.parseInt("4E2D",16) 也可以得到 20013

//將 unicode 轉回中文, 此處結果會是一個[中]字,當然,如果要將非 big 5 碼的 unicode 字寫入 ASCII 格式檔案中,是會變成亂碼的,所以輸出檔案格式要設定,如果是輸出在網頁上,就無所謂了
char c_Back = (char)Integer.parseInt("20013");
StringBuffer STSTR = new StringBuffer();
STSTR.append(c_Back);
out.print("
結果="+STSTR.toString());


發現這樣轉中文部份還是亂碼，暈了orz
不過發現在URL中，中文部份是正常的

用以下方法二：
java.net.URLEncoder.encode (tmpValue[1])
java.net.URLEncoder.encode (tmpValue[1],"UTF8")

不過還是不行阿，想想搞不好是因為在filter裡面有在進行轉碼的動作嗎?
拿掉之後測試還是失敗了，orz

是因為URL傳值的關係嗎?
被打敗了

程式設計師的格言

來源：程式設計師的格言（盜作不少）

譯自
http://www2.biglobe.ne.jp/~oni_page/other/etc/pr03.html
http://mixi.jp/view_community.pl?id=1772737

(版本2 2008/10/12更新)

譯註
SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
程式設計師多半自己不面對客戶。
跟PM又不一樣。（有什麼比較貼切的職稱翻譯嗎？）

—————

1
每天有24小時。
所謂的「今天之內」，是指到明天早上為止。

2
程式不會照自己所想的跑。只會照所寫的跑。

3
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。

4
我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare

5
程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！

6
畫面藍了。

7
先說「沒辦法」的人贏。

8
有意見的話你寫

9
要殺一個程式設計師不需要刀，改三次規格就好

10
首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）

11
開發沒有終點。只有釋出(release)。

12
無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。

13
客戶總是覺得水跟追加需求是不用錢的。

14
付錢愈計較的客人愈囉唆。

15
在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。

16
一個人掛了大家都掛了。

17
bug過了一晚可能就變成規格了。

18
好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。

19
客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。

20
對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。

21
顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。

22
很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。

23
品質的劣化程度依規格改變的次數與規模而定。

24
業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。

25
有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。

26
程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。

27
程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。

28
對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。

29
程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。

30
SE需要持久力，程式設計師需要爆發力。

31
準時離開公司，工作會變多。

32
完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。

33
詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。

34
還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。

35
程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。

36
所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…

37
地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。

38
遠處的火災一定燒到這裡。

39
禱告，然後跑吧。

40
程式不是用腦記的，要用身體記住。

41
明天能放假的話死了也罷。

42
外面有下雨耶，昨天開始下的嗎？

43
若不能心靜不移，身體會掛。
若不讓自己殘忍，自己會被殺。

44
客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）

45
（日文文字遊戲）
SE總是不負責的說「別逞強」，
業務總是無理取鬧不准說「沒辦法」。

46
規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。

47
再嘮嘮叨叨下去也是要付錢的。

48
多想個10秒鐘，你可以不說「嗯，這個做得到」。

49
人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。

50
老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。

51
所謂交案期限，是指開發現場從公司換到客戶那裡的日子。

52
程式、SE、經理不是職務。是逃不掉的責任。

53
業務是最難搞的客戶。

54
能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley

55
漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…

56
上線後的除錯才叫做bug。

57
追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。

58
除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。

59
不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。

60
要解決地獄的辦法，就是客戶把錢交出來。

61
不懂電腦的操作者是發現bug的天才。而且無法重現。

62
每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。

63
搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）

64
啊，那是微軟的規格。

65
程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）

66
程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。

67
正因為健康，才能做不健康的事。

68
規、規格、是規格啦。不過有一點跟規格不太一樣啦。

69
那是你說的規格。

70
開發室沒有窗戶，那是因為以前…

71
爛了也是因為規格。

72
SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）

73
為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。

74
不會動的bug就只是普通的bug。（會動的bug則能視為規格）

75
今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。

76
客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。

77
唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。

78
共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。

79
如果可以改行的話，想找個準時下班不叫「逃跑」的工作。

80
對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫租這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。

81
設計者應該是不該要求製作者製作出超過設計以上內容的吧…

82
無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。

83
SE對程式設計師說的「常識」每三小時變一次。

84
自己看規格書。不能跑的是規格。

85
「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。

86
工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。

87
能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。

88
累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）

89
試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。

90
REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。
（譯註：我比較煩惱 Linux）

91
有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。

92
小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路

93
「不要讓老闆當業務比較好」

94
說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。

————————

ex 1
就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。

ex 2
規格與規格書是不同的東西。

ex 3
比期限更重要的是靈感與睡眠。

ex 4
比知識與經驗重要的是手冊與時間。

ex 5
能動就好了，能動的話…

ex 6
過了三天就是別人寫的程式碼。

ex 7 (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！

ex 8 (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！

ex 9
漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了

ex 10
bug與規格是一體兩面

ex 11
電腦裡沒有bug，bug常在人心。

ex 12
無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)

ex 13
估價需要1%的經驗與99%的直覺

ex 14
沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。

ex 15
・『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
・『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
・『PM』＝每天修改自己定下的行程表的人
・『業界老鳥』＝臉色蒼白缺乏表情的人
・『外包』＝幫不會寫程式的正職員工寫程式的人
・『coding』＝複製貼上的工作
・『單體測試』＝指開始寫程式
・『除錯』＝把程式碼註解掉的工作
・『新同事』＝在火燒屁股的專案火上加油的人
・『出貨日』＝把只完成一半的系統上線的日子
・『末班電車』＝業界平均的下班時間
・『颱風假』＝一年一度可以準時下班的業界假日

ex 16
當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）

ex 17
最終手段
「重開機」
意外的常常都很有效

ex 18
最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」

ex 19
「程式碼的可信度，不會比寫的人還可信。」

ODBC, OLEDB, ADO 的差異

http://gordonliwei.spaces.live.com/Blog/cns!CCE1F10BD8108687!2629.entry
作者:李維 Delphi專家
重點:ODBC, OLEDB, ADO 的差異


在我的認知中OLEDB應該不可能比ODBC快，為什麼?這是一個故事，也是ODBC，OLEDB，ADO和dbExpress各自發展的原因，因此我們需要對於這些資料存取技術的背景有一個簡單的瞭解。

ODBC當初是MS為了在Window下提供一個共通的資料存取技術而發展出來的，目的是突破當時三大資料庫廠商Oracle，Sybase和Informix對於MS的SQL Server的圍堵，此外MS也想藉由這個共通的資料存取技術幫助MS Access擊倒Lotus和Approach，因此最早的ODBC的策略是提供一個最小公約數API，讓一個標準可以存取所有的資料庫，因此在ODBC的初期ODBC的效率很緩慢，因為除了實作技術不成熟之外，當時MS SQL Server的功能也不好，因此以SQL Server為中心思想發展出來的最小公約數ODBC在存取其他資料庫時簡直慢的不想話，這也是為什麼後來Borland發展出了BDE/IDAPI之後在功能和效率方面都比ODBC好上一大截的原因。但是當MS Server SQL逐漸成熟，ODBC的實作技術也慢慢成熟之後，以最小公約數為發展中心的ODBC因為功能最簡單，因此負荷最小，到了最後ODBC的效率是最好的資料存取之一。

OLEDB是當時MS想把COM/DCOM/COM+技術推為Windows平台的唯一技術時發展出來的，如此一來在Window平台所有的通訊，資料存取和元件都以COM/DCOM/COM+為核心，因此一度Borland也準備以COM/DCOM/COM+發展IDE，資料存取等。MS當時為了這個原因，因此有了OLEDB，但是舊的ODBC怎麼辦? 因此又發展出了ODBC和OLEDB Adapter的技術，讓ODBC也可以執行在COM/DCOM/COM+的世界，讓資料存取端認為ODBC也是OLEDB。OLEDB為什麼不會比ODBC快? 因為OLEDB功能比較多，而且OLEDB是以Ole Automation封裝傳遞的資料，負荷比ODBC大，因此ODBC應該會比較快。

至於ADO則是後來MS為MS Access，MS SQL Server特別在Windows平台發展出來的存取技術，因為當時由於Internet/Intranet的沖擊，MS的COM/DCOM/COM+不適合使用在Internet/Intranet上，因此MS逐漸準備放棄COM/DCOM/COM+，這也是OLEDB的長日將盡之日，ADO接手演出之時。ADO和ODBC不同的地方是，ADO再也不是使用最小公約數為中心，而是完全以MS的資料庫為核心，這也是為什麼當ADO推出後其他廠商並不熱衷支援ADO，我記得當時Oracle拒絕推出ADO For Oracle，MS迫不得已自己為Oracle寫了ADO驅動程式，但是又慢臭蟲又多，而Borland也決定繼續發展BDE/IDAPI，只是為ADO做簡單的封裝處理，但Delphi/BCB仍然以BDE/IDAPI為核心資料存取技術。

由於ADO不是使用最小公約數為中心，因此功能比ODBC多太多了，例如資料連結池，執行緒池，可分段存取資料，資料存取到用戶端時不是把所有記錄中的資料存取到用戶端，而是只把Key存取到用戶端，一旦當用戶端實際需要整筆資料時才藉由Key把資料存取到用戶端。因此如果只是簡單的單一用戶端存取資料測試，ADO不一定會比ODBC快，但是應該差不多，不過在實際的應用中，ADO應該是比ODBC整體效率快，但是記得ADO是為了MS的資料庫而生的，因此如果是使用ADO在其他廠商資料庫上則不一定。這是為什麼一些資料庫管理工具如果是管理多種不同的後端資料庫，那麼大多仍然是使用ODBC，為什麼? 因為簡單，因此穩定一點，所以快一點。例如Embarcadero的產品就是使用ODBC來管理後端多種資料庫。

OK，討論到這裡你應該知道ODBC，OLEDB和ADO的使用時機了。

現在回到dbExpress，dbExpress是為了跨平台發展出來的資料存取技術，不是為了特定的資料庫，也不是只為了Window 32平台。dbExpress可以執行在Win32，.NET，Win64，Linux，可以存取MS，Oracle等以及CodeGear自己的InterBase和BlackfishSQL。而dbExpress是結合跨平台和一些目前用戶端先進的資料存取概念為中心，例如dbExpress也提供連結池，執行緒池等。

OK，因此如果你使用dbExpress和ADO來比較存取MS的資料庫，那麼一定是ADO快一點，為什麼? 因為ADO是為了MS的資料庫而生。
如果你使用dbExpress和ODBC進行單一簡單的資料存取比較，那麼ODBC快一點，因為ODBC功能少，負荷少。但是在比較多的用戶端進行比較複雜的資料處理時，dbExpress就比ODBC表現的好多了，這和ADO比ODBC是類似的。
如果你想使用一種統一的資料存取技術，不管對於什麼平台，什麼資料庫都有良好的執行速度，因此當你改變資料庫時你的執行效率仍然很穩定，那麼dbExpress是王者。
ODBC，ADO和OLEDB已停止開發，因此如果你想使用一種仍然在開發之中而且能夠應用在未來Win64和多核心，多執行緒的世界，那麼dbExpress是比較好的解決方案。

Sybase ASE 常見問與答

來源


ASE 安裝過程中，安裝程式一直停留在初始化資料庫這一步，無法繼續

這是一個莫明其妙的 bug，在初始化庫的過程中，tempdb 滿了！
　　解決方法：
　　　　此時，ASE 服務實際已經啟動，因此，可以通過 isql 登錄，然後修改 tempdb 的大小：
　　　　1. 在命令行下鍵入以下命令，注意斜體部份用實際服務名代替：
　　　　　c:\>isql -Usa -S 服務名
　　　　2. 鍵入下面下劃線的命令：
　　　　　1>alter database tempdb on master ="2M"
　　　　　2>go


為什麼生產環境不要設置 truncate log on checkpoint？
　　有些用戶貪圖簡便，在生產環境中設置了 truncate log on checkpoint 。其原意不外是避免因寫滿日誌而導致的業務停頓。殊不知，這樣的設置可能帶來不可挽回的災難。因為當事務被截斷後，從最近一次全備到當前的事務均不可能再恢復了！如果這期間出現問題，如磁片損壞，則將導致大量資料丟失。
　　在生產環境中，應通過配置合理的備份策略來進行全備和增量備份。典型的策略是每週一次全備，每天一次增量備份。用戶應根據自身應用的實際情況（資料量、資料增量、資料重要性等因素），合理調整，如改為一天兩次增量備份。如果需要大量導入資料，可能寫滿日誌，那麼可能臨時設置 truncate log on checkpoint，但需要注意的是：完成資料導入後，應立即取消此設置，並馬上進行全備。　　


如何分離日誌與資料？
　　１、備份資料庫，包括 master 和你要分離資料與日誌的應用庫（廢話，根據 Sybase ASE 系統管理員日常維護指南，這一步是必不可少，以至於不用寫出來的步驟）；
　　２、檢查日誌是否有單獨的存放設備，如有，則直接到第５步；
　　３、增加一個設備：disk init .....；
　　４、alter database db_name log on new_log_device=xxx
　　５、sp_dropsegment logsegment, db_name, device_name
　　６、查看是否已分離（sp_helpdb或sp_helplog）；
　　 需要注意的是，執行 sp_helplog 會提示以下類似資訊：
No valid log device can be found to contain the starting logpage of 'xxxx', on database 'xxxxx'. Perhaps the segment mapping of database has changed recently. Please inspect the sysusages catalog and contact your system administrator.
　　你大可不必緊張。段（segment）只是管理以後如何為物件分配空間，增加和刪除 segment 並不移動當前的已分配空間。日誌至少有一個擴充（extend）位於以前的 segment 上（還記得嗎，為物件分配存貯單元時，實際是以 extend 為單位的。）。如果當前 extend 被填滿，需要再為日誌分配時，ASE會在新的 segment 上分配（segment 約束它不得不這麼做）。此時，截斷日誌就可以回收以前分配的 extend 了。
　　７、因此，如果不想看到 sp_helplog 的“錯誤輸出”，你可以創建一個臨時表，然後往面插入足夠的資料，然後截斷日誌；
　　８、老規矩，也是很重要的一步：備份資料庫，包括 master 和你分離資料與日誌的應用庫。


如何刪除tempdb資料庫在master設備上的記錄？
摘自 hobbylu 的博客。
sp_dropsegment 'system','tempdb','master'
go
sp_dropsegment 'default','tempdb','master'
go
sp_dropsegment 'logsegment','tempdb','master'
go
begin tran
delete from sysusages where dbid=2 and segmap=0
go
update sysusages set lstart=0 where dbid=2(注意這裏僅僅只考慮了一個tempdb設備的情況)
commit
go


新安裝ASE或新建服務後，用戶端無法連接伺服器
　　在安裝完 ASE 或新建服務後，伺服器上能使用 dsedit 連接資料庫服務，但用戶端無法連接。
　　通常的原因是資料庫服務綁定了 127.0.0.1，使用 dsedit，或直接修改 interfaces 檔，綁定確實的 IP 即可。


新安裝ASE或新建服務後，無法連接備份伺服器
　　在安裝ASE或新建服務後，試圖 load 或 dump 資料庫時，總是提示如下資訊：
Can't open a connection to site 'SYB_BACKUP', See the error log file in the SQL Server boot directory.
error code = 7205
　　通常，這是由於 ASE 安裝／服務初始化程式的 BUG 導致的。在創建服務時，ASE 會創建一個名為類似 XXXX_BS 的備份服務，同時會在 master..sysservers 中插入一條對應記錄。以服務名 FLYBAEN 為例，下面是 interfaces 檔和 sysservers 中的記錄：
　　interfaces 檔內容：
FLYBEAN_BS
master tcp ether FLYBEAN_LINUX 5001
query tcp ether FLYBEAN_LINUX 5001

sysservers 的記錄：(select srvname, srvnetname from sysservers where srvname='SYB_BACKUP'）
srvname srvnetname
------------------------------ --------------------------------
SYB_BACKUP FLYBEAN_BS
　　通常默認的備份伺服器就是 SYB_BACKUP 。在 load/dump 時，ASE 通過 sysservers 獲取備份伺服器對應 interfaces 的資訊，然後在 interfaces 檔中搜索該服務的實際位置（IP和埠）。在此例中，ASE 通過 sysservers 得到 interfaces 中的服務名為 FLYBEAN_BS，然後在interfaces 中獲取該服務的物理資訊。如果 ASE 無法通過 sysservers 中的 srvnetname 在 interfaces 中獲取相關資訊，則會報上面的錯誤。
　　那麼解決辦法就是非常簡單的。
　　方法一：修改 interfaces 檔，將服務名改為 sysservers.srvnetname 對應的值；
　　方法二：修改 sysservers 中相應記錄的 srvnetname 的值為 interfaces 檔中的服務名。


如何配置異地備份？
　　自 12.5.0（12.0是否支持待確認） 開始，ASE 支持異地備份，具體方法舉例如下：
　　假設兩台 ASE 資料庫伺服器，分別為 A 和 B，資料庫服務分別為： SRV_A, SRV_A_BS; SRV_B, SRV_B_S 。我們要把 B 上的資料庫 DB_1 備份到 A 上。
　　1. 修改 B 上的 interfaces 檔，增加 SRV_A_BS 的配置，如：
　　　　SRV_A_BS
　　　　　　master tcp ether A BS_PORT
　　　　　　query tcp ether A BS_PORT
　　2.用 isql 登錄 SRV_B，為 SRV_B 增加一個遠端服務：SRV_A_BS
　　　　sp_addserver "SRV_A_BS",null,"SRV_A_BS"
　　3.測試：dump database DB_1 to 在 A 上的路徑及檔案名 at "SRV_A_BS"

系統崩潰了，沒有備份，但設備檔還存在，如何恢復資料庫？
　　有的時候，系統崩潰了，手上也沒有資料庫的備份或者是備份太舊了，但僥倖的是設備還在，並且是完整的，這時可以通過檔COPY的方式恢復資料庫。
　　情況一、所有設備，包括 master ，均是完整的：
　　這種情況是最簡單的，只需要先備份設備檔（包括master，copy 到安全的地方），然後重新安裝系統，建服務（保持頁面大小、編碼和排序與以前一樣），然後停止服務，按原目錄將所有設備檔拷貝回來，再重啟服務即可。新建的服務名可與舊服務不同。建議把 服務名.cfg 也複製過來，省掉參數配置。
　　 情況二、應用的設備是完整的，但沒有master了：
　　方法一、這種情況下要恢復資料庫就需要原來的設備使用情況表了。重新安裝系統，建服務，然後按原設備情況建設備（大小、位置保持和原來一致），接下來根據記錄下來的設備使用情況建庫，順序以及佔用的空間要和以前的一致。然後停服務，將應用的資料庫設備複製回來，重啟服務即可。請參考Sybase ASE 系統管理員日常維護指南的建議，定期備份 master 資料庫。
　　方法二、
　　1.重新創建 master 設備
　　　buildmaster -dthe_full_path_of_master_device -sthe_size　12.5版本以下
　　　dataserver -b （Windows: sqlsrvr -b）12.5（含12.5）以上　
　　2.檢查並修改 RUN_XXX 檔，指向新創建的 master.dat，並增加 -T3608
　　3.命令行啟動服務
　　4.調整 master 庫的大小（可選）
　　5.重新構建 master..sysdevices 數據
　　　disk reinit name="device_name", physname="full_path_of_device", vdevno=device_no,size=size_of_device
　　6.重新構建 master..sysusages 數據
　　　disk refit
　　8.修改恢復回來的資料庫名
　　9.使用 isql，安裝 master 和 model
　　10.創建登錄和用戶
　　11.去除 RUN_XXX 檔中的 -T3608 標誌，重啟動服務


忘記了sa的密碼，怎麼辦？
　　修改RUN_XXXX腳本，在其後面添加 -psa，然後在命令行運行該腳本，ASE會給出重新生成的密碼，用此密碼登錄並修改。
　　注意：修改密碼後，應及時去掉添加的-psa。


調整參數後，ASE 無法啟動
　　這是由於參數配置不正確，導致無法啟動。可以通過直接修改配置檔，或者將系統自動備份的配置檔拷貝回來。
　　配置檔位於 ASE 安裝目錄下，命名規則為：服務名.cfg，如：/opt/sybase/ASE-15_0/FLYBEAN.log。每次調整參數後，ASE 會將備份以前的配置參數，形成諸如 服務名.三位序號 的文件，如：FLYBEAN.001，每次備份，序號會加 1。


如何跨平臺移植 ASE 資料庫？
　　此處的跨平臺是指硬體平臺，如 Sparc <-> X86，它們之間存在高低位元組順序不同的問題。
• 　　BCP in/out；
• 　　如果 ASE 版本為 12.5.3 及以上，則可以通過 Dump/Load 功能直接載入。
　　
如果不小心直接刪除了日誌的設備檔，如何恢復資料庫？
　　首先，應盡可能從作業系統中恢復被誤刪除的設備檔；　　如果不能恢復，可創建一個和被刪除設備檔大小相同的新設備檔，然後運行 dbcc rebuild_log。　　下面給出一個具體的測試用例：
-- 創建測試資料庫 test
use master
go
disk init name='test_dat_dev',physname='/opt/sybase/data/test_dat_dev.dat',size='50M'
go
disk init name='test_log1_dev',physname='/opt/sybase/data/test_log_dev1.dat',size='10M'
go
disk init name='test_log2_dev',physname='/opt/sybase/data/test_log_dev2.dat',size='10M'
go

create database test on test_dat_dev='40M' log on test_log1_dev='5M', test_log2_dev='2M'
go

-- 產生一些日誌
use test
go
create table test (
id int not null,
name char(20) not null
)
go
insert into test values(1,'aaaaaaa')
insert into test values(2,'bbbbbbb')
insert into test values(3,'ccccccc')
insert into test values(4,'ddddddd')
go


-- 創建另一個資料庫，我們需要一個與測試資料庫第一個日誌設備相同的設備檔
use master
go
disk init name='test1_dat_dev',physname='/opt/sybase/data/test1_dat_dev.dat',size='50M'
go
disk init name='test1_log1_dev',physname='/opt/sybase/data/test1_log_dev1.dat',size='10M'
go
disk init name='test1_log2_dev',physname='/opt/sybase/data/test1_log_dev2.dat',size='10M'
go

create database test1 on test1_dat_dev='40M' log on test1_log1_dev='5M', test1_log2_dev='2M'
go

-- 作業系統操作：刪除 test_log_dev1.dat，然後重啟 ASE
mv test_log_dev1.dat test_log_dev1.back

-- 檢查一下資料庫的狀態，然後停 ASE
select name, status from sysdatabases
go
shutdown
go

-- 作業系統操作：拷貝 test1_log_dev1.dat 為 test_log_dev1.dat，重新啟動 ASE
cp test1_log_dev1.dat test_log_dev1.dat

-- 修改測試資料庫狀態，並重新啟動 ASE
sp_configure 'allow update',1
go
begin tran
go
update master..sysdatabases set status=-32768 where name='test'
go
commit
go
sp_configure 'allow update',0
go
shutdown
go

-- 重建日誌，可選步驟
dbcc traceon(3604)
go
dbcc rebuild_log(test,0,0)
go
online database test
go

如何清除Sybase log

手動清除log記錄檔
dump tran 資料庫名 with truncate_only

trunc log on chkpt 選項說明

如果你的trunc log on chkpt開放了這個選項，當SQL SERVER自動執行checkpoint時會清除不活動的日誌，但是對於正在進行的事務，不會清除那些活動的事務日誌，所以如果你的事務定義過大，還是會造成日誌空間的增大。
解決方法：
1.增加log設備空間；
2.將大的事務劃分成若干個小的事務。