sqlserver讀寫分離
A. 分離資料庫是什麼意思
問題一：資料庫分離，什麼意思啊？ 一般默認情況下資料庫在聯機狀態下我們不能對資料庫文件進行任何復制刪除等操作，如果將資料庫分離的話就可以對數據文件進行復制、剪切、刪除等操作了。一般想直接備份數據文件，就先分離資料庫，之後把數據文件復制到別的地方，再把數據文件附加回去就可以了。
備份資料庫是將資料庫中全部對象以特定格式導成為備份文件，至於格式全部是資料庫引擎來使用，用戶無需關心。導出資料庫是將資料庫中某些對象導出為其他格式的文件，一般都是行集的形式。
問題二：什麼情況下需要分離資料庫？ 比如你想把資料庫轉移到別的地方，而你又不願意備份的時候，可以分離然後拷貝文件過去，然後附加上
問題三：sqlserver分離的資料庫在哪 默認的路徑在：D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data或者
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data；不過不行就用搜索功能；其實你分離之前可以先檢查其路徑：右鍵--資料庫--屬性--文件，在此面板上可看到路徑
問題四：什麼是資料庫的讀寫分離 資料庫復制被用來把事務性查詢導致的變更同步到集群中的從資料庫。對於大訪問量的網站，一般會採用讀寫分離，比如ebay的讀寫比率是260：1，也就是大型的電子商務網站的。網上看到說採用讀寫分離有如下工具：1，oracle的logical standby2, Quest公司的SharePlex3, DSG公司的RealSyncMySQLReplication可以將master的數據復制分布到多個slave上，然後可以利用slave來分擔master的讀壓力。那麼對於前台應用來說，就要考慮如何將讀的壓力分布到多個slave上。如果每蘆陪個應用都需要來實現讀寫分離的演算法，一則成本太高，二來如果slave增加更多的機器，應用就要隨之修改。明顯的，如果在應用和資料庫間加一個專門用於實現讀寫分離的中間層，則整個系統的架構擁有更好的擴展性。MySQLProxy就是這么一個中間層代理，簡單的說，MySQLProxy就是一個連接池，負責將前台應用的連接請求轉發給後台的資料庫，並且通過使用lua腳本，可以實現復雜的連接控制和過濾，從而實現讀寫分離和負載平衡。對於應用來說，MySQLProxy是完全透明的，應用則只需要連接到MySQLProxy的監聽埠即可。
問題五：sql server 中資料庫分離和刪除資料庫的區別 分離資料庫就相當於是暫停使用，就像把一個火車廂從列車上暫時分離出來放在倉庫一樣；
刪除就和平時陪模蠢的刪除沒什麼兩樣了，直接幹掉它。
問題六：sql server 2008資料庫的分離是什麼意思 相當於將輪胎（一個Database）從汽車（DBMS）上卸下來。
此時，這個輪胎還是在的（對應到文件），但不能轉（即無法訪問這個Database）。
問題七：資料庫的分離附加與備份還原的區別 分離說的是斷開這個資料庫的連接（但可不是刪除哦，仍然存在於硬碟上，這樣就可以隨意的挪動資料庫了） 。
附加資料庫是附加已分離的資料庫文件。
備份是對本機伺服器裡面的數據進行備份。
還原資料庫是還原已備份的資料庫文件。
問題八：資料庫的分離和附加有什麼作用？可以說詳細點嗎？ 一、可以切斷資料庫的使用 (比如當資料庫日誌很大佔用了空間時，可以用分離資料庫的方法來切斷資料庫，從而刪除以前的資料庫日誌，來節省空間）
實踐中碰到 資料庫日誌 很大（10G）佔用了硬碟空間的情況處理：
方法:
1、停掉iis，然後分離資料庫
2、修改資料庫日誌的名字
3、附加資料庫，成功後可以刪除資料庫日誌
二、可以在需要更換資料庫物理存放地址時使用如果您資料庫系統安裝在系統盤（比如 C 盤），由於 C 盤容易受病毒侵害，您也許希望您的數據存碼悔放在非系統盤（比如 D 盤），要做的這點很簡單，您並不需要重裝資料庫，只要把數據「分離」，然後將相關文件移動到 D 盤的某個目錄，接著「附加」資料庫即可。
SQL Server 2000允許分離資料庫的數據和事務日誌文件，然後將其重新附加到同一台或另一台伺服器上。分離資料庫將從 SQL Server 刪除資料庫，但是保證在組成該資料庫的數據和事務日誌文件中的資料庫完好無損。然後這些數據和事務日誌文件可以用來將資料庫附加到任何 SQL Server 實例上，這使資料庫的使用狀態與它分離時的狀態完全相同。
應注意，只有「使用本資料庫的連接」數為0時，該資料庫才能分離。所以分離資料庫時盡量斷開所有對要分離資料庫操作的連接，如果還有連接資料庫的程序，會出現資料庫的連接狀態窗口，顯示正在連接此資料庫的機器以及名稱，點擊清除按鈕將從伺服器強制斷開現有的連接。
問題九：sql分離資料庫的命令怎麼寫 --首先需要使用master資料庫進行操作
use master
go
--分離資料庫
exec sp_detach_db mydb
go
--附加資料庫
exec sp_attach_db mydb,'D:\mydb_data.mdf' --後面是路徑
go
B. 電子商務網站資料庫備份的方法有哪幾種
資料庫備份一般有以下幾種方案：
直接的電商網站後台，一般都提供數據整理功能，直接導出即可。
資料庫第三方管理工具比如mysql的phpmyadmin可以直接連接資料庫導出相關數據備份。
伺服器直接操作備份，比如mysql的源文件復制備份等等
C. 數據建模的如何進行
概念建模
數據建模大致分為三個階段，概念建模階段，邏輯建模階段和物理建模階段。其中概念建模和邏輯建模階段與資料庫廠商毫無關系，換言之，與MySQL，SQL Server，Oracle沒有關系。物理建模階段和資料庫廠商存在很大的聯系，因為不同廠商對同一功能的支持方式不同，如高可用性，讀寫分離，甚至是索引，分區等。
概念建模階段
實際工作中，在概念建模階段，主要做三件事：
1. 客戶交流
2. 理解需求
3. 形成實體
這也是一個迭代，如果先有需求，盡量去理解需求，明白當前項目或者軟體需要完成什麼，不明白或者不確定的地方和客戶及時交流，和客戶double confirm過的需求，落實到實體（Package）；但是好多時候我們需要通過先和客戶交流，進而將交流結果落實到需求，之後進一步具體到實體；本文可能會涉及到一些來自於EA（Enterprise Architect 7.1）建模術語，（EA中將每個實體視為一個Package）。這里並不對各種建模工具進行比較，如Visio，EA，PowerDesigner， ERWin等；其實作為員工的我們選擇性很少，公司有哪個產品的Licence，我們就用哪個吧。
舉例說明：在一個B2C電子商務網站中，這樣的需求再普通不過了：客戶可以在該網站上自由進行購物！我們就以這個簡單例子，對其進行細分，來講解整個數據建模的過程，通過上面這句話，我們可以得出三個實體：客戶，網站，商品；就像Scrum（敏捷開發框架的一種）中倡導的一樣每個Sprint，都要產出確確實實的東西，OK，概念建模階段，我們就要產出實體。客戶和商品（我們將網站這個實體扔掉，不需要它。）
在創建這兩個實體（Package）的時候，我們記得要講對需求的理解，以及業務規則，作為Notes添加到Package中，這些信息將來會成為數據字典中非常重要的一部分，也就是所謂的元數據。BTW，EA或者其他建模工具應該都可以自動生成數據字典，只不過最終生成的格式可能不太一樣。如在Customer這個Package的Notes上，我們可以這樣寫，用戶都要通過填寫個人基本信息以及一個郵箱來注冊賬戶，之後使用這個郵箱作為登錄帳號登錄系統進行交易。
在概念建模階段，我們只需要關注實體即可，不用關注任何實現細節。很多人都希望在這個階段把具體表結構，索引，約束，甚至是存儲過程都想好，沒必要！！因為這些東西使我們在物理建模階段需要考慮的東西，這個時候考慮還為時尚早。可能有的人在這個階段擔心會不會丟掉或者漏掉一些實體?也不用擔心，2013年好多公司都在採用Scrum的開發模式，只要你當前抽象出來的實體滿足當前的User Story，或者當前的User Story裡面的實體，你都抽象出來了，就可以了！如果你再說，我們User Story太大，實體太多，不容易抽象，那就真沒辦法了，建議你們的團隊重新開Sprint 計劃會議。
邏輯建模
邏輯建模階段
對實體進行細化，細化成具體的表，同時豐富表結構。這個階段的產物是，可以在資料庫中生成的具體表及其他資料庫對象（包括，主鍵，外鍵，屬性列，索引，約束甚至是視圖以及存儲過程）。我在實際項目中，除了主外鍵之外，其他的資料庫對象我都實在物理建模階段建立，因為其他資料庫對象更貼近於開發，需要結合開發一起進行。如約束，我們可以在web page上做JavaScript約束，也可以在業務邏輯層做，也可以在資料庫中做，在哪裡做，要結合實際需求，性能以及安全性而定。
針對Customer這個實體以及我們對需求的理解，我們可以得出以下幾個表的結構，用戶基本信息表（User），登錄賬戶表（Account），評論表（Commnets,用戶可能會對產品進行評價），當然這個案例中我們還會有更多的表，如用戶需要自己上傳頭像（圖片），我們要有Picture表。
針對產品實體，我們需要構建產品基本信息表（Proct），通常情況下，我們產品會有自己的產品大類（ProctCategory）甚至產品小類（ProctSubCategory），某些產品會因為節假日等原因進行打折，因為為了得到更好的Performance我們會創建相應ProctDiscount表，一個產品會有多張圖片，因此產品圖片表（ProctPicture）以及產品圖片關系表（ProctPictureRelationship），（當然我們也可以只設計一張Picture表，用來存放所有圖片，用戶，產品以及其他）有人說產品和圖片是一對多的關系，不需要創建一個關系表啊?是的，我認為只要不是一對一的關系，我都希望創建一個關系表來關聯兩個實體。這樣帶來的好處，一是可讀性更好，實現了實體和表一一對應的關系，二是易於維護，我們只需要維護一個關系表即可，只有兩列（ProctID和PictureID），而不是去維護一個Picture表。
客戶進行交易，即要和商品發生關系，我們需要Transaction表，一個客戶會買一個或者多個商品，因為一筆Transaction會涉及一個或多個Procts，因此一個Transaction和ProctDiscount之間的關系（ProctDiscount和Proct是一一對應的關系）需要創建，我們稱其為Item表，裡面保存TransactionID以及這筆涉及到的ProctDiscountID（s），這里插一句，好多系統都需要有審計功能，如某個產品歷年來的打折情況以及與之對應的銷售情況，我們這里暫不考慮審計方面的東西。
就這樣，我們根據需求我們確定下來具體需要哪些表，進一步豐富每一個表屬性（Column），當然這裡面會涉及主鍵的選取，或者是使用代理鍵（Surrogate Key），外鍵的關聯，約束的設置等細節，這里筆者認為只要能把每個實體屬性（Column）落實下來就是很不錯了，因為隨著項目的開展，很多表的Column都會有相應的改動。至於其他細節，不同資料庫廠商，具體實現細節不盡相同。關於主鍵的選取多說一句，有的人喜歡所有的表都用自增長ID作為主鍵，而有的人希望找到唯一能標識當前記錄的一個屬性或者多個屬性作為主鍵；自增長ID作為代理主鍵，對於將來以多個類似當前Transaction System作為數據源，構建數據倉庫的時候，這些自增長ID主鍵會是一個麻煩（多個系統中，相同表存在大量主鍵重復）；使用一個屬性或多個屬性作為作為主鍵，不管主鍵是可編輯的，讀寫效率是我們必須考慮得。所以並沒有一個放之四海而皆準的原則，筆者只是給大家推薦一些考慮的因素。
物理建模
物理建模階段
EA可以將在邏輯建模階段創建的各種資料庫對象生成為相應的SQL代碼，運行來創建相應具體資料庫對象（大多數建模工具都可以自動生成DDL SQL代碼）。但是這個階段我們不僅僅創建資料庫對象，針對業務需求，我們也可能做如數據拆分（水平或垂直拆分），如B2B網站，我們可以將商家和一般用戶放在同一張表中，但是針對PERFORMANCE考慮，我們可以將其分為兩張表；隨業務量的上升，Transaction表越來越大，整個系統越來越慢，這個時候我們可以考慮數據拆分，甚至是讀寫分離（即實現MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，當然不同存儲引擎採用不同的方案），這個階段也會涉及到集群的事情，如果你是架構師或者數據建模師，這個時候你可以跟DBA說，Alright,I am done with it,now is your show time.
相信大家都知道範式，更有好多人把3NF奉為經典，3NF確實很好，但是3NF是幾十年前提出來的，那個時候的數據量以及訪問頻率和2012年完全不是一個數量級的；因此我們絕對不能一味地遵守3NF；在整個數據建模過程中，在保證數據結構清晰的前提下，盡量提高性能才是我們關注的要點，因此筆者大力倡導數據適當冗餘!
上面筆者是結合一些實際例子表達自己對數據建模的觀點，希望對讀著有用。在數據建模過程中，不要希望一步到位將資料庫設計完整，筆者不管是針對data warehouse還是Transactional Database設計，從來沒有過一次成功的經歷。隨著項目的進行，客戶和開發團隊對業務知識與日增長，因此原來的設計也在不斷完善中。畢竟，數據建模或者設計資料庫不是我們的最終目的，我們需要的是一個健壯，性能優越，易擴展，易使用的軟體!
D. sql2008主從同步 是什麼意思
sql server 主從同步是指資料庫的主庫數據同步到從庫中，數據寫入到主庫，通過sqlserver的復制分發將主庫的數據復制到從庫中，已達資料庫之間數據的一致性；一般在主資料庫壓力比較大，通過讀寫分離來給主資料庫降壓的時候需要用到；寫的時候操作主庫，讀取數據的時候操作從庫；從庫可以有一個或多個；