2012年11月27日

Windows Azure - 升級Cloud Service到Windows Server 2012

前一段時間,看到Cloud Service已經開始支援Windows Server 2012的時候,很開心的就準備要去升級,所以小弟就到了下圖的畫面,選了Windows Server 2012。

image

然後悲劇就發生了… ( 好啦,也沒那麼悽慘,只是單純的錯誤。 )

錯誤訊息如下,簡單的說,就是不可以將Windows Server 2008 SP1直接升級到Windows Server 2012。

圖片 1

The Upgrade from OS family 1 to OS family 3 is not allowed

據說,Windows Server 2008 R2 升級 Windows Server 2012也會出錯。

The Upgrade from OS family 2 to OS family 3 is not allowed

這個案例,只要是發生在當Cloud Service上,已經使用Windows Server 2008或是Windows Server 2008 R2,而想升級成Windows Server 2012時,會發生的錯誤訊息;無論是使用如最上圖的升級方式,或是透過前篇,利用ServiceConfiguration.Cloud.cscfg改OSFamily,都會發生錯誤;只要目前Cloud Service上,還存在著Windows Server 2008或是R2。

所以要怎樣解決呢??

第一種方式

刪除現有的Cloud Service,然後透過前篇的方式,先設定ServiceConfiguration.Cloud.cscfg的OSFamily,最後佈署一個新的Cloud Service;不過,當刪除Cloud Service,建立新的Cloud Service的時候,IP位置,就會換了…所以不是很建議使用這種方式。

第二種方式 SWAP VIP

是的,SWAP VIP是最好的方式,大家可以參考這篇了解SWAP VIP,我們可以把修改過ServiceConfiguration.Cloud.cscfg的專案,佈署到Staging,然後再利用SWAP VIP進行切換;這樣就可以順利解決;當然,如果Staging目前上面已經在執行,也別忘記要先砍掉,在建立一個新的Staging;如下圖。

image

然後在UPDATE上新的Cloud Service到Staging,最後,再利用SWAP切換到Production,就可以順利升級到Windows Server 2012了 ( 也不算是升級了XDD,根本就是重新產生了… )

後記

相信未來會有越來越多人遇到這個問題,所以在這邊寫出來,希望能幫助到大家。

參考網址

Windows Azure - 佈署Cloud Service時,直接選擇想要的OS

相信如果有使用Cloud Service的人,因該都會知道,可以在Cloud Service管理畫面選擇想要的OS,看是Windows Server 2008,還是Windows Server 2008 R2,或是很潮的Windows Server 2012,如下圖。

image

但是不管怎樣選擇,大家可能會發現,剛剛佈署上去的Cloud Service,總是Windows Server 2008,如果每次都要進管理畫面調整,那不是很麻煩!?而且每次調整期間,又是一陣長時間的等待,難道都沒有別的辦法嗎?

其實在Visual Studio裡的Azure專案,是可以做調整的,首先,我們看到如下圖的Study4TwAzure專案,底下有一個ServiceConfiguration.Cloud.cscfg,那就是服務的設定檔,我們把他點開。

image

如下圖,osFamily就代表os的版本,1是08,2是R2,3就是2012,後面代表的是OS的版本,也就是第一張圖的Operating System Version,通常都是設定星號,代表自動選擇,當然也可以指定,接下來schemaVersion就是Azure SDK的版本,我這邊使用的是1.8。

image

為了方便大家觀看,也準備了文字格式,基本上和上面相同。

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Study4TwAzure" 
                      xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" 
  osFamily="3" osVersion="*" schemaVersion="2012-10.1.8">
  <Role name="Study4TwWork">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
  <Role name="Study4TwWeb">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

另外,補充一下,Instances Count的數字,就是代表需要Run幾個Instances,所以大家不要亂調整喔!!

當調整完後,我們佈署上去,就會自動幫我們建立Windows Server 2012的OS了!!

後記

如果想要知道詳細的一些設定,可以參考下面的MSDN參考網址。

參考網址

Windows Azure - Cloud Service的佈署方式

今天剛好有人問到,問我Cloud Service是怎樣佈署的,本來想說,把Blog網址丟過去交差了事( 疑!? 當然是開玩笑的XDD,我怎麼可能會做這種事情!! ),但後來發現,原來,我根本還沒寫過類似的文章 ( 所以也不能丟丟網址交差了事了…QQ ),所以這篇,教大家,幾個Cloud Service佈署的方式,另外,如果有去今年TechDays的朋友們,John哥那場也有介紹到這幾種方式喔!!

第一種 建立兩個Cloud Server

嗯,這也是小弟一開始使用的方式,假如正是網址為sky.com;簡單的說,就是準備兩個Cloud Service,A和B,當A是正式環境的時候,就把程式佈署到B,然後再利用自己架設的DNS,改變DNS,讓sky.com指向B的ip位置;所以Cloud Service B就變成正式的環境;同理,下次要佈署的時候,就佈署到A,然後再取改變DNS,讓sky.com指向A…嗯,當然小弟我就直接講結論了,基本上,除非不得已,不然真的不要用這種佈署方式…

第二種 直接覆蓋

其實在Cloud Service上,是可以直接覆蓋的,而且覆蓋期間,服務是不會中斷的( 官方文件是寫,如果有兩個Role以上,就不會中斷 ),簡單的說,就是只有一台Cloud Server A,而我們直接使用UpDate的方式,如下圖。

image

如果有多台Role,其實也不用擔心UPDATE會一口氣全部升級,我們可以從INSTANCES的地方看到UPDATE DOMAIN,簡單的說,Azure的升級,根據UPDATE DOMAIN的區塊進行升級,不過因為小弟這邊只用一個Web Role和Work Role,所以都是0,如果有兩個以上,就會發現有0,1,2等等不同的區段。

image

當然,這是一種升級方式,也是小弟後來使用的升級方式。

第三種方式 SWAP VIP

當然,小弟還是主推這種方式,因為這種方式真的是超級方便,不知道大家還記不記得,其實Cloud Service有分兩種Production和Staging ( 雖然兩個都要收錢… ),但是他既然這樣分,就自然有它的用意;所以這種佈署的方式,就是我們正式的Web頁面在Production上,而將我們準備要佈署新的頁面先佈署到Staging( 一個Cloud Service可以同時佈署不同的Production和Staging ),我們只要在DASHBOARD按下Staging,就可以切換到Staging,然後再按下下面的佈署,就可以佈署到Staging,而Production完全不會受到影響。image

當Staging佈署完成後,進入下一步之前,我們稍微回顧一下,現在我們的Production是正式環境,Staging是測試環境;如果依據版本來看,Staging目前放的是比較新的版本 ( 因為準備要替換掉目前Prodction線上的頁面嘛 ),那要如何做呢?我們只要按下SWAP按鈕,接下來按下ok。

image

是的,神奇的事情就這樣發生了SWAP的作用,就是將Prodction和Staging互換,簡單的說,原本準備卸下來,在Prodction的頁面,會變成Staging,而準備換上去,在Staging的新網站,會變成Production,所以,按下去後,我們放在Staging的新網站,就自動地被切換成新網站了!!當然,過程中,也不會中斷,全部交由Azure完成。

當然,後面的機制都是由Azure完成,主要是透過Role前面的Load Blance來切換位置,當然,這和我們使用者一點關係都沒有。

後記

是的,不用說,當然要用第三種方式,但也別忘記,放在Staging的網站,也是要算錢的,所以如果被換下來的舊網站,真的不需要的話,也別忘記砍掉,而第一二種方式就完全沒用了嗎?其實也不一定,或許某些場合,還是需要=v=,不管如何,這三種是Cloud Service佈署的一些小技巧,也給大家參考看看。

參考網址

TFS - 刪除不需要的使用者

今天和小章哥聊天,剛好聊到他說他的VS2012掛掉了 ( 好吧,我也必須負一半責任XDD,因為是我慫恿他玩Code Map的…Orz ),後來他貼給我他的解決方案,也讓我想到,我還有一篇文章還沒完成。 ( 但後來發現,解決方法,完全和小章哥的那篇無關… )

那我要處理的問題是甚麼?,就是在使用TFS的時候( 小弟是使用Team Foundation Service,不過處理方式和TFS應該都一樣 ),有時增加了一堆人,結果選擇的時候就會出現一堆人的列表,但那些人可能現在也不需要了,有可能離職了,也有可能退出專案了,總之,就已經消失出專案裡面,所以TFS也應該把這些人移除,如下,是一個例子,這裡是要新增新的使用者到此Team Porject,然後下拉選單一拉,結果有一堆人…,而這些人,早就應該刪除出整個Default Collection。

image

起初,我以為這是Cahce的問題,那解決的方式就應該用小章哥的那篇,結果後來發現,完全不是XDD,那應該怎樣做呢??

首先我們進入管理頁面,然後點選右上角的齒輪。

image

這邊就是控制中心了,選擇右下的管理Coolection Security和Group Membership。

image

進來後,再點選Users。

image

然後就會發現,之前加入過的使用者都在這邊了!!結果,和Cache完全無關!!Orz…( 由下圖可知,小弟很努力地在推廣TFS XDDD )

image

然後點選其中一位,並且按下右上的Edit,就會出現Delete的選項,刪除後,就可以和那位使用者說881了=v=。

image

以上,就那麼簡單,我完全沒注意到…或使這是自己一個人玩TFS的盲點吧,因為不太需要設定權限…所以一直沒發現在這邊…總之,這篇文章也推薦給新手吧QQ…

ASP.NET MVC - 將舊專案升級成.NET 4.5時,發生MSB3247錯誤

最近因為將ASP.NET MVC專案升級成.NET4.5,結果就發生了以下這個錯誤,主要原因是因為有組件使用了不同版本的.NET而造成衝突。

image

詳細的錯誤如下 :

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3247: 在同一個相依組件的不同版本之間發現衝突。

那這個到底怎麼發生的呢?,我們稍微還原一下案發現場 ( 學一下黑暗大XDD )。

這個專案,原本是架構在.NET Framework 4之下,也是從ASP.NET MVC 3升級上來的,而我們希望,將此專案改成.NET Framework 4,也就是大算把目標Framework改成,.NET Framework 4.5。

image

當然,改完後,沒出現甚麼問題,但是按下編譯的時候,第一次,就會出現如下圖錯誤。( 第二次以後就不會出現警告了… )

image

但老實說,這個錯誤訊息,真的看不出個所以然,所以我們要先改一下,讓這個錯誤訊息輸出多一點的資訊,我們使用選擇Visual Studio的工具,選項,就可以打開下面的視窗;之後我們在MSBuild 專案組建輸出詳細等級,從最小改成詳細。

image

在一次的建置後( 記得要改回.net 4.0再改回.net 4.5才會再次出現警告 ),就可以發現,原來是system.net.http這個組件的關係。

image

知道後就好處理了,接下來,我們請出Google做查詢,結果果然查到,已經有人回報這個問題。

image

接下來,我們當然就是去看一下專案檔的內容,我們選擇了要升級.NET 4.5出錯的專案,並選擇卸載專案。

image

接下來在選擇編輯。

image

我們就可以找到目前System.Net.Http是2.0.0.0。

image

而今天,剛好Visual Studio 2012 update 1已經正式釋出,所以小弟也順便開一個新的ASP.NET MVC 4專案,來比對看看,目前新的專案,是如何參考的,如下。

image

既然新版的寫法都不一樣了,我們當然就使用新版的吧XDD,所以我們就把參照改成如下。

<Reference Include="System.Net.Http">
</Reference>
<Reference Include="System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <HintPath>..\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll</HintPath>
</Reference>
<Reference Include="System.Net.Http.WebRequest">
</Reference>

這樣,就不會有任何問題了~~

參考網址

2012年11月8日

ASP.NET MVC – ASP.NET MVC 4 2012 Fall Update

ASP.NET MVC Fall 2012 Update 擁有更多的新功能!!還有更多的樣板!!

看到這段話,就讓我想到xxx-online,

xxx-online 新版更新,擁有更多的裝備,還有更多的副本!!

只不過,玩online看到新版的時候,心情是很躍樂的,而看到技術上的更新…恩…只好犧牲躍樂的心情來寫文章了QQ…

最近的技術更新,其實都慢慢有縮短的趨勢,當然,不知道算不算是敏捷開發的方式,讓這些新功能快速地釋出,來讓白老鼠大家能快速的測試與回饋,不過不管怎樣啦XDD,既然身活在這一行,也只能當成每季都有無敵大魔王可以打,抱持的愉悅痛苦的心情,來寫寫這開箱文吧。( 未來技術,會不會也朝向組隊出團的境界阿= =… )

( 其實本來是想偷懶,寫新版的SSDT開箱文,但結果Terry哥動作更快…馬上寫了這篇,所以小弟只好來開ASP.NET MVC Fall 2012 Updae (QQ) )

軟體需求

此更新只能在Visual Studio 2012和Visual Studio Express 2012 for Web。

官方支援

此更新為prerelease,官方是不support的,有問題必須去論壇問。

更新項目

因為沒有很仔細的一個一個去研究,所以有誤的話,請和小弟說,小弟會盡快更正;同樣的,未來有時間,再針對每個項目去做介紹。(原文在此,當然,根據小弟的習慣,不可能完全照意思翻啦…有興趣的可以去看原文喔!!)

以下為更新項目 :

Web Publishing (網站佈署)

  • Website發佈的強化 (現在Web Application Project和Website project有相同的發佈體驗了喔!!)
  • 選擇式發佈 – 你可以選擇一個或多個檔案來進行發佈(在佈署到Web Deploy endpoint之後),詳細如下:
    • 可以佈署選擇的檔案
    • 可以知道本地文件和原端文件之間的差異 
    • 可以利用遠端的檔案來更新本地端檔案,或是利用本地端檔案更新遠端檔案。 ( 真繞舌= =)

New ASP.NET MVC Templates ( 新!!ASP.NET MVC 樣板 )

  • Facebook樣板 – 只需要簡單的幾個步驟,就可以使用Facebook樣板可以快速地建立一個Facebook Canvas應用程式並且取得相關資料,有興趣的人可以參考這篇 http://go.microsoft.com/fwlink/?LinkID=269921
  • Single Page Application ( 單一頁面應用程式!!復活!!) – 單一頁面應用程式,使用了knockout.js和ASP.NET Web API,這個樣板時做了代辦事項應用程式,並且示範了使用JavaScript和HTML5搭配RESTful Server API。
  • FixedDisplayModes package – MVC專案樣板已經包含了新的FixedDisplayModes這個NuGet package,這個Package包含了MVC 4錯誤的解決方法。關於更多訊息請參考MVC Team的文章(http://blogs.msdn.com/b/rickandy/archive/2012/09/17/asp-net-mvc-4-mobile-caching-bug-fixed.aspx)。

ASP.NET Web API

Web API 增強了非常多的新怪物功能

  • ASP.NET Web API OData
  • ASP.NET Web API Tracing
  • ASP.NET Web API Help Page
ASP.NET Web API OData (再度復活!!)

當你需要建立含有豐富商業邏輯的資料來源OData Endpoints時,ASP.NET Web API OData 給了你非常多的靈活度。 最後 ASP.NET Web API OData預設會包含在ASP.NET MVC 4 專案樣板 ,同時也提供NuGet (http://www.nuget.org/packages/microsoft.aspnet.webapi.odata).

ASP.NET Web API Tracing

ASP.NET Web API Tracing 整合了.NET Tracing和Web API來追蹤數據。而目前的Web API 專案樣板預設也設定為啟用。你的web API所追蹤的數據會送到Output window並起供IntelliTrace來使用. 你也可以在任何的應用程式來使用ASP.NET Web API Tracing,你只需要安裝ASP.NET Web API Tracing NuGet package。 (http://www.nuget.org/packages/microsoft.aspnet.webapi.tracing)。

更多的ASP.NET Web API Tracing 資訊 http://go.microsoft.com/fwlink/?LinkID=269874

ASP.NET Web API Help Page

The ASP.NET Web API Help Page 預設已經包含在Web API專案樣板裡面. 簡單的說,ASP.NET Web API Help Page 會自動的產生說明文件,包含了HTTP endpoints、支持的HTTP methods, 參數等等。 你也可以在任何的應用程式來使用ASP.NET Web API Help Page ,你只需要安裝ASP.NET Web API Help Page NuGet package(http://www.nuget.org/packages/microsoft.aspnet.webapi.helppage).

更多的ASP.NET Web API Help Page 資訊http://go.microsoft.com/fwlink/?LinkId=271140

Windows Azure Authentication ( Windows Azure驗證 )

Windows Azure Authentication可以讓你簡單的把Windows Azure Directory使用在Web application上,你可以使用Office365的使用者,或是使用企業自己的domain帳號等等。

更多的Windows Azure authentication資訊http://go.microsoft.com/fwlink/?LinkID=267940

ASP.NET SignalR (大推)

ASP.NET SignalR 可以讓你簡單的建立(怎麼每個都講簡單建立…)即時的ASP.NET應用程式,而不是使用WebSockets!!

更多的ASP.NET SignalR資訊 http://go.microsoft.com/fwlink/?LinkId=271271

雖然未來小弟練習的時候,還是會寫心得筆記,但現在已經有很多前輩寫了SignalR的文章喔!!絕對值得推薦!!有興趣的可以點進去看看喔!!91哥小朱前輩黑暗前輩 ( 神人三人組~~ )。

ASP.NET Friendly URLs

ASP.NET FriendlyURLs一樣可以非常簡單讓Developer建立乾淨的URL!! ( 就是那種不包含.aspx的URL ),而且不太需要怎樣的設定!!,重點是,他也支援ASP.NET 4.0的應用程式!!其次,他也可以簡單的讓Developer加入mobile支援到現有的application上,並且支援Desktop和Mobile View的切換喔!!

更多的ASP.NET Friendly URLs資訊 http://www.hanselman.com/blog/IntroducingASPNETFriendlyUrlsCleanerURLsEasierRoutingAndMobileViewsForASPNETWebForms.aspx

安裝

基本上就是這樣,但同樣的目前也是會有一些問題存在,大家可以參考這裡,如果想當白老鼠勇者的人,就可以到這裡去下載安裝了。

image

下載的是exe檔,點兩下就可以開始裝了 ( 別忘了把vs2012先關閉喔 )。

image

過一下子,就完成了!!

image

然後,大家就可以開始被玩體驗了!!

後記

同上,有興趣的人就衝吧XDDD,小弟有空,再來打打看這些大魔王吧!!~

參考網址

2012年11月6日

LocalDB - 在LocalDB上使用SSMS還原資料庫產生錯誤

2012/11/09 更新 – 保哥的這篇文章,有教大家手動修改註冊碼,來修正這個錯誤喔,而Terry哥也提供了一篇文章,利用T-SQL去修改註冊碼!!大家有興趣也可以連過去看看=V=

很久很久以前,有一個案子 ( 好像在說故事一樣… ),那時後再使用SQL Server Express當作本機的資料庫開發;而最近,因為需求的關係,需要進行一些調整,老實說,我也懶的(不想)去裝SQL Server Express,畢竟用LocalDB用的好好的,為啥還要去裝呢!?於是,就先把資料從SQL Server Express備份下來 ( 不要問我,為什麼不直接拷貝mdf和log檔案..因為小弟我直覺就選擇了備份XDD ),然後拿到現在的電腦上,準備利用SSMS對LocalDB進行匯入…

然後悲劇就發生了… ( 所以這是一個悲慘的故事… )

image

設定 'Microsoft.SqlServer.Management.Smo.Settings' 無法使用屬性 BackupDirectory。此物件可能沒有此屬性,或因為存取權限不足而無法擷取。 (Microsoft.SqlServer.Smo)

或是選擇還原資料庫,也是出現同樣的錯誤。( 當然,我不是要還原到msdb..這裡只是隨便選一個,重點是上面的紅色框框。 )

image

好吧,既然發生錯誤,就要去尋找怎樣解決,於是找到了這篇;內文大致上是說,因為路徑的關係,所以要去改註冊碼,要不然就是要用T-SQL解決,而目前保哥也提供了一篇文章,來教大家如何修改註冊碼,而Terry哥也提供了一篇文章,則是利用T-SQL去修改註冊碼!!有興趣的可以連過去看看,小弟這邊就不針對註冊碼的地方做教學了 ( 沒事不要和那幾位神人PK~~ )。

OK,不管怎樣,小弟是沒去改路徑,而且既然T-SQL可以解決,那就用T-SQL吧,反正小弟我也不是一天到晚要復原XDD,也順便學習一下T-SQL…( 路人 : 我看其實是寫這篇文章的時候,根本沒去測試註冊碼的方式…還那麼多理由… )。OK,不管怎樣,那些是神人的做法XDD,平民的小弟我,還是用T-SQL就好!!,接下來,我們先看一下這個T-SQL。

RESTORE DATABASE FROM DISK = '' WITH NORECOVERY,
MOVE 'example_dat' TO 'C:\Temp\.mdf', 
MOVE 'example_log' TO 'C:\Temp\.ldf'

OK,相信如果是DBA,大概就已經知道如何還原了,後面也可以不用往下看了XDD,( 後面就單純介紹這個指令而已了。 )。

那這個T-SQL是甚麼意思呢,簡單的說,就是恢復Restore資料庫(廢話!!),而要恢復的這個資料庫來源來自於哪邊,所有DISK後面要接位置;例如DISK = ‘C:\Temp\ss.bak';接下來的WITH,表示我們後面還要加上一些還原的選項,例如這邊我們的NORECOVERY,就是代表著,要執行NORECOVERY的作業 ( 好啦,後續會講到…);而Move表示我們要將原本SQL Server的mdf和ldf檔案的位置,改變到新的位置。

嗯,有聽沒有懂!?,那我們先執行一下下面這個指令看看;我們可以利用這個指令列出備份檔案的資料。

RESTORE FILELISTONLY FROM 
DISK='C:\Temp\SC' 

會出現如下圖,大家可以看到下面第一個是LogicalName( 這邊資料很抱歉,必須隱藏一下,總之就是Sxxxx_Data和Sxxx_Log ),而第二個是PhysicalName,也就是原本mdf和ldf檔案存放的位置;那大家可以發現甚麼?是的,原本的mdf和ldf位置,是放在SQL Server Express的預設目錄下面。

image

所以我們回到剛剛的T-SQL,大家應該就可以了解的到,為什麼要用Move了吧,因為原本的備份檔,mdf和ldf檔的位置是在SQL Server Express的預設目錄下,而小弟我因為要移到新的電腦上,所以要存放mdf和ldf的位置,就和原本的不同了,所以要使用Move指令改變位置,所以我們的T-SQL會改成這樣;Move後面接的是LogicName的名稱,也就是Sxxxx_Data,而To接的就是要搬到那裡,然後也順便把DISK填入備份檔的路徑。

RESTORE DATABASE FROM DISK = 'C:\Temp\SC' WITH NORECOVERY, 
MOVE 'Sxxxx_Data' TO 'C:\Temp\Sxxxx.mdf', 
MOVE 'Sxxxx_Log' TO 'C:\Temp\Sxxxx.ldf'

另外,備註一下,如果Sxxxx_Data填錯,則會出現以下錯誤,所以我們才要用RESTORE FILELISTONLY來列出名稱。

邏輯檔案 'xx' 不屬於資料庫 xx' 的一部分。請使用 RESTORE FILELISTONLY 列出邏輯檔案名稱。

所以,這樣就好了嗎!?如果這樣執行下去,你會發現,DB的確是還原了…但會出現如下圖;式的會一直卡在"正在還原"。

image

那是為什麼呢?其實是因為NORECOVERY這個參數的關係,這個參數的意思,官方是這樣寫的。

指示還原作業不回復任何未認可的交易。 如果稍後必須套用另一個交易記錄,請指定 NORECOVERY 或 STANDBY 選項。 如果 NORECOVERY、RECOVERY 和 STANDBY 三者都沒有指定,預設值就是 RECOVERY。 在使用 NORECOVERY 選項的離線還原作業期間,無法使用資料庫。

就如官方的最後段話,使用NORECOVERY後,會無法使用資料庫;其實那是因為SQL Server的還原機制有三種,不過再談下去,就越拉越遠了XDD,大家可以參考Cary的這篇,或是Funkent的這篇

總之,因為小弟我的備份,是全部備份下來,也沒使用差異備份,所以我們要把NORECOVERY改成RECOVERY,要把T-SQL改成這樣。

RESTORE DATABASE SDB
FROM DISK = 'C:\Temp\SC' 
WITH RECOVERY,
MOVE 'Sxxxx_Data' TO 'C:\Temp\Sxxxx.mdf', 
MOVE 'Sxxxx_Log' TO 'C:\Temp\Sxxxx.ldf' 

這樣又可以了,如下圖,因為SQL Server Express是舊版的db,所以也會自動升級。

image

就這樣,完成了人生第一次的T-SQL 備份還原XDDD ( 話說有點撈過界了XDDD )

後記

老實說,雖然有點撈過界XDD,但也學習到不少東西,希望DBA高手們,不要鞭我喔XDDD

參考資料

2012年11月5日

Window Azure - Git與Web Site的自動佈署

前一篇,我們將Web Site的Git設定好了,也在Web Site裡面建立好了Repo,也在GitHub上準備好了原始碼,那接下來呢?沒錯,現在就只剩下Web SIte裡面Repo和GitHub的橋樑,我們只要把這兩個連起來,就可以了!!

聽起來感覺很困難,但實際上,卻是非常的簡單,Windows Azure的自動化,都幫我們處理好了,連一行指令都不用下… ( 嗯,還是要打打帳號密碼啦。 )

所以我們繼續下去,我們點開Deploy from my GitHub repository,然後選擇Authorize Windows Azure。

image

接下來,惠要求我們輸入帳號密碼,輸入完畢之後,就會問我們,是否允許Windows Azure。

image

完成之後,我們就可以從下拉選單找到我們要連結的Repo。

image

恩….這樣就結束了…,但這樣只有Link阿!!,自動佈署呢!?

image

這時候,我們點離開Deployments,再點進來Deployments,就可以發現,其實Windows Azure已經自動幫我們開始佈署了!!

image

我們可以看到,網站就這樣建立好了… ( 好快… )。

image

這時後,我們連FTP進去看,其實可以發現wwwroot還是一樣是網頁的目錄( 廢話… ),但是多了Repository的目錄來存放原始碼;此外,也多了一個Deployments的目錄來存放佈署的Log。

image

當然,我相信,這樣大家一定還意猶未盡,所以我們改一下ASP.NET MVC裡面的內容,加上個HelloWorld!!

image

然後再利用GitHub進行簽入,如果不知道如何使用的人,可能要看一下之前的文章了…

image

也別忘記按下Sync,讓本地的檔案和GitHub進行同步。

image

當同步完成後,如果我們再來看Deployments,我們可以發現,沒錯!!Windows Azure又自動的幫我們佈署了!! ( 完全不用作甚麼事情啊…突然覺得自己好廢… )

image

打開網頁一看,恩,Hello World出現了…,所以從頭到尾,除了帳號密碼外,只打了Hello World這幾個字…

image

就這樣,這次的實戰就到此結束…愉快的一天…

後記

雖然很簡單,但是實際上,也去翻了一些Git的相關資料,畢竟,之前對Git和GitHub算是完全沒用過的狀態,所以有些觀念點,也花了一些時間釐清;但對於常用Git的高手們,這些文章大概就是小菜一疊吧XDD;但不管怎樣…Windows Azure真的是方便到一個極致,有用Git管理網站的人,絕對要來試試看喔!!( 然後再來好好教教小弟XDD )

參考資料

Window Azure - 準備Web Sites與Git的連線

前一篇,小弟體驗了GitHub,但其實小弟的目的,是想來測試GitHub與Web Sites,所以我們延續前一篇,我們這篇來講解一下,設定Web Sites與Git連線的初期步驟!! ( 不過其實也很簡單,偶而也讓小弟混一混文章吧XDD )

下面這個是我們這要要準備Demo的Repo,裡面其實放的就是ASP.NET MVC 4的基本樣板,小弟預先把他簽入到GitHub上面了。

image_thumb[1]

接下來,小弟新建了一個稱為test5的Web Sites,至於為什麼要做test5!?,因為test1~4都被人用掉了Orz….,建立完成後,我們進入Web Sites,就可以從右下角,看到set up Git publishing,就可以設定設定Web Site的Git佈署。( 目前設定後,就不可以刪除了,除非整個Web Site砍掉重建,所以用在正式環境的人,要考慮清楚 )

image_thumb[9]

然後我們要輸入,新的使用者名稱和密碼,根據內文的意思是說,Git和FTP無法使用Live id進行驗證,所以這邊我們需要輸入一個新的使用者名稱和密碼提供佈署之用,這樣,我們就不需要在Web Site設定任何的憑證。

image_thumb[7]

完成後,我們就可以看到以下訊息,我們的Git Repository已經準備好了;是的,Windows Azure就會在Web Site上面建立一個Repo,當還沒設定Git的時候,我們可以連到Web Sites進去看看,就只有wwwroot。

image

但如果設定了Git,就會多出兩個目錄,一個是紀錄佈署Log用的,一個是存放原始碼的Repo目錄 ( 也就是Repository目錄 )。

image

完成後的畫面如下,我們就可以使用Git指令Push到Windows Azure,或是使用GitHub來觸發。

image_thumb[12]

到這邊,就設定完成了,如果第一次設定完成後,未來如果要設定其他的Web Site,就不會再跳出叫我們輸入帳號密碼的視窗,這點大家要注意;如果想改帳號密碼,也可以透過Reset deployment credentials的連結做更改。

image

就是這樣的簡單!

後記

這是基本的設定Git,簡單的說,Windows Azure會幫我們在遠端建立好Repo,接下來,我們要開始測試,如何自動佈署。