Azure SQL Managed Instance (MI) で試したいことがあったのでデプロイして触っていたところ、MI でプライベートエンドポイント接続が設定できるようになっていました。
SQL Server でトランザクション分離レベルに READ COMMITTED を使用した主キーの検索で、必ずキーの共有ロックがとられるということではないというお話
インストールタイプの SQL Server のトランザクション分離レベルのデフォルトは SNAPSHOT が使用されない、READ COMMITTED が使用されており、データの検索を行った際にはロックが取得されるというのが有名な話だと思います。
N_NATIONKEY が主キーとなっているとき、次のようなクエリを実行した場合、どのようなロックがとられるでしょうか？
SELECT * FROM NATION WHERE N_NATIONKEY = '0'
READ COMMITTED が使用されているので「主キーに対しての検索なので主キーまたは検索対象のレコードに対して共有ロックが取得される」と考えることがあるのではないでしょうか？
実際には、「取得されるロックは状態によって変わるため、主キーによる検索でも、共有ロックが取得されないケースがある」というのが正解となります。
本投稿ではこの動作についてまとめてみたいと思います
CPU 要件を満たしていているが Nested Hyper-V (入れ子になった仮想化) が有効化できない場合の対応
検証用で使用している Intel NUC Gen11 (NUC11TNHv70L) の CPU は、Core i7-1185G7 が搭載されており、VT-x が使用できますので、Nested Hyper-V (入れ子になった仮想化) を使用することができる CPU となっています。
Nested Hyper-V の有効化については、入れ子になった仮想化による仮想マシンでの Hyper-V の実行 で公開されており、今回使用している NUC のような物理ハードウェア上にインストールした仮想マシンで実行するのであれば、
- Nested Hyper-V を有効にしたい仮想マシンが停止した状態で、Nested Hyper-V を有効化
- Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
- Nested Hyper-V を有効にしたい仮想マシンで MAC アドレスのスプーフィングを有効化する
- Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing On
ことで、Nested Hyper-V を使用することができます。
しかし、今回使用している Gen 11 の NUC では、上記の対応を行っても Nested Hyper-V を有効化することができませんでした。
Twitter でつぶやいたところ次のようなアドバイスをいただき、教えていただいた方法を使用することで Nested Hyper-V を有効化することができました。
こちらのコマンドではどうでしょうか？
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V,RSAT-Hyper-V-Tools-Feature,Microsoft-Hyper-V-Management-PowerShell
— いまにゅー (@imanyu) December 17, 2021
今後も何回か同じ事象でハマりそうなので、対応方法を残しておきたいと思います。
Azure Purview のパブリックネットワークアクセスを拒否した際の挙動について
Azure Purview では、「ネットワーク」の設定に「パブリックネットワークアクセスを拒否 (Deny Public Network Access)」という設定があります。
デフォルトでは「許可」となっており、初期状態であれば、Purview へのアクセス / Purview からのデータ収集 (インジェスト) を阻害する要因はないのですが、この設定を「拒否」にすると、様々なネットワークアクセスに影響が出てきます。
本投稿では、パブリックネットワークアクセスを「拒否」にした場合の挙動についてまとめておきたいと思います。
Data Migration Assistant (DMA) によるデータベース アップグレード / マイグレーション評価の応用方法
SQL Server のアップグレード / マイグレーションを実施する際には、SQL Server の互換性を考慮する必要があります。
SQL Server の互換性についてのドキュメントについては次のような情報があります。
SQL Server のドキュメントは 2016 以降とそれより前のバージョンでドキュメントが分かれており、バージョンによって記載されている互換性レベルのバージョンが異なっているため、いくつかのバージョンのドキュメントを組み合わせる必要があります。(SQL Server 2019 のドキュメントには、SQL Server 2016 以降の情報が含まれています)
- 互換性レベル
- SQL Server 2008 : ALTER DATABASE 互換性レベル (Transact-SQL)
- SQL Server 2012 : ALTER DATABASE 互換性レベル (Transact-SQL)
- SQL Server 2014 : ALTER DATABASE 互換性レベル (Transact-SQL)
- SQL Server 2019 : ALTER DATABASE (Transact-SQL) 互換性レベル
- SQL Server 2008 : SQL Server データベース エンジンの旧バージョンとの互換性
- SQL Server 2012 : SQL Server データベース エンジンの旧バージョンとの互換性
- SQL Server 2014 : SQL Server データベース エンジンの旧バージョンとの互換性
- SQL Server 2019 : SQL Server で廃止されたデータベース エンジンの機能
現時点で非推奨とさている機能を使用しているかについては、パフォーマンスモニターのオブジェクトとしても情報が提供されており、次のカウンターの情報から使用状況を把握することもできるようになっています。
様々な情報が公開されていますが、「自分が使用している環境でどのような非互換となる情報が該当するか」を一つ一つチェックして影響度を把握することは工数を積んで人海戦術で対応をしようとしても、抜けなく各項目の対応状況を網羅することは現実的には難しいのではないでしょうか？
アップグレード / マイグレーションによる影響を確認するためのツールとして、SQL Server では、Data Migration Assistant (DMA) というツールが提供されています。このツールは SQL Server Upgrade Advisor の後継となり、現在の SQL Server 環境のアップグレード / マイグレーションについては、DMA が使用されます。
このツールをアップグレード対象の SQL Server に対して実行することで、環境を変更することの影響度を評価 (アセスメント) することができ、上述した各種ドキュメントで記載されている内容に対して、どの項目が該当する可能性があるかをツールの実行で機械的に判断することができ、環境の移行に伴う問題の評価を容易に実施することができます。
バージョンの変更 / 互換性レベルの変更についての影響度を評価することができ、新しい環境の SQL Server を使用する際の問題の把握 / 設定の変更の影響度を確認するためには、DMA の利用が推奨されています。
本投稿では、DMA を使用した評価の応用方法についてまとめたいと思います。
Azure Automation を Azure Arc の 拡張機能ベースの Hybrid Runbook Worker で実行する際の注意点 (2021/11 時点の暫定対応)
Azure Automation の Runbook を任意の環境上で動作させる方法として、Hybrid Runbook Worker があります。
Hybrid Runbook Worker を使用することで、任意の環境上で Automation の Runbook を実行することができるようになりますので、オンプレミスの環境や Azure VM 上で Runbook を実行するということが可能となります。
Hybrid Runbook Worker の導入方法としては、エージェントベースワーカー (v1) と拡張機能ベースワーカー (v2) の 2 種類があります。
- Automation でエージェントベースの Windows Hybrid Runbook Worker をデプロイする
- 拡張機能ベースの Windows または Linux ユーザー Hybrid Runbook Worker を Automation にデプロイする (プレビュー)
エージェントベースについては、Log Analytics ワークスペースへの接続が必要でした。
拡張機能ベースについては、Log Analytics ワークスペースに接続はする必要はなく、オンプレミスの環境であれば、Azure Arc Enabled Server の拡張機能としてインストールをすることができます。(Azure VM の場合は、Arc ではなく、Azure VM エージェントの拡張機能としてインストールできます)
Azure Arc が導入されている環境を Hybrid Runbook Worker でしようとした場合、現時点ではエラーとなるケースがあるようです。
原因都回避策については、次の Q＆A で解説が行われており、現時点では既知の問題となるようです。
追記
2022/1/25 時点では、問題が解決され、Automation アカウントのマネージド ID が有効な状態でも、Runbook が実行できるようになりました。
AKS on Azure Stack HCI の v1.21.2 の k8s でコントロールプレーンノードの再起動後に k8s が起動しない
タイトルの通りですが、AKS on Azure Stack HCI の k8s を v1.21.2 で展開した後に、コントロールプレーンノードを再起動した後に k8s が起動しないという事象が発生しました。
「systemctl status kubelet」で状態を確認してみると、次のようなエラーが発生し、kubelet が起動していませんでした。
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.936688 741 kuberuntime_sandbox.go:68] "Failed to create sandbox for pod" err="rpc error: code = Unknown desc = failed to get sandbox image \"ecpacr.azurecr.io/pause:3.2\": failed to pull image \"ec
pacr.azurecr.io/pause:3.2\": failed to pull and unpack image \"ecpacr.azurecr.io/pause:3.2\": failed to resolve reference \"ecpacr.azurecr.io/pause:3.2\": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized" pod="kube-system
/etcd-moc-lrr9qh1ew26"
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.936713 741 kuberuntime_manager.go:790] "CreatePodSandbox for pod failed" err="rpc error: code = Unknown desc = failed to get sandbox image \"ecpacr.azurecr.io/pause:3.2\": failed to pull image \"ec
pacr.azurecr.io/pause:3.2\": failed to pull and unpack image \"ecpacr.azurecr.io/pause:3.2\": failed to resolve reference \"ecpacr.azurecr.io/pause:3.2\": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized" pod="kube-system
/etcd-moc-lrr9qh1ew26"
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.936764 741 pod_workers.go:190] "Error syncing pod, skipping" err="failed to \"CreatePodSandbox\" for \"etcd-moc-lrr9qh1ew26_kube-system(8e85a0583a698c64f4daca0d375decfa)\" with CreatePodSandboxErro
r: \"Failed to create sandbox for pod \\\"etcd-moc-lrr9qh1ew26_kube-system(8e85a0583a698c64f4daca0d375decfa)\\\": rpc error: code = Unknown desc = failed to get sandbox image \\\"ecpacr.azurecr.io/pause:3.2\\\": failed to pull image \\\"ecpacr.azurecr.io/pause:3
.2\\\": failed to pull and unpack image \\\"ecpacr.azurecr.io/pause:3.2\\\": failed to resolve reference \\\"ecpacr.azurecr.io/pause:3.2\\\": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized\"" pod="kube-system/etcd-moc-l
rr9qh1ew26" podUID=8e85a0583a698c64f4daca0d375decfa
Nov 30 11:35:13 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:13.981869 741 kubelet.go:2291] "Error getting node" err="node \"moc-lrr9qh1ew26\" not found"
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.035070 741 event.go:273] Unable to write event: '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"moc-lrr9qh1ew26.16bc4fcc087e2ba6", GenerateName:"", Namespace
:"default", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil),
Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:"", ManagedFields:[]v1.ManagedFieldsEntry(nil)}, InvolvedObject:v1.ObjectReference{Kind:"Node", Namespace:"", Name:"moc-lrr9qh1ew26", UID:"moc-lrr
9qh1ew26", APIVersion:"", ResourceVersion:"", FieldPath:""}, Reason:"Starting", Message:"Starting kubelet.", Source:v1.EventSource{Component:"kubelet", Host:"moc-lrr9qh1ew26"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xc061a0f98b59afa6, ext:11623948584, loc:(
*time.Location)(0x74be600)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xc061a0f98b59afa6, ext:11623948584, loc:(*time.Location)(0x74be600)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v
1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Post "https://10.5.0.2:6443/api/v1/namespaces/default/events": EOF'(may retry after sleeping)
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.082278 741 kubelet.go:2291] "Error getting node" err="node \"moc-lrr9qh1ew26\" not found"
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: I1130 11:35:14.104104 741 trace.go:205] Trace[2056973426]: "Reflector ListAndWatch" name:k8s.io/client-go/informers/factory.go:134 (30-Nov-2021 11:35:02.280) (total time: 11824ms):
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: Trace[2056973426]: [11.824032031s] [11.824032031s] END
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.104137 741 reflector.go:138] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1.RuntimeClass: failed to list *v1.RuntimeClass: an error on the server ("") has prevented the request from
succeeding (get runtimeclasses.node.k8s.io)
Nov 30 11:35:14 moc-lrr9qh1ew26 kubelet[741]: E1130 11:35:14.182788 741 kubelet.go:2291] "Error getting node" err="node \"moc-lrr9qh1ew26\" not found"
kubelet の起動のパラメーターを見ると、「–pod-infra-container-image=ecpacr.azurecr.io/pause:3.2」が指定されており、上記のメッセージでも pause コンテナーのイメージのアクセスでエラーが発生しているようでした。
Ignite 2021 / PASS Data Community Summit 2021 で発表された SQL Server ベースの環境のアップデート
2021/11/3～4 に開催されていて Ignite 2021、2021/11/10~12 で開催されていた PASS Data Community Summit 2021 で SQL Server ベースのアップデートが多数発表されました。
これらのイベントで発表されたアップデートについて一通り確認ができ、次の投稿に情報を反映しました。
- 11/03 : Ignite 2021 で SQL Server 2022 がアナウンスされました
- 11/03 : Ignite 2021 で発表のあった SQL Server / SQL Database 関連のアップデート
- 11/08 : Ignite 2021 で Azure Arc Enabled Data Service のアップデートが発表されています
- 11/11 : PASS Data Community SUMMIT 2021 で SQL Server 2022 関連の情報の公開が行われています
各投稿の目次が次になりますが、大小合わせると様々なアップデートがのアナウンスが行われていますね。
PASS Data Community SUMMIT 2021 で SQL Server 2022 関連の情報の公開が行われています
2021/11/10 から開催されている PASS Data Community SUMMIT 2021 で Ignite 2021 に続き、SQL Server 2022 関連のセッションが実施され様々な情報が公開されています。
今回が、Redgate が PASS のコミュニティオーナーになってからの初めての開催ですね。
今回はオンライン開催で無料で参加 / 登録ができますので、興味のある方は参加してみてはいかがでしょうか。
PASS のキーノートでは様々な新しい発表があるのですが、今回は、Ignite 2021 からの間隔が短いので、Day 1 Keynote — Bridge to a new universe: the end-to-end Azure Data Platform については、Ignite 2021 と同等の発表となっていたように思えます。
PASS Data Community Summit 2021 では、Ignite 2021 内でアナウンスのあったように、SQL Server 2022 に特化している個別セッションが開催されています。
- Introducing SQL Server 2022
- Azure SQL and SQL Server 2022: Intelligent Database Futures
- SQL Server 2022: The hybrid data platform
- SQL Server 2022 Storage Engine Capabilities
- SQL Server and Intel: Unlock Better SQL Performance and Scalability
Ignite 前後で発表された内容については Ignite 2021 で SQL Server 2022 がアナウンスされました でまとめていますので、本投稿は PASS 開催以降に新しく発表された内容に注目していきたいと思います。
なお、PASS 2021 の各セッションのスライドについては、各セッションの URL 内の他に、 Bob Ward の One Drive で公開されているようです。
Ignite 2021 で Azure Arc Enabled Data Service のアップデートが発表されています
Ignite 2021 で CONLL104 : Introduction to Azure Arc-enabled Data Services でアナウンスが行われていますが、Azure Arc Enabled Data Services でいくつかのアップデートが行われています。
Release notes – Azure Arc-enabled data services でも 11 月のアップデートとして、様々な追加機能がアナウンスされています。
私がキャッチアップしているのは、 Arc Enabled SQL Managed Instance の部分となりますが、Enabled MI に関係するアップデートをキャッチアップしておこうと思います。
GA 時には「v1.0.0_2021-07-30」というイメージタグが使用されていたのですが、今回のアップデートでは、「v1.1.0_2021-11-02」が各環境のイメージとして使用されるようになりました。
「az arcdata dc list-upgrades」でイメージを確認することもできるようですね。
