SQL Server的安全管理可分為兩階段：
驗證(Authentication)：驗證使用者是否有權利登入SQL Server伺服器，使用SQL Server提供的服務。

授權(Authorization)：也就是設定使用者登入後，可對伺服器做哪些動作、使用哪些資料庫、存取哪些資料表等存取權限。

登入帳戶
在SQL Server中，將用來驗證使用者身份的帳戶稱為登入(Login)。SQL Server提供兩種驗證方式：Windows驗證 - 在SQL Server中建立對應到現有Windows 2000/2003本機或網域帳戶的「登入」，當使用者已用合法的帳戶登入Windows後，要存取SQL Server時，只要他目前所用的Windows帳戶已在SQL Server中有對應的登入，SQL Server就會允許他連線。

SQL Server驗證 - 指由SQL Server自己負責驗證使用者的身份，因此使用這種驗證方式時，管理員需事先y在SQL Server中建好所需的登入及密碼，使用者在連線伺服器時，則必須輸入登入名稱及密碼。通過驗證後才能連上伺服器，使用其資源。

存取權限
在SQL Server中，可被設定存取權限給使用者的物件或動作稱為安全性實體(Securable)，安全性實體的種類相當多，可概分為三個層次：
伺服器層級 - 例如登入、資料庫、連結伺服器、端點(Endpoint)等屬於整個SQL Server執行個體的安全性實體都是屬於這個層級，這類安全性實體的存取權限，也都要以登入為授與對象，而一般為方便設定，都是直接透過內建的伺服器腳色(Server Role)來設定登入對伺服器安全性實體的存取權限；當然SQL Server也允許不透過伺服器角色，而個別設定某安全性實體的存取權限。

資料庫層級 - 舉凡屬於某資料庫本身的安全性實體都屬此類，像是資料庫使用者、資料庫角色、結構描述、全文檢索目錄等，原則上，這類安全性實體都需授與給資料庫使用者。

結構描述層級 - 這類安全性實體包括資料表、檢視表、預存程序、函數等等，這個層級的存取權限自然也是以資料庫使用者為主要授與對象。

使用者
使用者(user)這個資料庫物件，就是用來設定登入帳戶對資料庫是否有存取權。由於每個資料庫所允許使用的人都不同，所以每個資料庫都有它自己的使用者物件，假設我們想使用SQL Server中所有的資料庫，那麼在每個資料庫中，都要有以我們的登入帳戶所建立的使用者物件才行。

角色
角色(role)是用來指定存取權限的資料庫物件，而且每個資料庫都有它自己的角色物件，每個角色也都有其獨立的存取權限設定。例如我們可指定某些角色只可查詢資料表資料、有些角色則可更改或刪除資料。設定好角色之後，我們只需再指定每一個使用者可以扮演哪些角色，就可讓使用者取得與角色相同的存取權限。

閱讀全文...

在網際網路上的主機通常會透過完整格式的網域名稱(Fully Qualified Domain Name，FQDN)來做為辦識主機的所在位置，而一個完整格式的網域名稱包含了兩個部份，分別為主機名稱(host name)與網域名稱(domain name)。為了確保每台主機的完整格式網域名稱不會產生重複的現象，在網域名稱系統的架構中，位於同一層的節點標籤必須是彼此相異，而我們稱這些在同一階層的節點為同輩節點(sibling node)。

在網域名稱系統中，最頂端的root節點是作為整個網域架構頂層管理，而這個樹狀階層架構中為了方便管理不同領域所使用的域名類型，因此在root節點下一層制定一個頂層網域(Top Level Domain，TLD)架構，在最早的時候，頂層網域架構共制定了七個不同的類型：

.com 商業機構或是公司行號
.edu 教育機構或是研究單位使用
.gov 美國政府的機構使用
.int 國際性組織機構使用
.mil 美國的軍事機構使用
.net 最初是給管理網路基礎設施的機構使用，自1996年開始已經開放給其它機構申請
.org 這個類別是給非商業的機構使用，於1996年後就沒有這個限制了

由於早期的發展與制定的規範都是針對美國本土所進行設計的，因此我們會發現在最初規範出來的七個頂層網域並無讓其它國家使用。為了解決這樣的設計謬誤，掌管這些域名架構的網際網路名稱與位址管理機構(International Corporation for Assigned Names and Numbers，ICANN)便將原先的七個頂層網域改稱為通用頂層網域(Generic Top Level Domain，gTLDs)。而為了因應網際網路的快速發展與調解國際網域分配的爭議，除了現存的gTLDs之外，另外也針對不同的國家與地區增加了新的網域命名空間，而這些新定義的網域命名空間以每個國家的國碼來進行定義，因此稱為國碼頂層網域(Country Code Top Level Domain，ccTLDs)。例如：台灣的國碼頂層網域為.tw，日本的國碼頂層網域為.jp等。除了這些定義之外，像近幾年來頗為熱門的.biz與.info這類的網域名稱也於2000年被新增到通用頂層網域中。除了通用頂層網域是由網際網路名稱與位址管理機構來進行管理之外，區域性的國碼頂層網域則是由該國的管理機構來負責，例如：台灣是透過財團法人台灣網路資訊中心(Taiwan Network Information Center，TWNIC)來進行處理.tw國碼頂層網域的管理。

閱讀全文...

SQL Server的資料庫可分為系統資料庫和使用者資料庫兩種，其中系統資料庫就是SQL Server自己所使用的資料庫，至於使用者資料庫就是由我們自己建立的資料庫。

系統資料庫是在SQL Server安裝好時就會被建立的，分別有master、msdb、model、tempdb這四個基本的系統資料庫，而且不能刪除這些資料庫。除此之外，還有一個隱藏的Resource資料庫，但在Management Studio中看不到它。以下簡單說明這幾個系統資料庫的用途：

master
master資料庫記錄的是有關SQL Server的資訊，包括所有的登入帳戶、系統的組態、各資料的初始資訊等各類重要資料。SQL Server 2005基於安全性的考量，已不再讓我們直接瀏覽、修改各資料庫中的系統資料表，而是必須透過系統檢視(system view)來瀏覽。我們可用"select * from sysobjects where type ='S'"來查看master資料庫中有多少隱藏起來的資料表。

由於master資料庫的內容對整個資料庫系統的關係重大，因此最好要定時備份此資料庫的內容。

msdb
msdb是另一個供系統使用的資料庫，其主要用途是供SQL Server Agent做各類排程作業(job)所用的資料庫。除了SQL Server Agent的資料外，有關備份和還原的記錄、複寫和資料維護計劃等資訊也都是放在這個資料庫中。

model
model是個較特殊的系統資料庫，或許應稱它為「樣板」資料庫。當我們在SQL Server中建立新的資料庫時，SQL Server會以model資料庫為藍本，將其內容複製到我們的新資料庫，因此在所有新建的資料庫中，都會有和model資料庫內容一樣的系統資料表和檢視表等資料庫物件。

tempdb
由名稱就可看出，tempdb是用來存放暫時性資料用的，像是使用者在進行各種查詢或排序時，SQL Server就會在此建立這些暫時性的工作資料表。由於是"暫時性"的，所以tempdb中的資料沒有什麼保存的價值，因此每次SQL Server重新啟動時，都會重建一份新的tempdb資料庫。

Resource
雖然在Management Studio中根本看不到這個資料庫，但只要用檔案總管進入SQL Server的資料庫檔資料夾(例如Program Files\Microsoft SQL Server\MSSQL.l\MSSQL\Data)，就可以看到Resource資料庫的資料檔及交易記錄檔mssqlsystemresource.mdf、mssqlsystemresource.ldf，此資料庫檔還不算小，因為它存放了許多與SQL Server 2005本身相關的系統物件，使用者物件都不會存放Resource資料庫中。

SQL Server 2005採用Resource資料庫的目的之ㄧ，就是讓系統資源集中存放管理，日後將可透過升級Resource資料庫的方式，即可升級SQL Server 2005的功能。

以上簡單介紹了SQl Server中內建的系統資料庫，除了這些系統資料庫外，在每個使用者資料庫中，也會有一些系統內建的物件，其中最重要的就是系統資料表和檢視表。

閱讀全文...

JSP Standard Tag Library(簡稱JSTL)，是一套預先定義好、協助程式設計人員簡化JSP網頁製作的標籤函式庫，包含了各種網頁運作所需的功能，例如迴圈、流程控制、輸出入、文字格式化，甚至XML文件處理以及資料庫存取操作均為其涵蓋範圍。

JSTL雖然是JSP網頁技術的一環，但是與JSP不同的是，JSTL本身並非由SUN公司所開發出來，相反的，SUN制定其規格之後，便直接開放讓外界進行實作，而目前提供相關規格實作成品的最主要的組織為Apache的Jakarta Project。

我們並沒有辦法直接使用JSTL，還必須先至Jakarta Project網站下載並且安裝JSTL。依其功能面作分類，JSTL提供了五種形式的標籤函式庫，列舉如下表：



閱讀全文...

在Linux作業系統中當我們執行一個程式來取得所需要的資源時，此時Linux作業系統便會為這個執行動作建立一個行程(process)，以便管理整個程式執行過程中所需要的狀態應變。然而從我們啟動Linux作業系統時，系統便會開始產生很多不同的行程，而如何針對這些行程來進行管理將會是系統管理員一個十分重要的基本工作。

行程的產生代表程式已經被載入記憶體中，並且可以透過CPU來進行執行。然而每一個行程裡面都會儲存程式執行時所需要的重要資訊，包括含有執行緒(thread)位置、行程識別碼(Process ID)、行程優先權、記憶體脈絡等。依據行程的執行啟動方式的不同將其區分為兩種類別，分別為：

使用者行程(User Process)：這類型的行程於啟動時通常是由使用者於終端機介面或是圖形介面來啟用。

Daemon行程(Daemon Process)：這類型的行程通常無法透過終端機或是圖形化介面中來啟動，它通常需要搭配其它的程式或是行程的執行才可以被啟用運作，通常這類型的行程多為網路服務為主的行程。

每一個行程都會擁有一個獨立的識別碼資訊，我們稱之為行程識別碼，行程間基本上也是透過這組識別碼資訊來辦別雙方的關係。通常我們可以依據行程間的關係利用下列名詞來進行解釋：

子行程(Child Process)：由其它行程所產生出來的行程，稱之為子行程。

父行程(Parent Process)：為行程的一個名稱，通常可以產生一個或是多個以上的子行程。

父行程識別碼(Parent Process ID，PPID)：用來表示某一行程的父行程的行程識別碼資訊。

服務
在Linux作業系統中通常我們可以依據服務的功能，將其區分為系統服務(System Service)與網路服務(Network Service)兩個類別。

系統服務：針對Linux作業系統本身所提供的服務，例如boot.quota、quotad等。

網路服務：針對網路中的其他用戶端所提供的服務，例如APACHE、SAMBA伺服器等。

Linux作業系統中所提供的服務通常會在啟動後就會持續的提供服務給所需要的對象，不論是針對Linux作業系統本身或是針對網路中的其他用戶端，一般我們針對這些服務的分類以執行的功能差異來進行區分之外，通常也會依據服務的啟動方式不同而再把這些服務進行不同的分類。通常會區分為：

獨立式服務：一般又稱之為SysV服務，執行於背景，除非被管理者將服務終止，或是系統關閉，否則服務會一直持續於背景提供服務。

短暫式服務：平時不會啟動於背景中等待存取要求，而是當使用者有所需求時才會啟動提供服務進行存取。

閱讀全文...

由於Internet的快速發展，網際網路上的應用服務也跟著日新月異，從以往最初的資訊流通共享，時至今日，各式各樣更多的需求和服務為消費者及開發廠商提供更多選擇和機會。如今，單純的網頁早已不敷使用，使用者需要更個人化、更多元化的「服務」。Java因為具跨平台能力，其共通性讓更多開發者投入它的懷抱，也不斷發展出更多應用，而其觸角也理所當然伸向網際網路領域。在1997年所提出的Servlet產生了網路服務的另一波新革命，結合了使用者直接接觸的JSP和後端連結資料庫的JDBC應用，Java相關應用在網路服務上創造了難以想像的衝擊和便利。Struts的目的便是要結合這些功能強大的元件，架構出一個兼具功能性及開發便利性的框架。

MVC Model

要想理解Struts的架構，必須先了解何謂MVC model(Model 2)。

字面上來說，MVC所代表的分別是Model、View以及Controller。這是一種將設計工作分層處理的概念，我們可以將一項網路服務的流程區隔為三個部分，每個部分由個別元件處理，只要製訂好各元件間如何聯絡的合作方法，就可以讓一個大型服務切割成數個較簡單的工作。

MVC-model將會有三個不同的元件，也就是模型元件(Model_Component)、視圖元件(View_Component)和控制器元件(Controller_Component)等，模型元件負責商業邏輯(Business_Logic)，視圖元件作為使用者介面，負責服務主體中和使用者的互動，而控制器元件則是接收使用者發出的需求，介接到相對應的商業邏輯，並取得結果後回應使用者，負責前二者的連結。如同一所大公司一樣，將工作區分做到專業化，讓開發人員各司其職，分別做好三個部分的設計，也讓一個大型服務開發過程能夠變得更加明確而清晰。MVC架構起始於一個GUI(Graphocal_user_interface_design_patter，圖型使用者介面設計原型)原型，早期是使用在Smalltalk這個語言，而今隨著網路服務的快速發展，MVC架構已經成為一個流行且成功的網路服務設計方法。

閱讀全文...

電腦科技日益進步，但經過數十年的發展，電腦軟硬體的穩定性仍未達多數人能滿意的水準，電腦中的資料還是有喪失或毀損的情況發生，若再加上天災人禍等意外狀況，存於電腦中的資料實在是不太安全了。就算使用的是具有容錯能力的RAID磁碟陣列，也是難以保證資料庫是百分之百的安全。

雖然電腦軟硬體設備的費用可能不便宜，但大多數的人都認同經過長時間所累積的電腦資料才是更珍貴的資產，因此為了防止在各種意外發生時，仍能保有資料庫的完整性，管理者就必需花額外的時間和資源來備份SQL Server中的資料庫。SQL Server本身當然也提供了不少備份的功能：

資料庫備份
也就是備份整個資料庫內容。如果要將SQL Server中所有資料庫都備份下來，可能需要相當龐大的儲存空間來存放備份資料。但其好處是在還原資料庫時，也只需將整個資料庫從一份資料庫備份還原到SQL Server就可以了。另外，就算要是使用下述的差異式備份或交易紀錄備份，也必須是在做過完整的資料庫備份後才能進行。

差異式(Differential)備份
只備份從上一次執行完整資料庫備份後有更動過的資料，因此所需的備份時間和儲存空間，通常會比資料庫備份少很多，所以適合還原，然後再用最近一次所做的差異式備份還原到SQL Server，就可讀資料庫的內容回復到最近一次差異式備份時的同樣內容。

交易記錄(Transaction Log)備份
只備份交易記錄檔的內容，由於交易記錄檔只會紀錄我們在前一次資料庫備份或交易記錄備份之後，對資料庫所做的異動過程，也就是只記錄某一段時間的資料庫異動情形，因此在做交易記錄備份之前，一定需做過一次完整的資料庫備份才行。交易記錄備份所需的時間和儲存空間應該不多，不過在做還原時，除了要先將資料庫備份還原外，還需再依序還原各個交易記錄備份中的內容。

檔案及檔案群組備份
如果資料庫的內容分散存於多個檔案或檔案群組，而且資料庫已非常龐大，大到進行一次完整的資料庫備份會有時間和儲存空間上的問題，就可使用這種方式來備份資料庫中部分檔案或檔案群組。由於每次只備份部分的檔案或檔案群組，因此需做數次不同的備份才能完成整個資料庫的備份，但資料庫大到不方便做完整備份時也只好如此。而且檔案及檔案群組備份也也另一個好處，就是當損毀的資料只是資料庫中的某個檔案或檔案群組時，也只要還原毀損的檔案或檔案群組備份就可以了，比起只有整個資料庫的備份時，要還原整個資料庫方便許多。

由於資料庫的備份有多種不同的方法，很自然地，還原資料庫時也需依照當初備份資料庫的方式，及還原作業的時間點，以對應的步驟將備份下來的資料還原到伺服器中，以使資料庫的內容能回復到您所希望的時間點(通常是越接近資料庫出問題的時間越好)。以下介紹各種備份的還原方式：

資料庫備份的還原
不管之前只進行完整的資料庫備份，或是資料庫備份、差異式、和交易記錄備份交錯使用，遇到需要還原資料庫時，都需先還原完整的資料庫備份。

若是只做完整的資料庫備份，只需還原最新的備份資料，就算是完成還原的工作了。但若是搭配差異式或交易記錄備份的話，則此處的還原完整的資料庫備份，應該就只是整個還原作業中的第一個動作而已，在將最近一次的資料庫備份還原到伺服器後，可能還得繼續還原後續的差異式或交易記錄備份資料。

差異式備份的還原
還原差異式備份，其步驟並不複雜，只需先還原最近一次的完整資料庫備份，然後再還原最近一次差異式備份即可。例如採取每週六做一次資料庫備份，每天清晨做一次差異式備份者，在星期三遇到要做還原的情況時，需先還原上週六的資料庫備份，然後再還原當天清晨所做的差異式備份，即可完成整個還原的工作。

如果在做完這兩個還原動作後，您還有後續的交易記錄備份，則可再取出這些備份資料，依序以稍後介紹的方法將它們還原。

交易記錄備份的還原
還原交易記錄備份會比較麻煩，但由於通常我們都會以較頻繁的頻率進行交易記錄備份，所以使用交易記錄備份時，也意味著我們能將資料庫的內容回復到較接近目前的狀態。

閱讀全文...