ডিফল্টরূপে আপনার জন্য এসকিউএল সার্ভার ট্র্যাক করে এমন বেশ কয়েকটি মূল্যবান তথ্য রয়েছে। এসকিউএল সার্ভার ২০০৩ সাল থেকে একটি "ডিফল্ট ট্রেস" রয়েছে যা ব্যাকগ্রাউন্ডে চলে এবং এসকিউএল সার্ভার ২০০৮ সাল থেকে একটি বর্ধিত ইভেন্টস সেশনটি স্বয়ংক্রিয়ভাবে চলমান, বলা হয়ে থাকে system_health।
আপনি এসকিউএল সার্ভার ত্রুটি লগ, এসকিউএল সার্ভার এজেন্ট লগ, উইন্ডোজ ইভেন্ট লগ এবং এসকিউএল সার্ভার অডিট , পরিচালনা ডেটা গুদাম , ইভেন্ট বিজ্ঞপ্তি , ডিএমএল ট্রিগার , ডিডিএল ট্রিগারস , এসসিএম / সিস্টেম কেন্দ্রের মতো অতিরিক্ত লগিং থেকে নির্দিষ্ট তথ্য সন্ধান করতে পারেন , আপনার নিজস্ব সার্ভার-সাইড ট্রেস বা বর্ধিত ইভেন্টস সেশনগুলি বা তৃতীয় পক্ষের পর্যবেক্ষণ সমাধানগুলি (যেমন আমার নিয়োগকর্তা, এসকিউএল সেন্ট্রি তৈরি করেছেন তার মতো )। সমস্যা সমাধানে সহায়তার জন্য আপনি বিকল্প হিসাবে একটি তথাকথিত "ব্ল্যাকবক্স ট্রেস" সক্ষম করতে পারেন ।
তবে এই পোস্টের জন্য আমি সেই বিষয়গুলিতে সুযোগকে ফোকাস করতে চলেছি যা সাধারণত সর্বত্র সক্ষম হয়: ডিফল্ট ট্রেস, বর্ধিত ইভেন্টস সেশন এবং ত্রুটি লগ।
ডিফল্ট ট্রেস
ডিফল্ট ট্রেস সাধারণত বেশিরভাগ সিস্টেমে চলমান থাকে, যদি না আপনি এটি ব্যবহার করে অক্ষম করেনsp_configure । যতক্ষণ এটি সক্ষম থাকে ততক্ষণ এটি মূল্যবান তথ্যের সমৃদ্ধ উত্স হতে পারে। নীচে ক্যাপচার হওয়া ট্রেস ইভেন্টগুলি তালিকাবদ্ধ করে:
DECLARE @TraceID INT;
SELECT @TraceID = id FROM sys.traces WHERE is_default = 1;
SELECT t.EventID, e.name as Event_Description
FROM sys.fn_trace_geteventinfo(@TraceID) t
JOIN sys.trace_events e ON t.eventID = e.trace_event_id
GROUP BY t.EventID, e.name;
sys.trace_columnsকোন ডেটা নিয়ে কোন ইভেন্টগুলি আসে তা দেখার জন্য আপনি যোগ দিয়ে আরও বিশদ পেতে পারেন , তবে আমি আপাতত এড়াতে যাচ্ছি, যেহেতু আপনি নির্দিষ্ট ইভেন্টগুলির জন্য ট্রেস ডেটাটি অনুসন্ধান করার সময় আপনার কী আছে তা আপনি দেখতে পাচ্ছেন। এটি আমার সিস্টেমে উপলভ্য ইভেন্টগুলি ((এসকিউএল সার্ভার 2019 সিটিপি ২.৪ এর মাধ্যমে এটি এখনও একই ইভেন্টগুলির মধ্যে রয়েছে) আপনার মিল নিয়ে নিশ্চিত হওয়ার জন্য আপনার উপর কোয়েরিটি চালানো উচিত:
EventID Event_Description
------- ----------------------------------------------
18 Audit Server Starts And Stops
20 Audit Login Failed
22 ErrorLog
46 Object:Created
47 Object:Deleted
55 Hash Warning
69 Sort Warnings
79 Missing Column Statistics
80 Missing Join Predicate
81 Server Memory Change
92 Data File Auto Grow
93 Log File Auto Grow
94 Data File Auto Shrink
95 Log File Auto Shrink
102 Audit Database Scope GDR Event
103 Audit Schema Object GDR Event
104 Audit Addlogin Event
105 Audit Login GDR Event
106 Audit Login Change Property Event
108 Audit Add Login to Server Role Event
109 Audit Add DB User Event
110 Audit Add Member to DB Role Event
111 Audit Add Role Event
115 Audit Backup/Restore Event
116 Audit DBCC Event
117 Audit Change Audit Event
152 Audit Change Database Owner
153 Audit Schema Object Take Ownership Event
155 FT:Crawl Started
156 FT:Crawl Stopped
164 Object:Altered
167 Database Mirroring State Change
175 Audit Server Alter Trace Event
218 Plan Guide Unsuccessful
নোট করুন যে ডিফল্ট ট্রেসটি রোলওভার ফাইলগুলি ব্যবহার করে এবং তাই আপনার কাছে উপলভ্য ডেটা কেবল এতদূর ফিরে যাবে - উপরের ইভেন্টগুলির কতগুলি ক্যাপচার করা হচ্ছে এবং কোন ফ্রিকোয়েন্সিতে উপলব্ধ ডেটার তারিখের সীমা নির্ভর করে। আপনি যদি দীর্ঘ ইতিহাস বজায় রাখার বিষয়টি নিশ্চিত করতে চান তবে আপনি একটি কাজ সেট আপ করতে পারেন যা পর্যায়ক্রমে ট্রেসের সাথে যুক্ত বর্তমানে নিষ্ক্রিয় ফাইলগুলি সংরক্ষণ করে।
উদাহরণ
প্রশ্নে আমি বেশ কয়েকটি প্রশ্ন জিজ্ঞাসা করেছি যা আমি খুঁজে পেয়েছি। ডিফল্ট ট্রেস থেকে সেই নির্দিষ্ট তথ্যটি টানানোর জন্য উদাহরণগুলি এখানে রয়েছে eries
প্রশ্ন: অ্যাডভেঞ্চার ওয়ার্কস ডাটাবেসে সর্বশেষ যখন স্বয়ংক্রিয় বৃদ্ধি ঘটেছিল এবং এটি কতক্ষণ নেয়?
এই ক্যোয়ারী অ্যাডভেঞ্চার ওয়ার্কস ডাটাবেসের সমস্ত অটগ্রো ইভেন্টগুলিকে টেনে আনবে, লগ এবং ডেটা ফাইল উভয়ের জন্য, যা এখনও ডিফল্ট ট্রেস লগ ফাইলগুলিতে রয়েছে:
DECLARE @path NVARCHAR(260);
SELECT
@path = REVERSE(SUBSTRING(REVERSE([path]),
CHARINDEX(CHAR(92), REVERSE([path])), 260)) + N'log.trc'
FROM sys.traces
WHERE is_default = 1;
SELECT
DatabaseName,
[FileName],
SPID,
Duration,
StartTime,
EndTime,
FileType = CASE EventClass WHEN 92 THEN 'Data' ELSE 'Log' END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE EventClass IN (92,93)
AND DatabaseName = N'AdventureWorks'
ORDER BY StartTime DESC;
প্রশ্ন: ডিবিও.অম্পলয়েড অডিটডাটা টেবিলটি কে মুছেছে এবং কখন?
এটি DROPনামের কোনও জিনিসের জন্য কোনও ইভেন্ট ফেরত দেবে EmployeeAuditData। আপনি যদি তা নিশ্চিত করতে চান যে এটি কেবল DROPটেবিলগুলির জন্য ইভেন্টগুলি সনাক্ত করে তবে আপনি একটি ফিল্টার যুক্ত করতে পারেন: ObjectType = 8277( পুরো তালিকাটি এখানে নথিভুক্ত করা হয়েছে )। আপনি যদি একটি নির্দিষ্ট ডাটাবেসের সাথে সার্চ স্পেস সীমিত করতে চান, আপনি একটি ফিল্টার যোগ করতে পারেন: DatabaseName = N'db_name'।
DECLARE @path NVARCHAR(260);
SELECT
@path = REVERSE(SUBSTRING(REVERSE([path]),
CHARINDEX(CHAR(92), REVERSE([path])), 260)) + N'log.trc'
FROM sys.traces
WHERE is_default = 1;
SELECT
LoginName,
HostName,
StartTime,
ObjectName,
TextData
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE EventClass = 47 -- Object:Deleted
AND EventSubClass = 1
AND ObjectName = N'EmployeeAuditData'
ORDER BY StartTime DESC;
এখানে একটি জটিলতা রয়েছে, এবং এটি খুব প্রান্তের ক্ষেত্রে তবে যাইহোক এটি উল্লেখ করা বুদ্ধিমানের বলে মনে হয়েছে। আপনি যদি একাধিক স্কিমা ব্যবহার করেন এবং একাধিক স্কিমাতে একই অবজেক্টের নাম থাকতে পারে তবে আপনি এটি কোনটি তা বলতে পারবেন না (যদি না এটির অংশীদারি উপস্থিত থাকে না)। বাইরের কেস রয়েছে যে ইউজারএ স্কিমাবিটি টেবিলনামটি বাদ দিয়েছে এবং ইউজারবি হয়ত স্কিমাএ.সামগ্রহটি ফেলে দিয়েছে। ডিফল্ট ট্রেস অবজেক্টের স্কিমা ট্র্যাক করে না (এটি TextDataএই ইভেন্টের জন্য ক্যাপচার করে না ), এবংObjectIDট্রেসটিতে অন্তর্ভুক্ত থাকা সরাসরি ম্যাচের জন্য কার্যকর নয় (কারণ বস্তুটি ফেলে দেওয়া হয়েছিল এবং এর অস্তিত্ব নেই)। এই ক্ষেত্রে আউটপুটে column কলামটি অন্তর্ভুক্ত করা সারণীটির যে কোনও অনুলিপি এখনও বিদ্যমান আছে তার বিপরীতে রেফারেন্স হিসাবে দরকারী হতে পারে, তবে যদি সিস্টেমটি এত বিপর্যস্ত হয় তবে (বা যদি এই জাতীয় সমস্ত অনুলিপি মুছে ফেলা হয়) এখনও টেবিলের অনুলিপি কার দ্বারা নামানো হয়েছে তা অনুমান করার নির্ভরযোগ্য উপায় হতে পারে না।
বর্ধিত ইভেন্টগুলি
এসকিউএল সার্ভার 2008 সমর্থনকারী থেকে : সিস্টেম_সামগ্রী অধিবেশন (এসকিউএলএসএস ব্লগ) , নিম্নলিখিত system_healthএসকিউএল সার্ভার ২০০৮ এবং ২০০৮ আর 2 এর অধিবেশনটি থেকে আপনি যে তথ্যগুলি সরাতে পারবেন তার তালিকা নীচে দেওয়া হয়েছে :
- তীব্রতা = = 20 এর সাথে ত্রুটির সম্মুখীন হওয়া যে কোনও সেশনের জন্য sql_text এবং সেশন_আইডি
- "মেমরি" ধরণের ত্রুটি যেমন 17803, 701 ইত্যাদির মুখোমুখি হয় এমন কোনও সেশনের জন্য sql_text এবং সেশন_আইডি (আমরা এটিকে যুক্ত করেছি কারণ সমস্ত মেমরির ত্রুটি তাত্পর্য নয়> = 20)
- কোনও "ফলনহীন" সমস্যার রেকর্ড (আপনি কখনও কখনও এটি 17883 এমএসজি হিসাবে ERRORLOG এ দেখেছেন)
- যে কোনও ডেডলক সনাক্ত করা হয়
- কলসট্যাক, sql_text এবং সেশন_ইড যে কোনও সেশনের জন্য যারা 15 সেকেন্ডের জন্য ল্যাচগুলিতে (বা অন্যান্য আকর্ষণীয় উত্স) অপেক্ষা করেছিলেন
- যে কোনও সেশনের জন্য> 30 সেকেন্ডের জন্য লকগুলিতে অপেক্ষা করা আছে তাদের জন্য কলস্ট্যাক, sql_text এবং সেশন_আইডি
- "বাহ্যিক" অপেক্ষা বা "প্রাক-প্রতীক্ষামূলক অপেক্ষা" এর জন্য বর্ধিত সময়ের জন্য অপেক্ষা করা কোনও সেশনের জন্য কলস্ট্যাক, sql_text এবং সেশন_আইডি।
সিস্টেম_সামগ্রী ইভেন্ট সেশন (এমএসডিএন) ব্যবহার থেকে , তালিকাটি এসকিউএল সার্ভার ২০১২-তে কিছুটা প্রসারিত হয়েছে (এবং এসকিউএল সার্ভার ২০১৪-তে একই থাকে):
- তীব্রতার সাথে ত্রুটির সম্মুখীন হওয়া যে কোনও সেশনের জন্য sql_text এবং सत्र_id> = 20।
- স্মৃতি-সম্পর্কিত ত্রুটির সম্মুখীন হওয়া যে কোনও সেশনের জন্য sql_text এবং সেশন_আইডি। ত্রুটিগুলির মধ্যে 17803, 701, 802, 8645, 8651, 8657 এবং 8902 অন্তর্ভুক্ত।
- কোনও ফলনহীন সময়সূচী সমস্যার রেকর্ড। (এগুলি এসকিউএল সার্ভার ত্রুটি হিসাবে লগতে 17883 টি হিসাবে উপস্থিত হয়))
- যে কোনও ডেডলক সনাক্ত করা হয়।
- কলসট্যাক, sql_text, এবং সেশন_আইডি যে কোনও সেশনের জন্য যা 15 সেকেন্ডের জন্য ল্যাচগুলিতে (বা অন্যান্য আকর্ষণীয় সংস্থানগুলি) অপেক্ষা করেছিল।
- কলসট্যাক, sql_text এবং সেশন_আইড যে কোনও সেশনের জন্য> 30 সেকেন্ডের জন্য লকগুলিতে অপেক্ষা করেছে।
- কলস্ট্যাক, sql_text এবং সেশন_ইড যে কোনও সেশনের জন্য প্রিম্পিটিভ অপেক্ষা করতে দীর্ঘ সময় অপেক্ষা করেছে। সময়কাল অপেক্ষা ধরণের দ্বারা পরিবর্তিত হয়। এসিকিউএল সার্ভার বাহ্যিক এপিআই কলগুলির জন্য অপেক্ষা করছে সেখানে একটি প্রাকদর্শন অপেক্ষা wait
- সিএলআর বরাদ্দ এবং ভার্চুয়াল বরাদ্দের ব্যর্থতার জন্য কলস্ট্যাক এবং সেশন_আইডি।
- মেমরি ব্রোকার, শিডিয়ুলার মনিটর, মেমরি নোড ওওএম, সুরক্ষা এবং সংযোগের জন্য রিং_বাফার ইভেন্টগুলি।
- Sp_server_diagnostics থেকে সিস্টেমের উপাদান ফলাফল।
- তাত্ক্ষণিক স্বাস্থ্য সময়সূচী_মনিটর_সিস্টেম_হেলথ_রিং_বাফার_রেখার্ড দ্বারা সংগৃহীত।
- সিএলআর বরাদ্দ ব্যর্থতা।
- কানেক্টিভিটি_রিং_বফার_রেখার্ড ব্যবহার করে সংযোগের ত্রুটি।
- সুরক্ষা_অরার_আর_বফার_রেখার্ড ব্যবহার করে সুরক্ষা ত্রুটি।
এসকিউএল সার্ভার 2016 এ, আরও দুটি ইভেন্ট ধরা পড়ে:
KILLকমান্ডটি ব্যবহার করে কোনও প্রক্রিয়া মারা গেলে ।- যখন এসকিউএল সার্ভার শাটডাউন শুরু করা হয়েছে।
(ডকুমেন্টেশনটি এখনও আপডেট হয়নি তবে আমি কীভাবে এই এবং অন্যান্য পরিবর্তনগুলি আবিষ্কার করি সে সম্পর্কে আমি ব্লগ করেছি ))
আপনার নির্দিষ্ট সংস্করণটির জন্য আরও ক্রিপ্টিক কনফিগারেশন প্রযোজ্য হওয়ার জন্য, আপনি সর্বদা নিম্নলিখিত কোয়েরিটি সরাসরি চালাতে পারেন, তবে আপনাকে নামগুলি ব্যাখ্যা করতে হবে এবং উপরের আরও প্রাকৃতিক ভাষার তালিকার সাথে মিলিয়ে নিতে ভবিষ্যদ্বাণীগুলি পার্স করতে হবে:
SELECT e.package, e.event_id, e.name, e.predicate
FROM sys.server_event_session_events AS e
INNER JOIN sys.server_event_sessions AS s
ON e.event_session_id = s.event_session_id
WHERE s.name = N'system_health'
ORDER BY e.package, e.name;
আপনি যদি উপলভ্যতা গোষ্ঠীগুলি ব্যবহার করে থাকেন তবে দুটি নতুন সেশনও আপনার চলমান দেখতে পাবেন: AlwaysOn_failoverএবং AlwaysOn_health। নীচের প্রশ্নের সাথে তারা যে ডেটা সংগ্রহ করে তা আপনি দেখতে পারেন:
SELECT s.name, e.package, e.event_id, e.name, e.predicate
FROM sys.server_event_session_events AS e
INNER JOIN sys.server_event_sessions AS s
ON e.event_session_id = s.event_session_id
WHERE s.name LIKE N'AlwaysOn[_]%'
ORDER BY s.name, e.package, e.name;
এই ইভেন্ট সেশনগুলি ডেটা সঞ্চয় করতে রিং বাফার লক্ষ্যগুলি ব্যবহার করে, সুতরাং - বাফার পুল এবং প্ল্যান ক্যাশের মতো - পুরানো ইভেন্টগুলি পর্যায়ক্রমে বেরিয়ে আসবে, সুতরাং আপনি প্রয়োজনীয় তারিখের সীমা থেকে ইভেন্টগুলি টানতে পারবেন না।
উদাহরণ
প্রশ্নে আমি এই কল্পিত প্রশ্নটি উত্থাপন করেছি:
আজ কত স্মৃতি সংক্রান্ত ত্রুটি ঘটেছে?
এখানে একটি নমুনা (এবং সম্ভবত খুব দক্ষ নয়) কোয়েরি রয়েছে যা system_healthসেশন থেকে এই তথ্যটি টানতে পারে :
;WITH src(x) AS
(
SELECT y.query('.')
FROM
(
SELECT x = CONVERT(XML, t.target_data)
FROM sys.dm_xe_sessions AS s
INNER JOIN sys.dm_xe_session_targets AS t
ON s.[address] = t.event_session_address
WHERE s.name = N'system_health'
) AS x
CROSS APPLY x.x.nodes('/RingBufferTarget/event') AS y(y)
)
SELECT
x, ts = CONVERT(DATETIME, NULL), err = CONVERT(INT, NULL)
INTO #blat FROM src;
DELETE #blat WHERE x.value('(/event/@name)[1]', 'varchar(255)') <> 'error_reported';
UPDATE #blat SET ts = x.value('(/event/@timestamp)[1]', 'datetime');
UPDATE #blat SET err = x.value('(/event/data/value)[1]', 'int');
SELECT err, number_of_events = COUNT(*)
FROM #blat
WHERE err IN (17803, 701, 802, 8645, 8651, 8657, 8902)
AND ts >= CONVERT(DATE, CURRENT_TIMESTAMP)
GROUP BY err;
DROP TABLE #blat;
(এই উদাহরণটি অধিবেশনটিতে অমিত ব্যানার্জির প্রবর্তক ব্লগ পোস্টsystem_health থেকে স্বচ্ছলভাবে ধার নিয়েছে ))
প্রসারিত ইভেন্টগুলি সম্পর্কে আরও তথ্যের জন্য (অনেকগুলি উদাহরণ সহ যেখানে আপনি নির্দিষ্ট ডেটার জন্য জিজ্ঞাসা করতে পারেন), জোনাথন কেহায়িয়াসের এই 31-অংশের ব্লগ সিরিজটি দেখুন:
https://www.sqlskills.com/blogs/jonathan/an-xevent-a-day-31-days-of-extended-events/
ত্রুটি লগ
এসকিউএল সার্ভার ডিফল্টরূপে বর্তমান প্লাস 6 খুব সাম্প্রতিক ত্রুটি লগ ফাইল রাখে (তবে আপনি এটি পরিবর্তন করতে পারেন )। প্রারম্ভকালের তথ্য (মেমরিতে লক পৃষ্ঠাগুলি সেট করা আছে কিনা, প্রমাণীকরণ মোড, ইত্যাদি) পাশাপাশি ত্রুটি এবং অন্যান্য দৃশ্যাবলী যা ডকুমেন্ট করার জন্য যথেষ্ট (এবং অন্যত্র ক্যাপচার করা হয়নি) সহ প্রচুর তথ্য সেখানে সংরক্ষণ করা হয়। সাম্প্রতিকতম উদাহরণটি হ'ল কেউ যখন ডেটাবেস অফলাইনে নেওয়া হয়েছিল তখন তার সন্ধান করছিল। আপনি পাঠ্যের জন্য অতি সাম্প্রতিক 7 টি ত্রুটি লগের মাধ্যমে স্ক্যান করে এটি নির্ধারণ করতে পারেন Setting database option OFFLINE:
EXEC sys.sp_readerrorlog 0,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 1,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 2,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 3,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 4,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 5,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 6,1,'Setting database option OFFLINE';
আমি এই সাম্প্রতিক উত্তরে কিছু অন্যান্য বিবরণ কভার করেছি এবং টডওয়ার্ল্ডে এবং অফিসিয়াল ডকুমেন্টেশনে কিছু ভাল পটভূমির তথ্যও রয়েছে ।
"ত্রুটি" এর একটি গ্রুপ ত্রুটি লগটি ডিফল্টরূপে ট্র্যাক করে - এবং গুরুত্বপূর্ণ তথ্যটি খুব দ্রুত লেজ থেকে পড়ে যায় - এটি প্রতিটি সফল ব্যাকআপ বার্তা। আপনি এগুলিকে ট্রেস পতাকাটি 3226 সক্ষম করে শোরগোলের সাথে ত্রুটিযুক্ত লগ পূরণ থেকে বিরত রাখতে পারেন ।