ডেটাবেস অ্যাডমিনিস্ট্রেটর (DBAs) এবং ডেভঅপস (DevOps) ইঞ্জিনিয়ার যারা মাইক্রোসফট এসকিউএল সার্ভার (Microsoft SQL Server) পরিচালনা করেন, তাদের জন্য খুব কম অ্যালার্টই ‘এরর ৯০০২’ (Error 9002)-এর মতো তাৎক্ষণিক উদ্বেগের সৃষ্টি করে: ‘X’ ডেটাবেসের ট্রানজ্যাকশন লগ পূর্ণ হয়ে গেছে। যখন ট্রানজ্যাকশন লগ পূর্ণ হয়ে যায় এবং আর বড় হতে পারে না, তখন ডেটাবেসটি কার্যকরভাবে রিড-অনলি (read-only) মোডে চলে যায়। সমস্ত INSERT, UPDATE, এবং DELETE অপারেশন বন্ধ হয়ে যায়, অ্যাপ্লিকেশন ট্রানজ্যাকশন ব্যর্থ হয় এবং প্রোডাকশন কার্যক্রম স্থবির হয়ে পড়ে।
এসকিউএল সার্ভার ট্রানজ্যাকশন লগের অন্তর্নিহিত আর্কিটেকচার বোঝা, মূল কারণ সঠিকভাবে নির্ণয় করা এবং দ্রুত পুনরুদ্ধারের পদ্ধতি প্রয়োগ করা উচ্চ প্রাপ্যতা (high availability) বজায় রাখার জন্য অত্যন্ত গুরুত্বপূর্ণ দক্ষতা। এই বিস্তারিত নির্দেশিকাটি ট্রানজ্যাকশন লগের কার্যপদ্ধতি, জরুরি অবস্থায় পূর্ণ লগ কীভাবে সমাধান করতে হয় এবং এটি পুনরায় ঘটা রোধ করার জন্য আর্কিটেকচারাল সর্বোত্তম অনুশীলনগুলো নিয়ে আলোচনা করবে।
এসকিউএল সার্ভার ট্রানজ্যাকশন লগ আর্কিটেকচার বোঝা
একটি পূর্ণ ট্রানজ্যাকশন লগ কার্যকরভাবে ট্রাবলশুট করার জন্য, আপনাকে প্রথমে বুঝতে হবে এসকিউএল সার্ভার কীভাবে ডেটা লেখে এবং পরিচালনা করে।
রাইট-অহেড লগিং (Write-Ahead Logging – WAL)
এসকিউএল সার্ভার একটি রাইট-অহেড লগিং (WAL) প্রোটোকল ব্যবহার করে। যখনই কোনো ডেটা পরিবর্তন হয়, পরিবর্তনটি প্রথমে মেমরিতে ট্রানজ্যাকশন লগে লেখা হয়, তারপর ডেটাবেস ফাইলে (MDF/NDF) প্রকৃত ডেটা পেজ আপডেট হওয়ার আগে ডিস্কে থাকা ফিজিক্যাল লগ ফাইলে ফ্লাশ করা হয়। এটি ACID (Atomicity, Consistency, Isolation, Durability) কমপ্লায়েন্স নিশ্চিত করে, যা নিশ্চিত করে যে কোনো ক্র্যাশের ক্ষেত্রে এসকিউএল সার্ভার ট্রানজ্যাকশনগুলো পুনরায় চালাতে (roll forward) বা পূর্বাবস্থায় ফিরিয়ে নিতে (roll back) পারে।
ভার্চুয়াল লগ ফাইল (VLFs) এবং সার্কুলার লগিং
অভ্যন্তরীণভাবে, ফিজিক্যাল ট্রানজ্যাকশন লগ ফাইল (LDF) ছোট, লজিক্যাল সেগমেন্টে বিভক্ত থাকে যাকে ভার্চুয়াল লগ ফাইল (VLFs) বলা হয়। ট্রানজ্যাকশন লগ চক্রাকারে কাজ করে। লগ রেকর্ডগুলো লেখার সাথে সাথে, সেগুলো একটি VLF পূর্ণ করে এবং পরেরটিতে চলে যায়।
যখন লগটি ফিজিক্যাল ফাইলের শেষে পৌঁছায়, তখন এটি শুরুতে ফিরে আসার চেষ্টা করে। তবে, এটি কেবল তখনই একটি VLF ওভাররাইট করতে পারে যদি সেই VLF-টিকে নিষ্ক্রিয় (inactive) হিসেবে চিহ্নিত করা থাকে। যদি সমস্ত VLF সক্রিয় থাকে (অর্থাৎ সেগুলোতে এমন লগ রেকর্ড থাকে যা এসকিউএল সার্ভারের এখনও প্রয়োজন), তবে লগটি আর ঘুরতে পারে না। যদি অটো-গ্রোথ (auto-growth) সক্রিয় থাকে এবং ডিস্কে জায়গা থাকে, তবে ফিজিক্যাল ফাইলটি বড় হয়। যদি ডিস্ক পূর্ণ থাকে বা অটো-গ্রোথ সীমাবদ্ধ থাকে, তবে আপনি এরর ৯০০২-এর সম্মুখীন হবেন।
লগ ট্রাঙ্কেশন বনাম লগ শ্রিঙ্কিং
একটি সাধারণ ভুল ধারণা হলো যে লগ ট্রাঙ্কেট করলে ফিজিক্যাল ফাইলের আকার কমে যায়।
* লগ ট্রাঙ্কেশন (Log Truncation): সক্রিয় VLF-গুলোকে নিষ্ক্রিয় হিসেবে চিহ্নিত করার প্রক্রিয়া, যা জায়গাটিকে পুনরায় ব্যবহারের জন্য উপলব্ধ করে। এটি ডিস্কে থাকা LDF ফাইলের আকার কমায় না।
* লগ শ্রিঙ্কিং (Log Shrinking): LDF ফাইলের আকার শারীরিকভাবে কমানোর এবং অপারেটিং সিস্টেমকে জায়গা ফেরত দেওয়ার প্রক্রিয়া।
ফুল রিকভারি মডেলে, লগ ট্রাঙ্কেশন কেবলমাত্র তখনই ঘটে যখন একটি ট্রানজ্যাকশন লগ ব্যাকআপ সফলভাবে সম্পন্ন হয় (যদি অন্য কোনো প্রসেস লগটিকে সক্রিয় না রাখে)।
‘ট্রানজ্যাকশন লগ ফুল’ এরর (এরর ৯০০২) নির্ণয় করা
যখন লগ পূর্ণ হয়ে যায়, আপনার প্রথম কাজ হলো অন্ধভাবে ডিস্কের জায়গা বাড়ানো বা ফাইল শ্রিঙ্ক করা নয়। আপনাকে অবশ্যই শনাক্ত করতে হবে কেন লগটি ট্রাঙ্কেট হতে পারছে না। এসকিউএল সার্ভার sys.databases ক্যাটালগ ভিউয়ের মাধ্যমে লগ পুনরায় ব্যবহারের পথে কী বাধা দিচ্ছে তা জানানোর জন্য একটি বিল্ট-ইন মেকানিজম প্রদান করে।
বটলনেক শনাক্ত করতে নিচের T-SQL কমান্ডটি চালান:
SELECT
name AS DatabaseName,
recovery_model_desc AS RecoveryModel,
log_reuse_wait_desc AS LogReuseWaitReason
FROM sys.databases
WHERE name = 'YourDatabaseName';
আপনি নিচের কমান্ডটি ব্যবহার করে আপনার ট্রানজ্যাকশন লগের বর্তমান জায়গা ব্যবহারের পরিমাণও পরীক্ষা করতে পারেন:
DBCC SQLPERF(LOGSPACE);
সাধারণ log_reuse_wait_desc অবস্থা
- LOG_BACKUP: ডেটাবেসটি ফুল বা বাল্ক-লগড রিকভারি মডেলে আছে এবং সম্প্রতি কোনো ট্রানজ্যাকশন লগ ব্যাকআপ নেওয়া হয়নি। এটি সবচেয়ে সাধারণ কারণ।
- ACTIVE_TRANSACTION: একটি দীর্ঘস্থায়ী ট্রানজ্যাকশন (যেমন, বিশাল ইনডেক্স রিবিল্ড বা ভুলে যাওয়া আনকমিটেড ট্রানজ্যাকশন) লগটিকে সক্রিয় রাখছে।
- REPLICATION / CDC: ট্রানজ্যাকশনাল রেপ্লিকেশন বা চেঞ্জ ডেটা ক্যাপচার (CDC) সক্রিয় আছে এবং লগ রিডার এজেন্ট এখনও ট্রানজ্যাকশনগুলো প্রসেস করেনি।
- AVAILABILITY_REPLICA: অলওয়েজ-অন অ্যাভেইল্যাবিলিটি গ্রুপে, একটি সেকেন্ডারি রেপ্লিকা বিচ্ছিন্ন বা খুব ধীরে সিঙ্ক্রোনাইজ হচ্ছে, যা প্রাইমারি রেপ্লিকাকে লগ রেকর্ডগুলো ধরে রাখতে বাধ্য করছে যতক্ষণ না সেগুলো সেকেন্ডারিতে হার্ডেন হয়।
দ্রুত পুনরুদ্ধার কৌশল: প্রোডাকশনে সমস্যার সমাধান
log_reuse_wait_desc-এর ওপর ভিত্তি করে আপনার জরুরি পদক্ষেপ ভিন্ন হবে। এখানে সবচেয়ে সাধারণ পরিস্থিতির জন্য দ্রুত পুনরুদ্ধারের কৌশলগুলো দেওয়া হলো।
পরিস্থিতি ১: অনুপস্থিত বা ব্যর্থ লগ ব্যাকআপ (LOG_BACKUP)
যদি ওয়েট টাইপ LOG_BACKUP হয়, তবে সমাধানটি সহজ: আপনাকে অবশ্যই ট্রানজ্যাকশন লগ ব্যাকআপ নিতে হবে।
BACKUP LOG [YourDatabaseName]
TO DISK = 'N:BackupsYourDatabaseName_EmergencyLog.trn'
WITH COMPRESSION, STATS = 10;
ব্যাকআপ সম্পন্ন হলে, নিষ্ক্রিয় VLF-গুলো ট্রাঙ্কেট হবে এবং এসকিউএল সার্ভার স্বাভাবিক কার্যক্রম পুনরায় শুরু করবে। যদি আপনার ব্যাকআপ ড্রাইভ পূর্ণ থাকে, তবে আপনাকে হয়তো কোনো অস্থায়ী নেটওয়ার্ক শেয়ার বা নাল ডিভাইসে ব্যাকআপ নিতে হতে পারে (ডেটাবেসটি সহজে পুনরায় তৈরি করা না গেলে এটি অত্যন্ত নিরুৎসাহিত করা হয়, কারণ এটি লগ চেইন ভেঙে দেয়):
-- সতর্কতা: এটি লগ চেইন ভেঙে দেয় এবং পয়েন্ট-ইন-টাইম রিকভারিকে ক্ষতিগ্রস্ত করে।
-- শুধুমাত্র যদি একান্ত প্রয়োজন হয় তবেই ব্যবহার করুন এবং অবিলম্বে একটি ফুল ব্যাকআপ নিন।
BACKUP LOG [YourDatabaseName] TO DISK = 'NUL';
পরিস্থিতি ২: দীর্ঘস্থায়ী সক্রিয় ট্রানজ্যাকশন (ACTIVE_TRANSACTION)
যদি একটি একক ট্রানজ্যাকশন কয়েক ঘণ্টা ধরে চলতে থাকে, তবে এটি পুরো সময়ের জন্য লগ ট্রাঙ্কেশন প্রতিরোধ করে। প্রথমে, সমস্যা সৃষ্টিকারী ট্রানজ্যাকশনটি শনাক্ত করুন:
DBCC OPENTRAN('YourDatabaseName');
এই কমান্ডটি প্রাচীনতম সক্রিয় ট্রানজ্যাকশন এবং এর সার্ভার প্রসেস আইডি (SPID) প্রদান করে। আপনি ডাইনামিক ম্যানেজমেন্ট ভিউ (DMVs) কোয়েরি করে SPID কী করছে সে সম্পর্কে আরও বিস্তারিত জানতে পারেন:
SELECT
s.session_id,
s.login_name,
s.host_name,
r.start_time,
r.status,
r.command,
t.text AS QueryText
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE s.session_id = <SPID_FROM_DBCC_OPENTRAN>;
যদি ট্রানজ্যাকশনটি কোনো ভুল কোয়েরি বা আটকে থাকা প্রসেস হয়, তবে লগ মুক্ত করতে আপনাকে এটি বন্ধ (terminate) করতে হতে পারে।
KILL <SPID>;
দ্রষ্টব্য: একটি বিশাল ট্রানজ্যাকশন কিল করলে রোলব্যাক শুরু হবে, যা অনেক সময় নিতে পারে এবং সাময়িকভাবে অতিরিক্ত লগ অ্যাক্টিভিটি তৈরি করবে। রোলব্যাকের সময় এসকিউএল সার্ভার সার্ভিস রিস্টার্ট করবেন না, অন্যথায় রিস্টার্টের পর ডেটাবেস রিকভারি মোডে চলে যাবে।
পরিস্থিতি ৩: জরুরি জায়গা বরাদ্দ (ডিস্ক ১০০% পূর্ণ)
যদি LDF ফাইলটি পুরো ড্রাইভ দখল করে নেয়, তবে আপনি ব্যাকআপও চালাতে পারবেন না কারণ ব্যাকআপ ইভেন্টটি রেকর্ড করার জন্য এসকিউএল সার্ভারের সামান্য লগ জায়গার প্রয়োজন হয়। এই পরিস্থিতিতে, আপনাকে অবশ্যই অন্য একটি ড্রাইভে একটি সেকেন্ডারি লগ ফাইল যোগ করতে হবে যেখানে জায়গা আছে।
ALTER DATABASE [YourDatabaseName]
ADD LOG FILE
(
NAME = N'YourDatabaseName_Log2',
FILENAME = N'E:TempLogsYourDatabaseName_Log2.ldf',
SIZE = 5GB,
MAXSIZE = 50GB,
FILEGROWTH = 1GB
);
এটি অবিলম্বে এসকিউএল সার্ভারকে শ্বাস নেওয়ার সুযোগ দেয়। ডেটাবেস অনলাইন হয়ে গেলে, একটি ট্রানজ্যাকশন লগ ব্যাকআপ নিন, সেকেন্ডারি লগ ফাইলটি খালি করুন এবং এটি সরিয়ে ফেলুন:
-- ১. লগ ট্রাঙ্কেট করতে একটি লগ ব্যাকআপ নিন
BACKUP LOG [YourDatabaseName] TO DISK = '...';
-- ২. অস্থায়ী লগ ফাইলটি খালি করুন
DBCC SHRINKFILE (N'YourDatabaseName_Log2', EMPTYFILE);
-- ৩. অস্থায়ী লগ ফাইলটি সরিয়ে ফেলুন
ALTER DATABASE [YourDatabaseName] REMOVE FILE [YourDatabaseName_Log2];
ট্রানজ্যাকশন লগ প্রতিরোধ এবং ব্যবস্থাপনার জন্য সর্বোত্তম অনুশীলন
প্রতিক্রিয়াশীল ট্রাবলশুটিং চাপপূর্ণ এবং এটি SLA-কে প্রভাবিত করে। এন্টারপ্রাইজ ডেটাবেস স্থিতিশীলতার জন্য সক্রিয় আর্কিটেকচারাল এবং অপারেশনাল সর্বোত্তম অনুশীলন বাস্তবায়ন করা অপরিহার্য।
১. একটি শক্তিশালী, স্বয়ংক্রিয় ব্যাকআপ কৌশল বাস্তবায়ন করুন
যদি একটি ডেটাবেস ফুল রিকভারি মডেলে থাকে, তবে ঘন ঘন ট্রানজ্যাকশন লগ ব্যাকআপ নেওয়া বাধ্যতামূলক। আপনার রিকভারি পয়েন্ট অবজেক্টিভ (RPO) এবং ট্রানজ্যাকশন ভলিউমের ওপর ভিত্তি করে, লগ ব্যাকআপ প্রতি ৫ থেকে ১৫ মিনিট অন্তর হওয়া উচিত।
CloudSave-এর মতো এন্টারপ্রাইজ ব্যাকআপ সমাধানগুলো এই প্রক্রিয়াটিকে উল্লেখযোগ্যভাবে সহজ করে। VDI (ভার্চুয়াল ডিভাইস ইন্টারফেস)-এর মাধ্যমে সরাসরি এসকিউএল সার্ভারের সাথে ইন্টিগ্রেট করে, CloudSave ডিবিএ-দের পলিসি-চালিত, উচ্চ-ফ্রিকোয়েন্সি ট্রানজ্যাকশন লগ ব্যাকআপ কনফিগার করার সুযোগ দেয়। এটি নিশ্চিত করে যে লগগুলো ক্রমাগত ট্রাঙ্কেট হয়, নিরাপদে এনক্রিপ্ট করা থাকে এবং অফ-সাইট বা ইমিউটেবল ক্লাউড স্টোরেজে সংরক্ষিত থাকে, যা জটিল কাস্টম এসকিউএল এজেন্ট জব ছাড়াই LOG_BACKUP ওয়েট স্টেট প্রতিরোধ করে।
২. ট্রানজ্যাকশন লগের সঠিক আকার নির্ধারণ এবং VLF ব্যবস্থাপনা
আপনার ট্রানজ্যাকশন লগের আকার পরিচালনার জন্য অটো-গ্রোথের ওপর নির্ভর করা একটি বিপজ্জনক অ্যান্টি-প্যাটার্ন। অটো-গ্রোথ অপারেশনগুলো ব্যয়বহুল এবং ডিস্ক জিরো-ইনিশিয়ালাইজ হওয়ার সময় ট্রানজ্যাকশন প্রসেসিং থামিয়ে দেয় (যদি না ইনস্ট্যান্ট ফাইল ইনিশিয়ালাইজেশন সক্রিয় থাকে, যা লগ ফাইলের ক্ষেত্রে প্রযোজ্য নয়)।
অধিকন্তু, ঘন ঘন, ছোট অটো-গ্রোথ (যেমন, প্রতিবার ১০% বা ৫০ এমবি বৃদ্ধি) VLF ফ্র্যাগমেন্টেশন ঘটায়। হাজার হাজার ছোট VLF বিশিষ্ট একটি ট্রানজ্যাকশন লগ ডেটাবেস স্টার্টআপের সময়, ব্যাকআপ পারফরম্যান্স এবং রেপ্লিকেশন ল্যাটেন্সিকে মারাত্মকভাবে কমিয়ে দেয়।
- লগের আকার আগে থেকেই নির্ধারণ করুন: আপনার বৃহত্তম রক্ষণাবেক্ষণ অপারেশনগুলো (যেমন ইনডেক্স রিবিল্ড) বিশ্লেষণ করুন এবং LDF ফাইলের আকার আগে থেকেই এমনভাবে নির্ধারণ করুন যাতে সেগুলো বড় না হয়েই সম্পন্ন হতে পারে।
- স্থির অটো-গ্রোথ সেট করুন: অটো-গ্রোথকে শতাংশ থেকে স্থির আকারে (যেমন ১ জিবি বা ৫ জিবি) পরিবর্তন করুন যাতে VLF-গুলো সঠিক আকারে তৈরি হয়।
আপনি নিচের কোয়েরিটি ব্যবহার করে আপনার VLF সংখ্যা পরীক্ষা করতে পারেন (এসকিউএল সার্ভার ২০১৭+ এর জন্য):
SELECT
db_name(database_id) AS DatabaseName,
COUNT(vlf_sequence_number) AS VLF_Count
FROM sys.dm_db_log_info(DB_ID('YourDatabaseName'));
যদি আপনার VLF সংখ্যা ৫০০-এর বেশি হয়, তবে শান্ত সময়ের জন্য অপেক্ষা করুন, লগটিকে ন্যূনতম আকারে শ্রিঙ্ক করুন এবং বড় আকারে ম্যানুয়ালি আপনার প্রয়োজনীয় আকারে ফিরিয়ে আনুন।
৩. ইনডেক্স রক্ষণাবেক্ষণ অপারেশন অপ্টিমাইজ করুন
ইনডেক্স রিবিল্ডগুলো সম্পূর্ণ লগড অপারেশন, এমনকি বাল্ক-লগড রিকভারি মডেলেও (ইনডেক্সের ধরনের ওপর নির্ভর করে)। একটি ৫০০ জিবি ইনডেক্স রিবিল্ড করলে অন্তত ৫০০ জিবি ট্রানজ্যাকশন লগ রেকর্ড তৈরি হবে।
রক্ষণাবেক্ষণের সময় লগ স্ফীতি কমাতে:
* ইনডেক্স রিবিল্ড করার সময় SORT_IN_TEMPDB = ON ব্যবহার করুন। এটি সর্টিং পর্যায়টিকে TempDB-তে সরিয়ে নেয়, যা ব্যবহারকারী ডেটাবেসের ট্রানজ্যাকশন লগের ওপর চাপ কমায়।
* যেখানে সম্ভব ইনডেক্স রিবিল্ড থেকে ইনডেক্স রিঅর্গানাইজ-এ সুইচ করুন, কারণ রিঅর্গানাইজেশনগুলো বেশি লগ-দক্ষ এবং পুরো অপারেশন রোলব্যাক না করেই এগুলো থামানো যায়।
* বড় DELETE বা UPDATE অপারেশনগুলো ব্যাচ করুন। এক ট্রানজ্যাকশনে ১০ মিলিয়ন সারি ডিলিট করার পরিবর্তে, ৫০,০০০-এর ব্যাচে ডিলিট করুন, কমিট করুন এবং ব্যাচগুলোর মাঝে লগ ব্যাকআপকে লগ ট্রাঙ্কেট করার সুযোগ দিন।
৪. উচ্চ প্রাপ্যতা এবং রেপ্লিকেশন টপোলজি মনিটর করুন
অলওয়েজ-অন অ্যাভেইল্যাবিলিটি গ্রুপে, প্রাইমারি রেপ্লিকা তার লগ ট্রাঙ্কেট করতে পারে না যতক্ষণ না লগ রেকর্ডগুলো সমস্ত সিঙ্ক্রোনাস এবং অ্যাসিনক্রোনাস সেকেন্ডারি রেপ্লিকাতে হার্ডেন হয়।
যদি একটি সেকেন্ডারি রেপ্লিকা অফলাইনে চলে যায়, অথবা যদি নেটওয়ার্ক ব্যান্ডউইথ প্রাইমারির ট্রানজ্যাকশন তৈরির হারের সাথে তাল মিলিয়ে চলতে না পারে, তবে প্রাইমারির সেন্ড কিউ (send queue) বড় হবে এবং লগ পূর্ণ হয়ে যাবে (AVAILABILITY_REPLICA ওয়েট টাইপ)।
SQLServer:Replica > Log Send Queue পারফরম্যান্স কাউন্টারের জন্য শক্তিশালী মনিটরিং বাস্তবায়ন করুন। যদি একটি সেকেন্ডারি রেপ্লিকা স্থায়ীভাবে হারিয়ে যায়, তবে আপনাকে অবশ্যই এটিকে অ্যাভেইল্যাবিলিটি গ্রুপ থেকে সরিয়ে ফেলতে হবে অথবা ডেটা মুভমেন্ট স্থগিত করতে হবে যাতে প্রাইমারি লগ ট্রাঙ্কেট হতে পারে।
উপসংহার
একটি পূর্ণ ট্রানজ্যাকশন লগের সম্মুখীন হওয়া ডেটাবেস অ্যাডমিনিস্ট্রেটরদের জন্য একটি অগ্নিপরীক্ষার মতো, তবে এর ফলে দীর্ঘ সময় ডাউনটাইম হওয়ার প্রয়োজন নেই। রাইট-অহেড লগিং এবং VLF-এর কার্যপদ্ধতি বোঝার মাধ্যমে, আপনি sys.databases ব্যবহার করে দ্রুত মূল কারণ নির্ণয় করতে পারেন এবং সঠিক দ্রুত পুনরুদ্ধার কৌশল প্রয়োগ করতে পারেন।
দীর্ঘমেয়াদী স্থিতিশীলতা প্রতিক্রিয়াশীল সমাধান থেকে সরে আসার ওপর নির্ভর করে। আপনার লগ ফাইলের আকার আগে থেকে নির্ধারণ করা, রক্ষণাবেক্ষণ রুটিন অপ্টিমাইজ করা এবং কঠোর, স্বয়ংক্রিয় লগ ব্যাকআপ শিডিউল নিশ্চিত করতে CloudSave-এর মতো এন্টারপ্রাইজ-গ্রেড ব্যাকআপ প্ল্যাটফর্ম ব্যবহার করা আপনার ট্রানজ্যাকশন লগগুলোকে সুস্থ, ট্রাঙ্কেট করা এবং উচ্চ-থ্রুপুট প্রোডাকশন ওয়ার্কলোড সমর্থন করার জন্য প্রস্তুত রাখবে।
