Category: Unix

  • 全球LTE網絡發展前瞻報告

    根據無線智能網WI(Wireless Intelligence)最新發布的《2010~2015全球LTE網絡前瞻報告》稱,在未來5年裏,LTE網絡將席卷全球移動通信網4%的市場份額。在2011年上半年,全球LTE網絡用戶將超過100萬戶,隨著全球移動網絡運營商不斷推出LTE高速無線網絡,到2015年,該數字將達3億戶。   據該前瞻報告稱,到2015年,亞太地區將成為全球最大的LTE網絡市場,占全球LTE網絡的43%。而作為全球最大的移動通信網絡市場,中國LTE網絡用戶數將占全亞太地區LTE網絡用戶的壹半。然而,由於西歐和北美移動網絡運營商對LTE網絡持續發展,在2010年,西歐和北美LTE網絡占全球LTE網絡的70%。這主要是因為諸如歐洲TeliaSonera和美國Verizon無線通信公司率先在歐洲和美國推出LTE網絡所致。對於亞太地區而言,中國、日本、印度尼西亞、韓國都將成為LTE網絡發展的先鋒。在南美洲和非洲,其LTE網絡用戶發展較緩,到2015年,其LTE網絡用戶只占全球LTE網絡用戶的5%。   無線智能網高級分析師,Joss Gillet表示:“LTE網絡的不斷推出也體現了電信行業正在雲計算和融合網絡基礎上,正以矯健的步伐給終端網絡用戶帶來全新的無線網絡體驗。該報告中也表明了,LTE網絡將風扉全球,然而,在無線網絡發展較快、頻譜已經敲定、政府政策已經形成、調控部門也積極配合網絡運營商部署LTE網絡的國家,其LTE網絡發展速度將更快。然而,壹種新新的網絡要想真正稱霸全球,也將歷經千辛萬苦,需數年才能真正在全球普及。”   該分析報告是經過調查全球LTE網絡(不包括印度)運營商對其在未來5年發展趨勢之後所分析、總結出來的結果。在2010年底,包括日本NTT Docomo、德國Deutsche電信、UAE Etisalat即將在本月底開通的LTE網絡,全球將有19張LTE網絡正式投入運營。全球首張LTE網絡是由TeliaSonera於壹年以前在瑞典首都斯德哥爾摩和挪威首都奧斯陸推出的。隨後,TeliaSonera相繼在芬蘭和丹麥也推出了LTE網絡。WI預測,在2010年底,全球LTE網絡用戶數將達35萬戶。   Gillet說:“最先使用LTE網絡的用戶是由於當前移動網絡帶寬無法滿足數據中心移動寬帶網絡用戶的需求,故其將通過USB加密狗和嵌入式網絡設備提高其網絡帶寬。據我們分析預測,LTE聲音(VoLTE)網絡將於2012年推出,這將對LTE手機的大批量出貨和LTE網絡的快速發展帶來巨型引擎。然而,就短期發展而言,高昂的LTE手機價格與有線的網絡覆蓋率依舊減緩LTE發展速度。”   據該報告分析稱,LTE網絡的發展依然與網絡調控部門頒發相關通信頻譜息息相關。對於LTE網絡部署而言,需三大主頻段:2500~2600MHz頻帶中的IMT延伸頻帶,700~800MHz頻帶中的數字分區頻帶,以及對現有低速率通信頻段的升級頻帶。

  • 教妳正確的理解什麽是數據庫恢復

    使用壹個數據庫時,人們總是希望數據庫的內容是可靠的、正確的,但由於計算機系統的故障(硬件故障、軟件故障、網絡故障、進程故障和系統故障)影響數據庫系統的操作,影響數據庫中數據的正確性,甚至破壞數據庫,使數據庫中全部或部分數據丟失。因此當發生上述故障後,希望能重構這個完整的數據庫,該處理稱為數據庫恢復。恢復過程大致可以分為復原(Restore)與恢復(Restore)過程。   數據庫恢復分為以下兩類:   1.實例故障的壹致性恢復   當實例意外地(如掉電、後臺進程故障等)或預料地(發出SHUTDOUM ABORT語句)中止時出現實例故障,此時需要實例恢復。實例恢復將數據庫恢復到故障之前的事務壹致狀態。如果在在線後備發現實例故障,則需介質恢復。在其它情況ORACLE在下次數據庫起動時(對新實例裝配和打開),自動地執行實例恢復。如果需要,從裝配狀態變為打開狀態,自動地激發實例恢復,由下列處理:   (1) 為了解恢復數據文件中沒有記錄的數據,進行向前滾。該數據記錄在在線日誌,包括對回滾段的內容恢復。   (2) 回滾未提交的事務,按步1重新生成回滾段所指定的操作。   (3) 釋放在故障時正在處理事務所持有的資源。   (4) 解決在故障時正經歷壹階段提交的任何懸而未決的分布事務。   2.介質故障或文件錯誤的不壹致恢復   介質故障是當壹個文件、壹個文件的部分或磁盤不能讀或不能寫時出現的故障。   文件錯誤壹般指意外的錯誤導致文件被刪除或意外事故導致文件的不壹致。   這種狀態下的數據庫都是不壹致的,需要DBA手工來進行數據庫的恢復,這種恢復有兩種形式,決定於數據庫運行的歸檔方式和備份方式。   (1) 完全介質恢復可恢復全部丟失的修改。壹般情況下需要有數據庫的備份且數據庫運行在歸檔狀態下並且有可用歸檔日誌時才可能。對於不同類型的錯誤,有不同類型的完全恢復可使用,其決定於毀壞文件和數據庫的可用性。   (2) 不完全介質恢復是在完全介質恢復不可能或不要求時進行的介質恢復。重構受損的數據庫,使其恢復介質故障前或用戶出錯之前的壹個事務壹致性狀態。不完全介質恢復有不同類型的使用,決定於需要不完全介質恢復的情況,有下列類型:基於撤消、基於時間和基於修改的不完全恢復。   基於撤消(CANCEL)恢復:在某種情況,不完全介質恢復必須被控制,DBA可撤消在指定點的操作。基於撤消的恢復地在壹個或多個日誌組(在線的或歸檔的)已被介質故障所破壞,不能用於恢復過程時使用,所以介質恢復必須控制,以致在使用最近的、未損的日誌組於數據文件後中止恢復操作。   基於時間(TIME)和基於修改(SCN)的恢復:如果DBA希望恢復到過去的某個指定點,是壹種理想的不完全介質恢復,壹般發生在恢復到某個特定操作之前,恢復到如意外刪除某個數據表之前。

  • Asp.Net中Session詳解

    懂得ASP/ASP.NET編程   了解ASP/ASP.NET的Session模型   了解ASP.NET Web應用程序模型   了解ASP.NET Web應用程序配置文件Web.config的作用、意義及使用方法   了解Internet Information Services(以下間稱IIS)的基本使用方法   了解如何在Microsoft SQL Server中創建壹個數據庫。   Session模型間介   Session是什麼呢?間單來說就是服務器給客護端的壹個編號。當壹臺WWW服務器運行時,可能有若幹個用護瀏覽正在運正在這臺服務器上的網站。當每個用護首次與這臺WWW服務器建立連接時,他就與這個服務器建立了壹個Session,同時服務器會自動為其分配壹個SessionID,用以標識這個用護的唯壹身份。這個SessionID是由WWW服務器隨機產生的壹個由24個字符組成的字符串,我們會在下面的實驗中見到它的實際洋子。   這個唯壹的SessionID是有很大的實際意義的。當壹個用護提交了表單時,瀏覽器會將用護的SessionID自動附加在HTTP頭信息中,(這是瀏覽器的自動功能,用護不會察覺到),當服務器處理完這個表單後,將結果返回給SessionID所對應的用護。試想,如果沒有SessionID,當有兩個用護同時進行註冊時,服務器怎洋才能知道到底是哪個用護提交了哪個表單呢。當然,SessionID還有很多其他的作用,我們會在後面提及到。   除了SessionID,在每個Session中還包含很多其他信息。但是對於編寫ASP或ASP.NET的程序與來說,最有用的還是可以通過訪問ASP/ASP.NET的內置Session對象,為每個用護存儲各自的信息。例如我們想了解壹下訪問我們網站的用護瀏覽了幾個頁面,我們可能在用護可能訪問到每個的頁面中加入:   通過以下這句話可以讓用護得知自己瀏覽了幾個頁面:   可能有些有些讀者會問:這個看似像是數組的Session(“..”)是哪裏來的?需要我定義嗎?實際上,這個Session對象是具有ASP解釋能力的的WWW服務器的內建對象。也就是說ASP的系統中已經給妳定義好了這個對象,妳只需要使用就行了。其中Session(“..”)中的..就好像變量名稱,Session(“..”)=$$中的$$就是變量的值了。妳只需要寫上句話,在這個用護的每個頁面中都可以訪問..變量中的值了。   其實ASP壹共內建了7個對象,有Session、Application、Cookie、Response、Request、Server等。在其他的服務器端腳本語言如JSP、PHP等中也有其類似的對象,只是叫法或者使用方法上不太壹洋。   ASP Session的功能的缺陷:   目前ASP的開發人員都正在使用Session這壹強大的功能,但是在他們使用的過程中卻發現了ASP Session有以下缺陷:   進程依賴性:ASP Session狀態存於IIS的進程中,也就是inetinfo.exe這個程序。所以當inetinfo.exe進程崩饋時,這些信息也就丟失。另外,重起或者關閉IIS服務都會造成信息的丟失。   Session狀態使用範圍的局限性:剛壹個用護從壹個網站訪問到另外壹個網站時,這些Session信息並不會隨之遷移過去。例如:新浪網站的WWW服務器可能不止壹個,壹個用護登錄之後要去各個頻道瀏覽,但是每個頻道都在不同的服務器上,如果想在這些WWW服務器共享Session信息怎麼辦呢? Cookie的依賴性:實際上客護端的Session信息是存儲與Cookie中的,如果客護端完全禁用掉了Cookie功能,他也就不能享受到了Session提供的功能了。 鑒於ASP Session的以上缺陷,微軟的設計者們在設計開發 ASP.NET Session時進行了相應的改進,完全克服了以上缺陷,使得ASP.NET Session成為了壹個更加強大的功能。   Web.config文件間介   有的ASP.NET程序員說:Web.config文件?我從來沒有聽說過啊,可是我寫的程序不是也能很正常的運轉嗎?是的,妳說得沒錯,沒有Web.config文件程序是可以正常運行的。但是,如果妳做了壹個大型的網站,需要對整個網站做壹些整體配置,例如整個網站的頁面使用何種語言編寫的、網站的安全認證模式、Session信息存儲方式等,這時妳就需要使用Web.config文件了。雖然Web.config文件中的某些選項是可以通過IIS配置的,但是如果在Web.config中也有相應的設置就會覆蓋掉IIS中的配置。而且,Web.config文件的最大的便利之處就是可以在ASP.NET頁面中通過調用System.web名字空間訪問Web.config中的設置。   Web.config有兩種,分別是服務器配置文件和Web應用程序配置文件,他們都名為Web.config。在這個配置文件中會保存當前IIS服務器中網頁的使用哪種語言編寫的、應用程序安全認證模式、Session信息存儲方式的壹系列信息。這些信息是使用XML語法保存的,如果想對其編輯,使用文本編輯器就行了。   其中服務器配置文件會對IIS服務器下所有的站點中的所有應用程序起作用。在.NET Framework 1.0中,服務器的Web.config文件是存在:      \WinNT\Microsoft.NET\Framework\v1.0.3705中的。   而Web應用程序配置文件Web.config則保存在各個Web應用程序中。例如:當前網站的根目錄\Inetpub\wwwroot,而當前的Web應用程序為MyApplication,則Web應用程序根目錄就應為:\Inetpub\wwwroot\MyApplication。如果妳的網站有且只有壹個Web應用程序,壹般說來應用程序的根目錄就是\Inetpub\wwwroot。如果想添加壹個Web應用程序,在IIS中添加壹個具有應用程序起始點的虛擬目錄就行了。這個目錄下的文件及目錄將被視為壹個Web應用程序。但是,這洋通過IIS添加Web應用程序是不會為妳生成Web.config文件的。如果想創建壹個帶有Web.config文件的Web應用程序,需要使用Visual Studio.NET,新建壹個Web應用程序項目。   Web應用程序的配置文件Web.config是可選的,可有可無。如果沒有,每個Web應用程序會使用服務器的Web.config配置文件。如果有,則會覆蓋服務器Web.config配置文件中相應的值。   在ASP.NET中,Web.config修改保存後會自動立刻成效,不用再像ASP中的配置文件修改後需要重新啟動Web應用程序才能生效了。   Web.config文件中的Session配置信息 :   打開某個應用程序的配置文件Web.config後,我們會發現以下這段:   這壹段就是配置應用程序是如何存儲Session信息的了。我們以下的各種操作主要是針對這壹段配置展開。讓我們先看看這壹段配置中所包含的內容的意思。sessionState節點的語法是這洋的: 必須有的屬性是 屬性 選項 描述 mode 設置將Session信息存儲到哪裏 Off 設置為不使用Session功能 InProc…