2010年4月21日 星期三

Bug修復

4月21 14時
進行平台更新,以修正通聯紀錄無處理人員之問題。
修正後,一併至DB HC_ContactLog 修改處理人員檔位,以補正資料

2010年4月20日 星期二

系統維護日作日誌–SQL

上星期Logship 機制之設定,一直卡在存取被拒的問題,
研究後,應有2種方式解決。
一、架設Active directory 建立網域管理架構,並進一步設定SQL Agent的執行身分或利用Agent Proxy與認證來指派需要的權限。(正規、未來擴展與管理方便,缺點是比較複雜且要變更伺服器較大)
二、利用「群組原則管理」gpedit來修改匿名存取的權限(來自遠端的任何帳戶,都會被視在匿名的身分)。修改電腦設定–windows設定-安全性設定-安全性選項的網路存取: 可以匿名存取的共用,直接增加其項目。例如 COMCFG,DFS$,SqlDBbk

在本次應用中,我被主要伺服器和次要伺服器都進行了設定變更,以方便雙向的資料存取。

2010年4月12日 星期一

系統維護工作日誌–補述137server SQL管理

4月初為備份資料庫資料與維持ldm檔案大小,
進行備份計畫維護工作
1. ADD FullBKAllDbPlan (All Database would be full backup every monday 13:30 to .\BackupFiles\FullBKCluster\)
2. ADD DiffBKPrimaryDb(Primary Database Diffence Backup every W1 W3 W5 at 14:00 to .\BackupFiles\DiffBKCluster) task
3. ADD LogBKPrimaryDb(Primary Database Log Backup every 30 min to .\BackupFiles\LogBKCluster) task
4. Add delete old backup file tasks : DeleteOldBackupFilesPlan (over 4 weeks full and diff log)
5. reset clearlog task (remove log files over 8 weeks)

2010年4月2日 星期五

系統維護工作日誌–firewall

由於檢測掛號功能失敗,發現IP錯誤,所以修改設如下,以利用Port轉發實作

BackupPlatformFutabaProxy wan1/*.*.*.136 16888/tcp 192.168.1.136 16888/tcp
BackupPlatformHttp wan1/*.*.*.136 80/tcp 192.168.1.136 80/tcp
BackupPlatformHttps wan1/*.*.*.136 443/tcp 192.168.1.136 443/tcp
BackupPlatformIII2 wan1/*.*.*.136 22222/tcp 192.168.1.136 22222/tcp
BackupPlatformIII8080 wan1/*.*.*.136 8080/tcp 192.168.1.136 8080/tcp
BackupPlatformLSBoxChannel wan1/*.*.*.136 50000/udp 192.168.1.136 50000/udp
BackupPlatformRDP wan1/*.*.*.136 3389/tcp 192.168.1.136 3389/tcp
BackupPlatformSQLIII1 wan1/*.*.*.136 11111/tcp 192.168.1.136 11111/tcp
BackupPlatformVNC wan1/*.*.*.136 5900/tcp 192.168.1.136 5900/tcp

2010年3月31日 星期三

系統維護工作日誌–SQL

增設自動化系統維護設定
2010 3月31日
1. Data Mail
2. Add 操作員
3. Add Critical Error Alert
4. Add User Connection too High 100 Alert (For watch if SQL is in High Load)
5. Add Login Fault Alert (For watch if SQL is being hacked)
6. Use Penguin Backup Task complete to test Alert setting / functions→ It is Ok, alert condition is changed to "If task is failure"
7. Add AllDatabaseFullBK(All Database would be full backup every monday 13:30 to .\BackupFiles\FullBKCluster\) task
8. 執行備份時發現penguin有一致性錯誤,進行修復(平台期間需停用,費時1分內),以下為執行碼
EXEC sp_dboption 'Penguin', 'single user', 'TRUE'
use Penguin
dbcc checkdb ('Penguin',repair_allow_data_loss)-------修复数据库
dbcc checkdb ('Penguin',REPAIR_REBUILD)----------------修复数据库索引
dbcc checkdb
EXEC sp_dboption 'Penguin', 'single user','FALSE'

9. Add PrimaryDbDiffBK(Primary Database Diffence Backup every day at 14:00 to .\BackupFiles\DiffBKCluster) task
10. Add PrimaryDbLogBK(Primary Database Log Backup every 30 min to .\BackupFiles\LogBKCluster) task
11. Add delete old backup file tasks : DeleteOldBkPlan(over 6 weeks full and diff) DeleteLodBkPlan(over 2 days log)
12. reset clearlog task (remove log files over 12 weeks)
13. remove old penguin backup plans
14. 日誌檔(LDF)無法隨自動交易備份作業完成後自動縮減(標準程序:備份交易檔(with nolog = "截斷交易紀錄"),再壓縮資料庫),尚待研究






系統維護工作日誌–SQL

進行備份計畫設定時,考量使用data mail,發現無法使用(因為service broke沒有辦法啟用)。
  利用以下方式解決
  USE [master]
GO
ALTER DATABASE [msdb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE [msdb] SET SINGLE_USER
GO
ALTER DATABASE [msdb] SET NEW_BROKER
GO
ALTER DATABASE [msdb] SET MULTI_USER
GO
  
  msdb 係依DBMS報出的錯誤訊息決定
  
  實作時間:2010/3/31 10:40

2009年8月1日 星期六

是巧合嗎?還是大趨勢?facebook

是巧合嗎?facebook這2天在我的生活里熱起來了,好久沒有一個事物可以讓我的熱度上揚到回復牧羊人的本性囉。

比較只是單純想要激勵學生多了解資訊生活,深入了解與分析資訊應用的特色,
讓大家養成多想想的習慣。

沒想到有個學生還發現了我久久註冊沒用的facebook,再加上大學同學的邀約,
所以就認真的開始玩看看。老實一開始我覺得facebook的功能實在太多樣化,而且使用型態上有別以前的blog、bbs、twitter的東西,有點難上手,或多或少有點不習慣。

在使用上,它已經不像blog是用來發文的平台(雖然它也包含了這個功能),而是針對社交功能上作了很大幅度的強化,使用者不是在這扮演獨擔大梁的總編了,在上面的每一位朋友都在無形中成了增填色彩的繪筆。你可以向大家滴沽一下你的想法,讓大家回文,讓你滿足小小得成就,也可就借平台上一堆的小應用程式投下去(也許是心理測驗、遊戲、小禮品),看著它擴散出去,在旁邊欣賞它的漣漪,那也是滿不錯的溫馨。說直白一點,把它當成大家胡亂、起閧的小空間也可以吧

現在看來facebook這樣的東西,各部件拆了就沒什麼了不起,在其他web apps上都可以看到它的影子,但是怎麼拼起來就有一點killer application的味道。

不過聽說比爾蓋茲覺得它不好用?改天要找文來拜讀一下