どこからともなくこのエラーが発生し始め、データベースまたは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の一般的なエラーのようには見えません。
更新:
マイクロソフトのサポート担当者から返信があり、メモリ使用量が完全に制限されているようです。
エラスティックプールを1層上に移動した後、エラーはなくなりました。以前にあった28 GBの代わりに56 GBのメモリがあり、エラーは発生しなくなりました。これはおそらく私たちをAzure上の別のサーバーに移動させ、おそらく今のところ問題を修正しているでしょう。サイトはメモリ使用量が約78%で稼働しており、8588のバッファキャッシュヒット率と87332のPLEを使用しています。通常の負荷時に、CPU、ワーカー、DataIOなどのボード全体で2%未満の使用率で動作しています。巨大なゴミのように。
エラーの原因を明確に特定することはできませんでしたが、現時点ではサイトが正常に動作しているため、完全なメモリ使用量であると想定しています...
Azure SQL Database(not新しいマネージドインスタンス)はカスタムSQLCLRアセンブリ(つまり、 "CLRが有効"なサーバーレベルの構成オプション)をサポートしていませんが、CLRは次の機能で内部的に使用されます。
FORMAT
PARSE
TRY_PARSE
AT TIME ZONE
COMPRESS
DECOMPRESS
sys.time_zone_info
sp_FuzzyLookupTableMaintenanceInvoke
など)もちろん、これはwouldがメモリを占有していることを指しているわけではありません。ただし、影響を受ける領域を特定するのに役立ちます。
Azure SQL DB(マネージドインスタンスではない)を使用しており、地理空間やAT TIME ZONE
私はこれと同じ問題を抱えていて、解決策を見つけることができませんでした。 MSサポートを使用すると、これが可能な解決策として考え出されたものです-10分前に行っただけですが、正当なようです :
仮説は、私たちが経験しているCLRエラーは、(弾性検索を介して)CLRを活用する外部テーブルの使用が原因であるというものです。外部テーブルの実装によりCLRスレッドが破損しているため、Microsoftが調査中です。
一部の運用保守には外部テーブルのみを使用していたため、それらを削除することができました。次に、データベースをリセットして、すべてのスレッドをリセットする必要がありました。これを行うための文書化されていないDBCCコマンドがあります。
dbcc stackdump('')
これによりデータベースが停止し、別の冗長サーバーにフェイルオーバーします。私がそれを実行したとき、約5秒の停止がありました
this のドキュメントをお読みいただけるように、CLRはAzure SQL Databaseではサポートされていません。ただし、新しい Azureマネージドインスタンス はCLRをサポートしています。
このエラーが発生したとき、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に確認させることができます。