比特幣是區塊鏈的應用

比特幣是區塊鏈的應用

每個block
    10分鐘內的交易紀錄+前個block的hash值+一個數值(nonce)產生一個hash值(很長)
   
礦工的工作
    找出未被確認的block(只有一個,大家競爭),block內含10分鐘的交易
    要用電腦找出數值(nonce),讓nonce+10分鐘內的交易紀錄+前個block的hash值可以小於dufficulty
    找到後可以廣播把結果給其他礦工核可(除了10分鐘交易外,還有礦工酬勞也一併在此block),
    各方核可後才把該block掛到鏈上
   
平常的交易
    交易通常由礦工的帳本可以檢查付款方是否有足夠的金額給付,檢查過了會放到
    交易池(未被確認的block)交給礦工去計算該block

Read Committed Snapshot與SNAPSHOT isolation差異

SQL2005隔離層級
Read Committed Snapshot與SNAPSHOT isolation差異

Read Committed Snapshot只是Read Committed的進化版本,本質上並一是一種事務隔離層級,
在此模式下select語句並不會等待該row commit,而是直接讀取上一個已經commited的資料
那跟select語句使用with nolock有什麼差異?簡單說nolock一樣不會等待row commit
但是可能取到uncommited的資料(垃圾)。

SNAPSHOT isolation呢
當第一個事務啟動此隔離層級,後續每個事務對同一筆資料讀到的都是當時commited的資料
假設有個值i=10,三個session同時啟動事務
第一個session讀到10,把10給為15,commit
第二個session讀到10,把10給為15,commit,
第三個session讀到10,把10給為100,commit

然後
第一個session commit成功,另外兩個session commit會失敗

DevOps筆記

Chef
    想像一下我們現在需要搭建一台MySQL Database Slave服務器，安裝過程我們手動操作了沒過多久，又需要第二台，這時候我們會想，如果之後安裝第一台的時候把操作過程執行的命令寫成腳本，現在安裝第二台，運行一下腳本就行了，節約時間而且不容易出錯。
Chef就相當於這樣的一個腳本管理工具，但功能要強大得多，可定製性強，Chef將腳本命令代碼化，定製時只需要修改代碼，安裝的過程就是執行代碼的過程。
來源：http://heylinux.com/archives/2175.html

Continuous Integration 持續整合(CI工具)
    持續集成（CI）的目標是對開發團隊的代碼進行集成，包括代碼的構建、單元測試與集成測試的執行，以及生成執行結果的報表等等。CI使開發團隊無需將時間浪費在處理代碼衝突的問題上，因此很多人將其視為敏捷軟件開發的奠基石。
比較常見的軟體是Jenkins
來源:http://www.infoq.com/cn/news/2016/04/DevOps-continuous-integration-to

Docker
Docker 解決什麼問題?
    想像我們有網站伺服器、資料庫伺服器等。
為了兩個環境不互相影響，我們會用兩個 Virtual Machine 建立， VM 1 為網站伺服器，VM2 為資料庫伺服器。
另外，測試環境也同樣會這樣建立。兩個 Virtual Machine 建立， VM 1 為網站伺服器，VM2 為資料庫伺服器。
開發環境也是同樣這樣建立。兩個 Virtual Machine 建立， VM 1 為網站伺服器，VM2 為資料庫伺服器。
問題來了，測試、開發、上線環境都需要這樣建立，有沒有比較快的方式呢?
我們可能建立完一個環境之後，將該好幾G Mb檔案大小的 VM複製。複製完後，再對該系統環境做一些小修改。
這是目前使用 VM 的情境。
Docker 出現之後
    就再也不用複製好幾 G 的檔案，同時在一個VM內，就可以執行container 1 網站伺服器，container 2 資料庫伺服器。
Container 1 與 Container 2相互獨立不影響，每一個 Container 檔案都很小。運作起來就好像獨立的 VM 一般。
由於檔案小，又可以保有獨立的環境運作，因此在DevOps環境佈署上，Docker 成為一個火紅的話題。
來源：http://www.qa-knowhow.com/?p=1638

斯斯有三種，Join的訣竅也有三種!

最近遇到一件詭異的事，某個平常很穩定的SQL，忽然執行到逾時。上網查發現原來是統計資訊不及時導致SQL Server選錯執行計畫。原來平常SQL的Join在內部還可分為三種執行模式。似乎是如果table資料常有大量的資料異動，像是我們家APS每次跑一個計畫就要寫入上百萬筆資料，很容易因為統計資訊更新不及時出現選錯執行計畫的窘境，我們公司的DBA是建議就使用hash join 雖然不是最佳的選擇，但至少穩定。

以下為MSDN的說明:

出處:Advanced Query Tuning Concepts

SQL Server employs three types of join operations:

• Nested loops joins
• Merge joins
• Hash joins

If one join input is small (fewer than 10 rows) and the other join input is fairly large and indexed on its join columns, an index nested loops join is the fastest join operation because they require the least I/O and the fewest comparisons. For more information about nested loops, see Understanding Nested Loops Joins.
If the two join inputs are not small but are sorted on their join column (for example, if they were obtained by scanning sorted indexes), a merge join is the fastest join operation. If both join inputs are large and the two inputs are of similar sizes, a merge join with prior sorting and a hash join offer similar performance. However, hash join operations are often much faster if the two input sizes differ sihttps://www.blogger.com/blogger.g?blogID=3153720234527010496#editor/target=post;postID=2111640605181692195gnificantly from each other. For more information, see Understanding Merge Joins.
Hash joins can efficiently process large, unsorted, nonindexed inputs. They are useful for intermediate results in complex queries because:

• Intermediate results are not indexed (unless explicitly saved to disk and then indexed) and often are not suitably sorted for the next operation in the query plan.
• Query optimizers estimate only intermediate result sizes. Because estimates can be very inaccurate for complex queries, algorithms to process intermediate results not only must be efficient, but also must degrade gracefully if an intermediate result turns out to be much larger than anticipated.

The hash join allows reductions in the use of denormalization. Denormalization is typically used to achieve better performance by reducing join operations, in spite of the dangers of redundancy, such as inconsistent updates. Hash joins reduce the need to denormalize. Hash joins allow vertical partitioning (representing groups of columns from a single table in separate files or indexes) to become a viable option for physical database design. For more information, see Understanding Hash Joins.

這邊有大陸高手中文說明，有範例
 看懂SqlServer查询计划

[SSIS]當資料來源透過cursor或程式邏輯產生的,要如何取出資料集？ 使用[執行SQL工作]

1.當資料來源透過cursor或程式邏輯產生的,最後資料放在table variable,可以透過[執行SQL工作編輯器]把資料集取回

2.此結果集要指定給一個ssis變數,此變數型態為object

3.接著使用foreach將資料一筆一筆取出

4.指定foreach取出的資料,一個欄位要指定一個變數承接

5.這邊例子是透過這兩個變數組成insert語法

union與union all差異

select part,sum(qty) qty
from
(
   select part,sum(qty) qty from A
   union
   select part,sum(qty) qty from B
)
上面的語法union會把A+B撈出的資料做distinct
這樣會導致最外層sum的時候資料有短缺

同樣的SQL直接跑(4秒)跟包成proceudure跑(3分)時間差距很大

同樣的SQL直接跑(4秒)跟包成proceudure跑(3分)時間差距很大

後來查到奇怪的解決方式

把sp_commit_case的傳入的參數給local變數,然後Procedure裡原本用到傳入參數的地方都改為local變數

這裡"Parameter Sniffing"有解釋原因

如果Procudure內直接使用傳入參數當where條件的話，則SQL只會存在第一次執行時所創建的執行計劃

意思就是說只有第一次才有優化,第二次後就….

或許create procedure使用with recompile及清空procedure cache都可達成相同目的?

以上分享給大家知道

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I had the same problem as the original poster but the quoted answer did not solve the problem for me. The query still ran really slow from a stored procedure. I found another answer here "Parameter Sniffing", Thanks Omnibuzz. Boils down to using "local Variables" in your stored procedure queries, but read the original for more understanding, it's a great write up. e.g. Slow way: CREATE PROCEDURE GetOrderForCustomers(@CustID varchar(20)) AS BEGIN     SELECT *     FROM orders     WHERE customerid = @CustID END Fast way: CREATE PROCEDURE GetOrderForCustomersWithoutPS(@CustID varchar(20)) AS BEGIN     DECLARE @LocCustID varchar(20)     SET @LocCustID = @CustID       SELECT *     FROM orders     WHERE customerid = @LocCustID END Hope this helps somebody else, doing this reduced my execution time from 5+ minutes to about 6-7 seconds.