web-dev-qa-db-ja.com

SQL Azure DBでのCLRエラーの発生

どこからともなくこのエラーが発生し始め、データベースまたはElastic Pool内の他のデータベースを呼び出すときにかなり頻繁に発生するようです。 DTUが限界に達しておらず、リソースのdmvは悪くないようです。

HRESULT 0x80131022で共通言語ランタイム（CLR）に入ることができませんでした。これは、リソース不足の状態が原因である可能性があります。 （db）

これは、システムリソースガバナープールから取得したものです

Resource Pool Name           cache_memory (MB)   used_memory (MB)
internal                     104.773437          1577.125000
default                      37.609375           38.796875
SloSecSharedPool             2.914062            8.156250
InMemBackupRestorePool       26.210937           101.437500
InMemDmvCollectorPool        186.195312          203.406250
InMemMetricsDownloaderPool   2.234375            2.250000
InMemDTAPool                 0.000000            0.000000
SloHkPool                    0.000000            0.031250
InMemQueryStorePool          22.453125           35.304687
InMemWIAutoTuningPool        3.312500            4.062500
InMemXdbLoginPool            3.976562            6.250000
PVSCleanerPool               0.000000            0.000000
InMemTdeScanPool             0.000000            0.000000
SloSharedPool1               1108.890625         1234.312500

Sys.dm_os_performance_countersから、これは過去3時間の状態です。

cpu%    data_io%   log_write%   memory_usage%   max_worker%   sessions%
22.37   73.51      16.54        41.56           5.50          0.43

これは、SQL Server 2008の過去の出来事に関連することは何も見つからないため、SQL Azureの一般的なエラーのようには見えません。

更新：

マイクロソフトのサポート担当者から返信があり、メモリ使用量が完全に制限されているようです。

Elastic Pool resource usage

エラスティックプールを1層上に移動した後、エラーはなくなりました。以前にあった28 GBの代わりに56 GBのメモリがあり、エラーは発生しなくなりました。これはおそらく私たちをAzure上の別のサーバーに移動させ、おそらく今のところ問題を修正しているでしょう。サイトはメモリ使用量が約78％で稼働しており、8588のバッファキャッシュヒット率と87332のPLEを使用しています。通常の負荷時に、CPU、ワーカー、DataIOなどのボード全体で2％未満の使用率で動作しています。巨大なゴミのように。

エラーの原因を明確に特定することはできませんでしたが、現時点ではサイトが正常に動作しているため、完全なメモリ使用量であると想定しています...

sql-serverazure-sql-databasesql-clr
7
Brandon Huber

Azure SQL Database（not新しいマネージドインスタンス）はカスタムSQLCLRアセンブリ（つまり、 "CLRが有効"なサーバーレベルの構成オプション）をサポートしていませんが、CLRは次の機能で内部的に使用されます。

  1. CLRデータ型：
    • ジオメトリ
    • 地理
    • 階層
  2. 組み込み関数：
    • sQL Server 2012で導入：
      • FORMAT
      • PARSE
      • TRY_PARSE
    • sQL Server 2016で導入：
      • AT TIME ZONE
      • COMPRESS
      • DECOMPRESS
      • sys.time_zone_info
    • 多分他の
  3. SSIS（あいまい参照/ sp_FuzzyLookupTableMaintenanceInvokeなど）
  4. 変更データキャプチャ（CDC）
  5. レプリケーション
  6. マスターデータサービス
  7. ポリシーベースの管理者（PBM。当初は「動的管理フレームワーク（DMF）」と呼ばれていました）
  8. 多分他の

もちろん、これはwouldがメモリを占有していることを指しているわけではありません。ただし、影響を受ける領域を特定するのに役立ちます。

4
Solomon Rutzky

Azure SQL DB（マネージドインスタンスではない）を使用しており、地理空間やAT TIME ZONE

私はこれと同じ問題を抱えていて、解決策を見つけることができませんでした。 MSサポートを使用すると、これが可能な解決策として考え出されたものです-10分前に行っただけですが、正当なようです ：

仮説は、私たちが経験しているCLRエラーは、（弾性検索を介して）CLRを活用する外部テーブルの使用が原因であるというものです。外部テーブルの実装によりCLRスレッドが破損しているため、Microsoftが調査中です。

一部の運用保守には外部テーブルのみを使用していたため、それらを削除することができました。次に、データベースをリセットして、すべてのスレッドをリセットする必要がありました。これを行うための文書化されていないDBCCコマンドがあります。

dbcc stackdump('')

これによりデータベースが停止し、別の冗長サーバーにフェイルオーバーします。私がそれを実行したとき、約5秒の停止がありました

3
JoeLeBaron

this のドキュメントをお読みいただけるように、CLRはAzure SQL Databaseではサポートされていません。ただし、新しい Azureマネージドインスタンス はCLRをサポートしています。

2
Alberto Morillo

このエラーが発生したとき、masterデータベースで次のクエリを実行しました。

select DATEADD(hour, DATEDIFF(hour, 0, rs.start_time), 0) as hr, max(avg_instance_memory_percent) as MaxMem 
from sys.elastic_pool_resource_stats rs
group by dateadd(hour, datediff(hour, 0, rs.start_time), 0)
order by 1

エラー発生前の数時間で最大メモリが100％に達したことがわかりました。

スケジュールに従って実行すると、95％を超えると警告が表示されます。その後、Azure SQLデータベースの再起動をオフィスアワーの外でスケジュールするか、すべてが機能しなくなる前にMicrosoftに確認させることができます。

0
Henrik Staun Poulsen