SQL Server：チューニング＞複数行を取得する際のユーザ定義関数の使用方法について（処理が遅い場合の対策）

複数行を取得する際に使用するユーザ定義関数のチューニングについて

下記のユーザ定義関数があったとします。
create function fn_GetProductName(@ProductID int)
returns nvarchar(50)
as
begin
  declare @ProductName as nvarchar(50)
  set @productName = (select [name] from Product where ProductID = @ProductID)
  return @productName
end

↓のクエリで10万行を返すような処理をすると処理時間がとても掛かってしまいます。
select fn_GetProductName(ProductID), InStock, ReorderLevel from Inventory

原因は行単位に関数が実行されるているためです。

↓この対策は、ユーザ定義関数を使わずに
１）サブクエリを使用する
select (select [name] from Product P where P.ProductID = I.ProductID), InStock, ReorderLevel from Inventory I

２）inner joinを使用する（関係性によっては、left outer joinとisnullを使ってね。）
select P.[name], InStock, ReorderLevel from Product P
inner join Inventory I on P.ProductID = I.ProductID

などがあります。
良いハード設計に組み込まれたSQL Serverは正しく使えばそれなりに早いです。

SQL Serverでインデックスを上手く使ってくれない場合について（データのバラツキが少ないキー項目に対する処理について）

Customerテーブル（とても大量のデータ）には、clusterd indexがCustomerID、nonclustered indexがStatusがあります。

その場合に、

select CustomerName, Address, City from Customers where Status = @Status

のクエリが非常に異常に遅くなります。実行プランを見てみるとフルスキャン（全走査）が走っています。

原因は、Status列のindexについて統計情報のバラツキ（標準偏差）が小さいのでオプティマイザが平均してフルスキャンしたほうが早いと判断しているのだと考えられます。

この対策については、案が２つあって

１）対象データ量がある程度多い場合は、nonclustered indexにCustomerName, Address, Cityを追加して上げるといい。（バラツキをもたせると同時に、データノードへのアクセスを抑制する）
２）抽出するデータ量が少ない場合は、nonclustered indexをヒント指定が良い。（データノードへの索引が許容できるという判断の場合の選択）

という選択肢があります。

選択における数式的な分岐点は、

SAMSUNG Magician SSD 850 PRO 2TB 合計書き込みバイト数がついに40TBを超えた

850 PROは総書き込みバイト量（TBW）が最大300TBで10年間の保証をうたっているので、先に300TBの方に達しますね。

その前にM.2に切り替える予定なのですが、十分な耐久性があるSSDだと感じています。

予定では、後１～２年を使いまわして、このThinkPad T420sと共にSATAはお別れ予定です。

New-AzureRmVM : Long running operation failed with status 'Failed'. Additional Info:'Blob https://uploadstorageaccount.blob.core.windows.net/vhds/productsv-OsDisk.vhd is already in use by another disk belonging to VM 'productSV'. You can examine the blob metadata for the disk reference information.' ErrorCode: DiskBlobAlreadyInUseByAnotherDisk

１）エラー
PS C:\Users\Administrator>     New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm

New-AzureRmVM : Long running operation failed with status 'Failed'. Additional Info:'Blob https://uploadstorageaccount.blob.core.windows.net/vhds/productsv-OsDisk.vhd is already in use by another disk belonging to VM 'productSV'. You can examine the blob metadata for the disk reference information.'
ErrorCode: DiskBlobAlreadyInUseByAnotherDisk
ErrorMessage: Blob https://uploadstorageaccount.blob.core.windows.net/vhds/productsv-OsDisk.vhd is already in use by another disk belonging to VM 'PRODUCTSV'. You can examine the blob metadata for the disk reference information.
StartTime: 2018/02/10 9:27:21
EndTime: 2018/02/10 9:27:21
OperationID: 400477a6-xxxx-xxxx-xxxx-ab95cef71e92
Status: Failed
発生場所 行:1 文字:5
+     New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM  ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureRmVM]、ComputeCloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.NewAzureVMCommand

２）原因と対応   
作業用のストレージアカウントに既に同盟のBlogがあるためのエラーです。対象のファイルを削除して再実行しする。

StorageAccountに既に同名のVHDディスクがあり、「https://uploadstorageaccount.blob.core.windows.net/vhds/productsv-OsDisk.vhd」を変更、または、再駆除してくださいということです。

New-AzureRmVM : Changing property 'osDisk.image.uri' is not allowed. ErrorCode: PropertyChangeNotAllowed

１）エラ－
PS C:\Users\Administrator>     New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm

New-AzureRmVM : Changing property 'osDisk.image.uri' is not allowed.
ErrorCode: PropertyChangeNotAllowed
ErrorMessage: Changing property 'osDisk.image.uri' is not allowed.
StatusCode: 409
ReasonPhrase: Conflict
OperationID : 67fb0b1e-xxxx-xxxx-xxxx-2b184a8eff43
発生場所 行:1 文字:5
+     New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM  ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureRmVM]、ComputeCloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.NewAzureVMCommand

２）対応

「Changing property 'osDisk.image.uri' is not allowed.」ということで、既に同名の仮想マシンが存在しているためにこのエラーが発生しています。
過去に途中まで作っていた起動に失敗する仮想マシンを見つけてそれを消して、再実行したら上手く仮想マシンを作成することができました。

New-AzureRmVM : Long running operation failed with status 'Failed'. Additional Info:'StorageAccount 'uploadstorageaccount' associated with VM 'PRODUCTSV' for boot diagnostics encountered an error. Please look at the error code for more information about the error.' ErrorCode: StorageAccountLocationMismatch

１）エラー
PS C:\Users\Administrator>     New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm

New-AzureRmVM : Long running operation failed with status 'Failed'. Additional Info:'StorageAccount 'uploadstorageaccount' associated with VM 'PRODUCTSV' for boot diagnostics encountered an error. Please look at the error code for more information about the error.'
ErrorCode: StorageAccountLocationMismatch
ErrorMessage: StorageAccount 'uploadstorageaccount' associated with VM 'PRODUCTSV' for boot diagnostics encountered an error. Please look at the error code for more information
 about the error.
StartTime: 2018/02/09 10:49:40
EndTime: 2018/02/09 10:49:40
OperationID: 064d5ac1-xxxx-xxxx-b1f3-83f5b0a2038c
Status: Failed
発生場所 行:1 文字:5
+     New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM  ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureRmVM]、ComputeCloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Compute.NewAzureVMCommand

２）対応

エラー「StorageAccountLocationMismatch」ということで、一般化したVHDが置いてあるロケーションと作成するVMのロケーションが異なっていることが問題だと認識して、

使用する一般化したVHDディスクを東日本から、西日本へ送って対応しまいた。

Azure IaaSにDシリーズとAシリーズのみで、EシリーズやBシリーズ、Gシリーズ、Lシリーズが出てこない問題（西日本、東日本）

仮想マシンを完全に再起動しないと出てきません。
OSを停止させただけでは、仮想マシン基盤が動作しており、（もちろん課金対象）リージョン全体で使える仮想マシンの種類が選べません。

正しくは、Azure　Portalサイトで仮想マシンの「停止」を行い、サイズを変更する必要があります。