{"id":97702,"date":"2020-10-20T20:42:28","date_gmt":"2020-10-20T18:42:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah"},"modified":"2020-10-20T20:42:28","modified_gmt":"2020-10-20T18:42:28","slug":"rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah","title":{"rendered":"Entschl\u00fcsselung von Key und Page WaitResource in Deadlocks und Sperren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Wenn Sie den Bericht \u00fcber blockierte Prozesse (blocked process report) verwenden oder die von SQL Server bereitgestellten Deadlock-Diagramme gelegentlich sammeln, werden Sie mit solchen Dingen konfrontiert: <\/p>\n<blockquote><p>waitresource=\"PAGE: 6:3:70133\"<\/p>\n<p>waitresource=\"KEY: 6:72057594041991168 (ce52f92a058c)\"<\/p><\/blockquote>\n<p>\nManchmal enth\u00e4lt das riesige XML, das Sie analysieren, mehr Informationen (die Deadlock-Grafiken enthalten eine Liste von Ressourcen, die helfen, die Namen des Objekts und des Indexes herauszufinden), aber nicht immer.<\/p>\n<p>Dieser Text hilft Ihnen, sie zu entschl\u00fcsseln.<\/p>\n<p>Alle Informationen, die hier vorhanden sind, gibt es im Internet an verschiedenen Stellen, sie sind nur sehr verstreut! Ich m\u00f6chte alles zusammenbringen \u2013 von DBCC PAGE \u00fcber hobt_id bis hin zu den undocumented %%physloc%% und %%lockres%% Funktionen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nZuerst sprechen wir \u00fcber Wartezeiten bei PAGE-Sperren und danach \u00fcber KEY-Sperren.<\/p>\n<h3>1) waitresource=\"PAGE: 6:3:70133\" = Datenbank_Id: FileId: PageNumber<\/h3>\n<p>\nWenn Ihre Anfrage auf eine PAGE-Sperre wartet, gibt SQL Server Ihnen die Adresse dieser Seite.<\/p>\n<p>Wenn wir \"PAGE: 6:3:70133\" aufschl\u00fcsseln, erhalten wir:<\/p>\n<ul>\n<li>database_id = 6<\/li>\n<li>data_file_id = 3<\/li>\n<li>page_number = 70133<\/li>\n<\/ul>\n<h4>1.1) Entschl\u00fcsseln des database_id<\/h4>\n<p>\nLassen Sie uns den Namen der Datenbank mit der Abfrage finden:<\/p>\n<pre><code class=\"sql\">SELECT \n    name \nFROM sys.databases \nWHERE database_id=6;\nGO<\/code><\/pre>\n<p>\nDas ist \u00f6ffentlich zug\u00e4nglich <noindex><a rel=\"nofollow\" href=\"https:\/\/www.littlekendra.com\/2016\/09\/13\/deadlock-code-for-the-wideworldimporters-sample-database\/\">DB WideWorldImporters<\/a><\/noindex> auf meinem SQL Server.<\/p>\n<h4>1.2) Suchen des Namens der Datendatei \u2013 falls es Sie interessiert<\/h4>\n<p>\nWir werden data_file_id im n\u00e4chsten Schritt verwenden, um den Namen der Tabelle zu finden. Sie k\u00f6nnen einfach zum n\u00e4chsten Schritt \u00fcbergehen, aber wenn Sie am Namen der Datei interessiert sind, k\u00f6nnen Sie ihn finden, indem Sie die Abfrage im Kontext der gefundenen DB ausf\u00fchren und data_file_id in diese Abfrage einsetzen:<\/p>\n<pre><code class=\"sql\">USE WideWorldImporters;\nGO\nSELECT \n    name, \n    physical_name\nFROM sys.database_files\nWHERE file_id = 3;\nGO<\/code><\/pre>\n<p>\nIn der DB WideWorldImporters ist dies eine Datei mit dem Namen WWI_UserData und sie wurde bei mir in C:MSSQLDATAWideWorldImporters_UserData.ndf wiederhergestellt. (Ups, Sie haben mich dabei erwischt, wie ich die Dateien auf dem Systemlaufwerk abgelegt habe! Nein! Das war peinlich).<\/p>\n<h4>1.3) Erhalten des Objekt-Namens aus DBCC PAGE<\/h4>\n<p>\nJetzt wissen wir, dass die Seite #70133 in der Datendatei 3 zur DB WorldWideImporters geh\u00f6rt. Wir k\u00f6nnen den Inhalt dieser Seite mit dem undocumented DBCC PAGE und dem Trace-Flag 3604 anschauen.<br \/>\nHinweis: Ich ziehe es vor, DBCC PAGE auf einer wiederhergestellten Kopie aus einem Backup auf einem anderen Server zu verwenden, da es eine undocumented Funktion ist. In einigen F\u00e4llen kann es <noindex><a rel=\"nofollow\" href=\"https:\/\/connect.microsoft.com\/SQLServer\/feedback\/details\/776144\/dbcc-page-incorrect-output-with-filtered-indexes\">zu einem Dump f\u00fchren.<\/a><\/noindex> (<i>Hinweis des \u00dcbersetzers \u2013 der Link f\u00fchrt leider ins Leere, aber laut URL d\u00fcrfte es sich um gefilterte Indizes handeln<\/i>).<\/p>\n<pre><code class=\"sql\">\/* This trace flag makes DBCC PAGE output go to our Messages tab\ninstead of the SQL Server Error Log file *\/\nDBCC TRACEON (3604);\nGO\n\/* DBCC PAGE (DatabaseName, FileNumber, PageNumber, DumpStyle)*\/\nDBCC PAGE ('WideWorldImporters',3,70133,2);\nGO<\/code><\/pre>\n<p>\nWenn Sie zu den Ergebnissen scrollen, k\u00f6nnen Sie object_id und index_id finden.<br \/>\n<img decoding=\"async\" alt=\"Entschl\u00fcsselung von Key und Page WaitResource in Deadlocks und Sperren\" src=\"\/wp-content\/uploads\/2020\/10\/c5a42f36fb7a87cfd2e11adfef3caa17.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nFast fertig! Jetzt k\u00f6nnen Sie die Namen des Schemas und des Index mit dieser Abfrage finden:<\/p>\n<pre><code class=\"sql\">USE WideWorldImporters;\nGO\nSELECT \n    sc.name as schema_name, \n    so.name as object_name, \n    si.name as index_name\nFROM sys.objects as so \nJOIN sys.indexes as si on \n    so.object_id=si.object_id\nJOIN sys.schemas AS sc on \n    so.schema_id=sc.schema_id\nWHERE \n    so.object_id = 94623380\n    and si.index_id = 1;\nGO<\/code><\/pre>\n<p>\nUnd so sehen wir, dass das Warten auf die Sperre auf dem Index PK_Sales_OrderLines der Tabelle Sales.OrderLines war.<\/p>\n<p>Hinweis: In SQL Server 2014 und h\u00f6her k\u00f6nnen Sie den Objektnamen auch \u00fcber die undocumented DMO sys.dm_db_database_page_allocations finden. Sie m\u00fcssen jedoch jede Seite in der DB abfragen, was f\u00fcr gro\u00dfe Datenbanken nicht wirklich sch\u00f6n aussieht; deshalb habe ich DBCC PAGE verwendet.<\/p>\n<h4>1.4) Kann man die Daten auf der Seite sehen, die blockiert war?<\/h4>\n<p>\nNaja, ja. Aber... sind Sie sich sicher, dass Sie das wirklich brauchen?<br \/>\nEs ist selbst bei kleinen Tabellen langsam. Aber es ist irgendwie cool, also, da Sie bis hierher gelesen haben... lassen Sie uns \u00fcber %%physloc%% sprechen!<\/p>\n<p>%%physloc%% ist ein undocumented St\u00fcck Magie, das die physische ID f\u00fcr jeden Datensatz zur\u00fcckgibt. Sie k\u00f6nnen es verwenden <noindex><a rel=\"nofollow\" href=\"http:\/\/www.sqlskills.com\/blogs\/paul\/sql-server-2008-new-undocumented-physical-row-locator-function\/\">%%physloc%% zusammen mit sys.fn_PhysLocFormatter in SQL Server 2008 und h\u00f6her<\/a><\/noindex>.<\/p>\n<p>Jetzt, da wir wissen, dass wir eine Sperre auf die Seite in Sales.OrderLines anwenden wollten, k\u00f6nnen wir alle Daten in dieser Tabelle, die in der Datendatei #3 auf Seite #70133 gespeichert sind, mit dieser Abfrage ansehen:<\/p>\n<pre><code class=\"sql\">Use WideWorldImporters;\nGO\nSELECT \n    sys.fn_PhysLocFormatter (%%physloc%%),\n    *\nFROM Sales.OrderLines (NOLOCK)\nWHERE sys.fn_PhysLocFormatter (%%physloc%%) like '(3:70133%'\nGO<\/code><\/pre>\n<p>Wie ich sagte \u2013 es ist selbst bei winzigen Tabellen langsam. Ich habe NOLOCK zur Abfrage hinzugef\u00fcgt, weil wir sowieso keine Garantien haben, dass die Daten, die wir sehen wollen, genau die gleichen sind, die zum Zeitpunkt der Blockierung vorhanden waren \u2013 wir k\u00f6nnen also ruhig dirty reads durchf\u00fchren.<br \/>\nAber hurra, die Abfrage liefert mir genau die 25 Zeilen, um die sich unsere Abfrage gestritten hat<br \/>\n<img decoding=\"async\" alt=\"Entschl\u00fcsselung von Key und Page WaitResource in Deadlocks und Sperren\" src=\"\/wp-content\/uploads\/2020\/10\/e7909bb7c496d9509e5f5a1aa30a135a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nGenug von PAGE-Sperren. Was, wenn wir auf eine KEY-Sperre warten?<\/p>\n<h3>2) waitresource=\"KEY: 6:72057594041991168 (ce52f92a058c)\" = Database_Id, HOBT_Id (magischer Hash, der mit %%lockres%% entschl\u00fcsselt werden kann, falls Sie das wirklich wollen)<\/h3>\n<p>Wenn Ihre Abfrage versucht, eine Sperre auf einen Datensatz im Index anzuwenden und selbst blockiert wird, erhalten Sie einen ganz anderen Typ von Adresse.<br \/>\nZerlegen wir \"6:72057594041991168 (ce52f92a058c)\" in Teile, erhalten wir:<\/p>\n<ul>\n<li>database_id = 6<\/li>\n<li>hobt_id = 72057594041991168<\/li>\n<li>magischer Hash = (ce52f92a058c)<\/li>\n<\/ul>\n<h4>2.1) Entschl\u00fcsseln der database_id<\/h4>\n<p>\nEs funktioniert genau wie das Beispiel oben! Wir finden den DB-Namen mit einer Abfrage:<\/p>\n<pre><code class=\"sql\">SELECT \n    name \nFROM sys.databases \nWHERE database_id=6;\nGO<\/code><\/pre>\n<p>\nIn meinem Fall ist es immer noch dasselbe <noindex><a rel=\"nofollow\" href=\"https:\/\/www.littlekendra.com\/2016\/09\/13\/deadlock-code-for-the-wideworldimporters-sample-database\/\">DB WideWorldImporters<\/a><\/noindex>.<\/p>\n<h4>2.2) Entschl\u00fcsseln von hobt_id<\/h4>\n<p>\nIm Kontext der gefundenen DB muss eine Abfrage an sys.partitions mit einem Paar Joins durchgef\u00fchrt werden, die helfen, die Namen der Tabelle und des Index zu bestimmen\u2026<\/p>\n<pre><code class=\"sql\">USE WideWorldImporters;\nGO\nSELECT \n    sc.name as schema_name, \n    so.name as object_name, \n    si.name as index_name\nFROM sys.partitions AS p\nJOIN sys.objects as so on \n    p.object_id=so.object_id\nJOIN sys.indexes as si on \n    p.index_id=si.index_id and \n    p.object_id=si.object_id\nJOIN sys.schemas AS sc on \n    so.schema_id=sc.schema_id\nWHERE hobt_id = 72057594041991168;\nGO<\/code><\/pre>\n<p>\nEr sagt mir, dass die Abfrage auf die Sperre von Application.Countries gewartet hat, wobei der Index PK_Application_Countries verwendet wird.<\/p>\n<h4>2.3) Jetzt ein wenig Magie %%lockres%% \u2014 wenn Sie herausfinden m\u00f6chten, welcher Datensatz gesperrt war<\/h4>\n<p>\nWenn ich wirklich wissen m\u00f6chte, auf welcher Zeile die Sperre ben\u00f6tigt wurde, kann ich dies mit einer Abfrage auf die Tabelle selbst herausfinden. Wir k\u00f6nnen die nicht dokumentierte Funktion %%lockres%% verwenden, um den Datensatz zu finden, der mit dem magischen Hash \u00fcbereinstimmt.<br \/>\nBeachten Sie, dass diese Abfrage die gesamte Tabelle durchsuchen wird, und bei gro\u00dfen Tabellen kann das ziemlich unangenehm sein:<\/p>\n<pre><code class=\"sql\">SELECT\n    *\nFROM Application.Countries (NOLOCK)\nWHERE %%lockres%% = '(ce52f92a058c)';\nGO<\/code><\/pre>\n<p>\nIch habe NOLOCK hinzugef\u00fcgt (<noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/Aschenbrenner\/status\/788036874891853824\">auf den Rat von Klaus Aschenbrenner auf Twitter<\/a><\/noindex>) weil Sperren problematisch werden k\u00f6nnen. Wir m\u00f6chten einfach nur sehen, was dort jetzt ist, und nicht, was dort war, als die Transaktion begann \u2013 ich denke nicht, dass uns die Konsistenz der Daten wichtig ist.<br \/>\nVoil\u00e0, der Datensatz um den wir gek\u00e4mpft haben!<br \/>\n<img decoding=\"async\" alt=\"Entschl\u00fcsselung von Key und Page WaitResource in Deadlocks und Sperren\" src=\"\/wp-content\/uploads\/2020\/10\/4107bfa33261ea62d17f27f61b1b4c23.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Danksagungen und weiterf\u00fchrende Literatur<\/h3>\n<p>\nIch erinnere mich nicht, wer viele dieser Dinge zuerst beschrieben hat, aber hier sind zwei Posts \u00fcber die am wenigsten dokumentierten Techniken, die Ihnen gefallen k\u00f6nnten:<\/p>\n<ul>\n<li>Paul Randals Post \u00fcber <noindex><a rel=\"nofollow\" href=\"http:\/\/www.sqlskills.com\/blogs\/paul\/sql-server-2008-new-undocumented-physical-row-locator-function\/\">%%physloc%% und sys.fn_PhysLocFormatter<\/a><\/noindex> (wie wir unsere Daten im ersten Beispiel)<\/li>\n<li>Die Frage auf StackOverflow \u00fcber <noindex><a rel=\"nofollow\" href=\"https:\/\/dba.stackexchange.com\/questions\/106762\/how-can-i-convert-a-key-in-a-sql-server-deadlock-report-to-the-value\">die Verwendung von %%lockres%%<\/a><\/noindex> (wie wir die Daten im zweiten Beispiel gefunden haben). Eine der Antworten f\u00fchrt zu dem Post <noindex><a rel=\"nofollow\" href=\"http:\/\/www.scarydba.com\/2010\/03\/18\/undocumented-virtual-column-lockres\/\">von Grant Fritchey \u00fcber %%lockres%%, der bereits 2010 geschrieben wurde.<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/524098\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0415\u0441\u043b\u0438 \u0432\u044b \u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0435\u0441\u044c \u043e\u0442\u0447\u0451\u0442\u043e\u043c \u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430\u0445 (blocked process report) \u0438\u043b\u0438 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u0433\u0440\u0430\u0444\u044b \u0434\u0435\u0434\u043b\u043e\u043a\u043e\u0432, \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u043c\u044b\u0435 SQL Server&#8217;\u043e\u043c, \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438, \u0432\u044b \u0431\u0443\u0434\u0435\u0442\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0432\u043e\u0442 \u0442\u0430\u043a\u0438\u043c\u0438 \u0448\u0442\u0443\u043a\u0430\u043c\u0438: waitresource=\u201cPAGE: 6:3:70133\u201c waitresource=\u201cKEY: 6:72057594041991168 (ce52f92a058c)\u201c \u0418\u043d\u043e\u0433\u0434\u0430, \u0432 \u0442\u043e\u043c \u0433\u0438\u0433\u0430\u043d\u0442\u0441\u043a\u043e\u043c XML, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0432\u044b \u0438\u0437\u0443\u0447\u0430\u0435\u0442\u0435, \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 (\u0433\u0440\u0430\u0444\u044b \u0434\u0435\u0434\u043b\u043e\u043a\u043e\u0432 \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u0442 \u0441\u043f\u0438\u0441\u043e\u043a \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0443\u0437\u043d\u0430\u0442\u044c \u0438\u043c\u0435\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u0430 \u0438 \u0438\u043d\u0434\u0435\u043a\u0441\u0430), \u043d\u043e \u043d\u0435 \u0432\u0441\u0435\u0433\u0434\u0430. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97703,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97702","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0415\u0441\u043b\u0438 \u0432\u044b \u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0435\u0441\u044c \u043e\u0442\u0447\u0451\u0442\u043e\u043c \u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430\u0445 (blocked process report) \u0438\u043b\u0438 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u0433\u0440\u0430\u0444\u044b \u0434\u0435\u0434\u043b\u043e\u043a\u043e\u0432, \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u043c\u044b\u0435 SQL Server&#039;\u043e\u043c, \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438, \u0432\u044b \u0431\u0443\u0434\u0435\u0442\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0432\u043e\u0442 \u0442\u0430\u043a\u0438\u043c\u0438 \u0448\u0442\u0443\u043a\u0430\u043c\u0438: .\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u044b\u0432\u0430\u0435\u043c Key \u0438 Page WaitResource \u0432 \u0434\u0435\u0434\u043b\u043e\u043a\u0430\u0445 \u0438 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0415\u0441\u043b\u0438 \u0432\u044b \u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0435\u0441\u044c \u043e\u0442\u0447\u0451\u0442\u043e\u043c \u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430\u0445 (blocked process report) \u0438\u043b\u0438 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u0433\u0440\u0430\u0444\u044b \u0434\u0435\u0434\u043b\u043e\u043a\u043e\u0432, \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u043c\u044b\u0435 SQL Server&#039;\u043e\u043c, \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438, \u0432\u044b \u0431\u0443\u0434\u0435\u0442\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0432\u043e\u0442 \u0442\u0430\u043a\u0438\u043c\u0438 \u0448\u0442\u0443\u043a\u0430\u043c\u0438: .\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-10-20T18:42:28+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-10-20T18:42:28+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Entschl\u00fcsselung von Key und Page WaitResource in Deadlocks und Sperren | ProHoster","description":"Wenn Sie Berichte \u00fcber Sperren (Blocked Process Report) oder von SQL Server bereitgestellte Deadlock-Grafiken regelm\u00e4\u00dfig verwenden, werden Sie gelegentlich mit solchen Dingen konfrontiert: .","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u044b\u0432\u0430\u0435\u043c Key \u0438 Page WaitResource \u0432 \u0434\u0435\u0434\u043b\u043e\u043a\u0430\u0445 \u0438 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430\u0445 | ProHoster","og:description":"\u0415\u0441\u043b\u0438 \u0432\u044b \u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0435\u0441\u044c \u043e\u0442\u0447\u0451\u0442\u043e\u043c \u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430\u0445 (blocked process report) \u0438\u043b\u0438 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u0433\u0440\u0430\u0444\u044b \u0434\u0435\u0434\u043b\u043e\u043a\u043e\u0432, \u043f\u0440\u0435\u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0435\u043c\u044b\u0435 SQL Server'\u043e\u043c, \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438, \u0432\u044b \u0431\u0443\u0434\u0435\u0442\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0432\u043e\u0442 \u0442\u0430\u043a\u0438\u043c\u0438 \u0448\u0442\u0443\u043a\u0430\u043c\u0438: .","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rasshifrovyvaem-key-i-page-waitresource-v-dedlokah-i-blokirovkah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-20T18:42:28+00:00","article:modified_time":"2020-10-20T18:42:28+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97702","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:15:26","updated":"2022-10-03 07:13:25","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97702","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=97702"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97702\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/97703"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=97702"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=97702"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=97702"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}