টাইমআউট এর ব্যর্থতার পরে মিররিং সেশনটির কারণ কী হতে পারে?

আমাদের দুটি প্রযোজনা এসকিউএল সার্ভারগুলি এসকিউএল সার্ভার ২০০৫ এসপি 4 চালিয়ে ক্রমহ্রাসমান আপডেটের সাথে 3 Both উভয় সার্ভার একই রকম শারীরিক মেশিনে চালিত। সমস্ত এসকিউএল ডাটাবেস এবং লগগুলির জন্য 10 জিবি আইএসসিএসআই সান সংযুক্ত ড্রাইভ সহ 4 এক্স 12 কোর সিপিইউস এবং 512 জিবি (হ্যাঁ জিবি) সহ ডেল্লার পাওয়ারেজ আর 815। সমস্ত এসপি এবং উইন্ডোজ আপডেট সহ ওএস হ'ল মাইক্রোসফ্ট উইন্ডোজ সার্ভার ২০০৮ আর 2 এন্টারপ্রাইজ সংস্করণ। ওএস ড্রাইভ 3 এক্স 72 জিবি 2.5 "15 কে এসএএস ড্রাইভের একটি র‌্যাড 5 অ্যারে। সান একটি ডেল ইক্যুয়াললজিক 6510, 48 এক্স 10 কে এসএএস 3.5" ড্রাইভ সহ, র‌্যাড 50 এ কনফিগার করা হয়েছে, 2 এসকিউএল সার্ভারের জন্য বিভিন্ন এলএনওতে কাটা, এবং ভাগ করা হয়েছে একটি এক্সচেঞ্জ মেশিন এবং বেশ কয়েকটি ভিএমওয়্যার সার্ভার সহ।

আমাদের কাছে 20 টিরও বেশি ডাটাবেস রয়েছে, যার মধ্যে 11 টি সাক্ষ্য সার্ভার ব্যবহার করে উচ্চ প্রাপ্যতার সাথে মিরর করা হয়েছে। সাক্ষী সার্ভারটি একটি নিম্ন চালিত মেশিন যা একটি এসকিউএল সার্ভার ইনস্ট্যান্স চালায় যা সাক্ষী পরিষেবাদি সরবরাহ ব্যতীত অন্য কোনও কিছুর জন্য ব্যবহৃত হয়। বৃহত্তম মিররযুক্ত ডাটাবেস 450 জিবি এবং প্রায় 100-300 আইওপ্স উত্পন্ন করে। ডেটাবেস মিররিং মনিটর প্রতি সেকেন্ডে 100kb থেকে 10 এমবি প্রতি সেকেন্ড প্রেরণের প্রতিবেদন করে এবং একটি আয়না কমিট ওভারহেড (সাধারণত) 0 মিলিসেকেন্ডে করে। মিরর সার্ভারের অধ্যক্ষের সাথে রাখতে সমস্যা নেই।

আমরা ধারাবাহিকভাবে মিররিং ব্যর্থতা অভিজ্ঞতা করছি। কখনও কখনও একক ডাটাবেস ব্যর্থ হয়, অন্য সময় প্রায় সব ডাটাবেস একসাথে ব্যর্থ হয়। উদাহরণস্বরূপ, গত রাতে, আমাদের মধ্যে 11 টি ডাটাবেস ফেইলওভার ছিল, আমি যখন নিজে নিজে এটি ব্যর্থ না করলাম তখন পর্যন্ত বাকী ডাটাবেস অ্যাক্সেসযোগ্য ছিল।

সমস্যাটি সনাক্ত করার চেষ্টা করার জন্য আমি বেশ কয়েকটি সমস্যা সমাধানের পদক্ষেপ নিয়েছি, তবে এখনও পর্যন্ত সমস্যার সমাধান করতে সক্ষম হইনি:

1) মেশিনটি একটি ব্রডকম বিসিএম5709 সি নেটএক্সট্রিম II 4 বন্দর গিগাবিট নেটওয়ার্ক অ্যাডাপ্টার নিয়ে আসে যা আমরা প্রাথমিকভাবে প্রাথমিক নেটওয়ার্ক সংযোগ হিসাবে ব্যবহার করি। NIC কে ইস্যু হিসাবে মুছে ফেলার জন্য আমরা উভয় মেশিনে একটি ইন্টেল (আর) প্রো / 1000 পিটি ডুয়াল পোর্ট সার্ভার অ্যাডাপ্টার ইনস্টল করেছি।

2) সমস্ত ডেটাবেজে মিররিংয়ের সাথে জড়িত ডাটাবেসের জন্য লগ ব্যাকআপের পাশাপাশি একটি স্বয়ংক্রিয় পূর্ণ ব্যাকআপ থাকে। লগ ফাইলের ব্যবহার পর্যবেক্ষণ করা হয় এবং খুব কমই ব্যবহৃত হয় 15% এর উপরে। মূল ডাটাবেসের লগ ফাইলটি 125 গিগাবাইট, 159 ভার্চুয়াল লগ ফাইল রয়েছে যা 511MB থেকে 1GB পর্যন্ত আকারের হয়। টেম্পডিবি এটির নিজস্ব লুন রয়েছে এবং এটিতে 24 x 2GB ফাইল রয়েছে।

3) এসকিউএল সার্ভার লগইন করে সাক্ষী ব্যতীত অন্য কোনও ত্রুটি দেখায় না: "TCP: //SQL02.DOMAIN.INET: 5022" এর সাথে মিররিং সংযোগটি 30 সেকেন্ড পরে কোনও প্রতিক্রিয়া ছাড়াই ডাটাবেস "ডেটা" এর জন্য সময়সীমা শেষ হয়ে গেছে। পরিষেবা এবং নেটওয়ার্ক সংযোগগুলি পরীক্ষা করুন।

প্রাথমিক এবং মাধ্যমিক সার্ভারগুলিতে এসকিউএল সার্ভার লগ মিরর সম্পর্কিত সম্পর্কিত বার্তা দেখায়:

"TCP: //SQL01.DOMAIN.INET: 5022" এর সাথে মিররিং সংযোগটি 30 সেকেন্ড পরে কোনও প্রতিক্রিয়া ছাড়াই ডাটাবেস "ডেটা" এর জন্য সময়সীমা শেষ হয়ে গেছে। পরিষেবা এবং নেটওয়ার্ক সংযোগগুলি পরীক্ষা করুন।

মিররযুক্ত ডাটাবেস "ডেটা" রোল সিঙ্ক্রোনাইজেশনের কারণে "PRINCIPAL" থেকে "মিরর" এ রোলগুলি পরিবর্তন করছে। (আসল বার্তাটি কীভাবে প্রদর্শিত হয় তা হ'ল তাই সংশ্লেষনের উদ্দেশ্য হিসাবে এখানে ভুল বানান রয়েছে is)

মিররযুক্ত ডাটাবেস "ডেটা" ব্যর্থতার কারণে "PRINCIPAL" থেকে "মিরর" তে ভূমিকা পরিবর্তন করছে।

মিররযুক্ত ডাটাবেস "ডেটা" অংশীদার থেকে ব্যর্থতার কারণে "মিরর" থেকে "PRINCIPAL" এ ভূমিকা পরিবর্তন করছে।

এসকিউএল সার্ভার পরিষেবাদিগুলি চলতে থাকে এবং নেটওয়ার্ক সংযোগগুলি আপ অবিরত বলে মনে হচ্ছে। আমাদের ধারাবাহিকভাবে প্রতিটি সার্ভারের সাথে 500 থেকে 2500 সেশন সংযুক্ত থাকে (প্রাথমিকভাবে রোবোটিক অ্যাপ্লিকেশনগুলি যা একক ডাটাবেসে পরিষেবা ব্রোকার সারিগুলিতে সংযুক্ত থাকে)।

৪) টিসিপি চিমনি এবং আরএসএস ইত্যাদি নেট এসএইচ সিনট্যাক্স ব্যবহার করে অক্ষম করা হয়েছে।

5) আমি উভয় মেশিনের বিপরীতে এসকিউএল সার্ভার 2005 সেরা অনুশীলন বিশ্লেষক চালিয়েছি এবং খুব বিরল ইভেন্ট অ্যাপ্লিকেশন লগ ত্রুটি 833 ব্যতীত অন্য কিছুই খুঁজে পাই না, এর মধ্যে কোনওটিই ফেলওভার ইভেন্টগুলির সাথে একযোগ নয়:

এসকিউএল সার্ভার আই / ও অনুরোধগুলির 1 টি ঘটনা (গুলি) এর মুখোমুখি হয়েছে যাতে ফাইল [এফ: in ডেটা.এমডিএফ] ডাটাবেস [ডেটা] (9) এ সম্পূর্ণ হতে 15 সেকেন্ডের বেশি সময় নেয়। ওএস ফাইল হ্যান্ডেলটি 0x000000000000101000। সর্বশেষতম I / O এর অফসেটটি হল: 0x000007d4b10000)।

)) মাঝে মাঝে আমরা দেখতে পাই "ক্লায়েন্ট এসপিআইডি এক্সএক্সএক্সএক্সএক্সের সাথে একটি সেশন পুনরায় ব্যবহার করতে অক্ষম ছিল, যা সংযোগ পুলিংয়ের জন্য পুনরায় সেট করা হয়েছিল operation । " উভয় সার্ভার দ্বারা উত্পাদিত। কোনও "পূর্ববর্তী" বার্তা নেই যা কোনও সমস্যা ইঙ্গিত করে।

)) মাঝে মাঝে ডাটাবেস মেল অ্যাপ্লিকেশন ইভেন্ট লগতে একটি ত্রুটি লিখে:

ব্যতিক্রম প্রকার: মাইক্রোসফ্ট.এসএইচএল সার্ভার.ম্যানেজমেন্ট.সক্লিমাইল.সার্ভার.কমন.বেস এক্সসেপশন বার্তা: সংযোগটিতে একটি ত্রুটি ছিল। কারণ: সময়সীমা শেষ হয়েছে। অপারেশন শেষ হওয়ার আগে সময়সীমা অতিক্রান্ত হয়েছে বা সার্ভার সাড়া দিচ্ছে না, SQLLCnnicationInfo) সহায়তা লিঙ্ক: নাল সূত্র: ডাটাবেসমেলইঙ্গাইন

মাইক্রোসফ্ট.সেক্লসার সার্ভার.ম্যানেজমেন্ট.সক্লিমাইল. সার্ভার.ডাটাঅ্যাক্সেস.সংযোগ ম্যানেজার.অপেনকনেকশন (স্কেলকনেকশনআইএনফো সিআই) এ স্ট্যাকট্রেস তথ্য, ডেটাঅ্যাক্সেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসনেসঅ্যাকসেসনমেজিং ) মাইক্রোসফ্ট.সক্ল্যাওয়ার সার্ভার.ম্যানেজমেন্ট.সক্লিমাইল.আইমেলপ্রসেস.কুইউ আইটেমপ্রসেসার.প্রসেসকুইউ আইটেমস (স্ট্রিং ডিবিনেম, স্ট্রিং ডিবি সার্ভারনাম, ইন্টার 32 লাইফ মাইনিম্যাসেক, লগ-লেভেল লগিং লেভেল)

আমি বিশ্বাস করি টাইমআউটগুলি ব্যর্থতার কারণ ঘটায়; কি এই সময়সীমা কারণ হতে পারে? স্পষ্টতই যদি কোনও আসল নেটওয়ার্ক ইস্যু যেমন খারাপ ব্যাবস্থা, বা খারাপ সুইচ থাকায় প্যাকেট নষ্ট হতে পারে এবং তাই সময়সীমা শেষ হতে পারে তবে অন্য কোন জিনিস সময়সীমা আউট করার কারণ হতে পারে? ব্লকিং? যদি এমএসডিবি, বা অন্য কোনও সিস্টেমের ডাটাবেসে আই / ও টাইমআউট হয়ে থাকে যা মিররিং ব্যর্থতার কারণ হতে পারে?

কোন পরামর্শের জন্য ধন্যবাদ!

টাইমআউট প্রক্রিয়া নিজেই সম্পর্কে এমএসডিএনের নিম্নলিখিত কথা রয়েছে :

মিররিং টাইম-আউট মেকানিজম

যেহেতু নরম ত্রুটিগুলি সরাসরি কোনও সার্ভার উদাহরণস্বরূপ সনাক্ত করা যায় না, একটি নরম ত্রুটি সম্ভবত কোনও সার্ভারের উদাহরণটি অনির্দিষ্টকালের জন্য অপেক্ষা করতে পারে। এটি প্রতিরোধের জন্য, ডাটাবেস মিররিং তার নিজস্ব সময়-আউট প্রক্রিয়াটি প্রয়োগ করে, প্রতিটি সার্ভারের উদাহরণের ভিত্তিতে একটি মিররিং সেশনে একটি নির্দিষ্ট বিরতিতে প্রতিটি খোলা সংযোগে একটি পিং প্রেরণ করে।

সংযোগটি উন্মুক্ত রাখতে একটি সার্ভারের উদাহরণটি সংজ্ঞায়িত সময়-সময়কালে সেই সংযোগের সাথে একটি পিং গ্রহণ করতে হবে, সাথে সাথে আরও একটি পিং প্রেরণের জন্য প্রয়োজনীয় সময়। সময়সীমার সময়কালে একটি পিং পাওয়া ইঙ্গিত দেয় যে সংযোগটি এখনও খোলা আছে এবং সার্ভারের দৃষ্টান্তগুলি এটিতে যোগাযোগ করছে। পিং পাওয়ার পরে, কোনও সার্ভার উদাহরণটি সেই সংযোগে তার সময়-আউট কাউন্টারটিকে পুনরায় সেট করে।

সময়-আউট সময়কালে কোনও সংযোগে যদি কোনও পিং না পাওয়া যায় তবে কোনও সার্ভার উদাহরণটি সংযোগকে সময়সীমা শেষ বলে বিবেচনা করে। সার্ভার উদাহরণস্বরূপ সময়সীমা সংযোগ বন্ধ করে এবং সেশনটির রাজ্য এবং অপারেটিং মোড অনুসারে টাইম আউট ইভেন্ট পরিচালনা করে।

netsh interface tcp show global শো:

Receive-Side Scaling State          : disabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : disabled
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled

netsh interface ipv4 show dynamicportrange tcp

Protocol tcp Dynamic Port Range

Start Port      : 1025
Number of Ports : 64510

SELECT name, value_in_use FROM sys.configurations

    অ্যাডহক বিতরণ প্রশ্নাবলী 0         
    অ্যাফিনিটি I / O মাস্ক 0         
    অ্যাফিনিটি মাস্ক 0         
    affinity64 I / O মাস্ক 0         
    affinity64 মাস্ক 0         
    এজেন্ট এক্সপিএস 1         
    আপডেট 0 অনুমতি দিন         
    বিস্ময়কর 0 সক্ষম         
    ব্লক প্রক্রিয়া প্রান্তিকর 5         
    সি 2 অডিট মোড 0         
    clr সক্ষম 1         
    সাধারণ মানদণ্ডের সম্মতি 0 সক্ষম করে         
    সমান্তরালতা 4 জন্য ব্যয় প্রান্তিককরণ         
    ক্রস ডিবি মালিকানা চেইন 0         
    কার্সার থ্রেশহোল্ড -১        
    ডাটাবেস মেল এক্সপিএস 1         
    ডিফল্ট পূর্ণ পাঠের ভাষা 1033      
    ডিফল্ট ভাষা 0         
    ডিফল্ট ট্রেস সক্ষম 1         
    ট্রিগার 0 থেকে ফলাফল বাতিল করবেন না         
    পরিপূর্ণ ফ্যাক্টর (%) 0         
    ফুট ক্রল ব্যান্ডউইথ (সর্বাধিক) 100       
    ফুট ক্রল ব্যান্ডউইথ (মিনিট) 0         
    ft notify ব্যান্ডউইথ (সর্বাধিক) 100       
    ft notify ব্যান্ডউইথ (মিনিট) 0         
    সূচক তৈরি মেমরি (কেবি) 0         
    ইন-সন্দেহ এক্স্যাক্ট রেজোলিউশন 0         
    লাইটওয়েট পুলিং 0         
    লক 0         
    সমান্তরালতা সর্বাধিক ডিগ্রি 6         
    সর্বাধিক পূর্ণ-পাঠ্য ক্রল পরিসীমা 4         
    সর্বাধিক সার্ভার মেমরি (এমবি) 393216    
    সর্বাধিক পাঠ্য repl আকার (বি) 65536     
    সর্বোচ্চ কর্মী থ্রেড 0         
    মিডিয়া ধরে রাখা 0         
    প্রতি ক্যোয়ারে মিনিট মেমরি (KB) 2048 48      
    মিনিট সার্ভার মেমরি (এমবি) 52427     
    নেস্টেড ট্রিগার 1         
    নেটওয়ার্ক প্যাকেটের আকার (বি) 1400      
    ওলে অটোমেশন পদ্ধতি 1         
    ওপেন অবজেক্ট 0         
    পিএইচ সময়সীমা 60        
    প্রাক্পম্পিউট র‌্যাঙ্ক 0         
    অগ্রাধিকার 0         
    গভর্নরের ব্যয়ের সীমা 0         
    ক্যোয়ারী ওয়েট (গুলি) -1        
    পুনরুদ্ধারের ব্যবধান (মিনিট) 0         
    দূরবর্তী অ্যাক্সেস 1         
    দূরবর্তী প্রশাসক সংযোগ 0         
    দূরবর্তী লগইন সময় শেষ (গুলি) 20        
    রিমোট প্রোক ট্রান্স 0         
    দূরবর্তী ক্যোয়ারির সময়সীমা 600 (গুলি)       
    প্রতিলিপি এক্সপি 0         
    প্রারম্ভের জন্য 0 স্ক্যান         
    সার্ভার ট্রিগার পুনরাবৃত্তি 1         
    সেট সেট আকার 0         
    উন্নত বিকল্পগুলি দেখান 1         
    এসএমও এবং ডিএমও এক্সপি 1         
    এসকিউএল মেল এক্সপিএস 0         
    শব্দ শব্দ 0 রূপান্তর         
    দুই অঙ্কের বছরের কাটফফ 2049      
    ব্যবহারকারী সংযোগ 0         
    ব্যবহারকারী বিকল্পসমূহ 4216      
    ওয়েব সহায়ক পদ্ধতি 0         
    এক্সপি_সিএমডি শেল 1

কিছুক্ষণ আগে, আমি mirroring_connection_timeoutসমস্যাটি পুনরুদ্ধারের চেষ্টা করার জন্য আমি সমস্ত মিররযুক্ত ডেটাবেসগুলির মানটি 30 সেকেন্ডে ম্যানুয়ালি সংশোধন করেছি ; এটি কেবল ব্যর্থতা ইভেন্টগুলির মধ্যে সময়ের পরিমাণ বাড়িয়েছে। সঙ্গে mirroring_connection_timeout10 সেকেন্ড ডিফল্ট সেটিংস সেট, আমরা একটি দেখতে অনেক বেশি ফেলওভারস।

একটি মন্তব্য আমাকে আইপিএসসি অক্ষম করা হয়েছে তা নিশ্চিত করতে বলেছে, তাই আমি netshঅপারেটিং সিস্টেমের আইপিসেক কনফিগারেশন প্রদর্শিত বেশ কয়েকটি কমান্ডের বিষয়বস্তু পোস্ট করছি :

সি: \> নেট নেট আইপিসে ডায়নামিক সব দেখান
বর্তমানে অর্পিত নীতি নেই
মেইনমোড পলিসি উপলভ্য নয়।
কুইকমোড নীতিগুলি উপলভ্য নয়।
জেনেরিক মেনমোড ফিল্টারগুলি উপলভ্য নয়।
নির্দিষ্ট মেনমোড ফিল্টার উপলভ্য নয়।
জেনেরিক কুইকমোড ফিল্টারগুলি উপলভ্য নয়।
নির্দিষ্ট কুইকমোড ফিল্টার উপলভ্য নয়।
আইপিএসেক মেইনমোড সুরক্ষা সমিতিগুলি উপলভ্য নয়।
আইপিস্ক কুইকমোড সুরক্ষা সমিতিগুলি উপলভ্য নয়।

আইপিসি কনফিগারেশন প্যারামিটার
------------------------------
স্ট্রংসিআরএল চেক: 1
আইপিসেক্সেক্সিট: 3

আইপিএসসি পরিসংখ্যান
----------------
সক্রিয় সহযোগী: 0
অফলোড এসএ: 0
মুলতুবি কী: 0
মূল অ্যাডস: 0
কী মোছা: 0
রেইকিস: 0
সক্রিয় টানেল: 0
খারাপ এসপিআই Pkts: 0
Pkts ডিক্রিপ্ট করা হয়নি: 0
Pkts প্রমাণীকৃত নয়: 0
রিপ্লে সনাক্তকরণ সহ পিকেটস: 0
গোপনীয় বাইট পাঠানো হয়েছে: 0
গোপনীয় বাইট প্রাপ্ত: 0
প্রমাণীকৃত বাইট পাঠানো হয়েছে: 0
প্রমাণীকৃত বাইট প্রাপ্ত: 0
পরিবহন বাইট প্রেরণ: 0
প্রাপ্ত পরিবহণ বাইট: 0
টানেলগুলিতে বাইট পাঠানো হয়েছে: 0
টানেলগুলিতে বাইটস পাওয়া গেছে: 0
অফলোডড বাইট প্রেরিত: 0
অফলোডড বাইটস প্রাপ্ত: 0

সি: \> নেট নেট ইপস্যাক স্ট্যাটিক সব দেখায়
ERR IPsec [05072]: পলিসি স্টোরটিতে কোনও নীতি নেই

আপডেট: 2012-12-20

আমরা এখন আমাদের উত্পাদন সিস্টেমগুলি এসকিউএল সার্ভারে 2012 এ সরিয়ে নিয়েছি 17 যাইহোক, আমরা 2005-ভিত্তিক সিস্টেমগুলির সাথে যা দেখেছি তার মধ্যে বেশ কয়েকটি দিন ভাল।

আমাদের নতুন সিস্টেমগুলির কর্মক্ষমতা ডকুমেন্ট করার প্রয়াসে, আমি sys.dm_os_wait_statsআরও সাবধানে তাকিয়েছি; এবং লক্ষ্য করা গেছে DBMIRROR_DBM_EVENT, এটি একটি অনিবন্ধিত অপেক্ষা ধরণের। মাইক্রোসফ্টে গ্রাহাম কেন্টের অপ্রত্যাশিত ব্যর্থতা এবং এই অপেক্ষার প্রকারের সমস্যা সমাধানের বিষয়ে একটি আকর্ষণীয় নিবন্ধ রয়েছে । আমি তার অনুসন্ধানগুলি এখানে পুনরুদ্ধার করব:

গ্রাহক একটি উচ্চ পরিমাণে ওয়ালটিপি ডাটাবেসে নির্মিত একটি বিশাল ব্লকিং চেইনটি अनुभव করছিলেন যেখানে সমস্ত হেড ব্লকাররা DBMIRROR_DBM_EVENT এ অপেক্ষা করছিল। এখানে আমি যে ইভেন্টগুলির মধ্য দিয়েছি তার ধারাবাহিকতা এখানে:

অবরুদ্ধ শৃঙ্খলা নিজেই পর্যালোচনা করুন - হো আমরা এখানে দেখতে যেমন সহায়তা পেতে পারি তা হ'ল আমরা ডিবিএমআইআরআর_আরবিএম_ইভেন্টের জন্য অপেক্ষা করছি
অননুমোদিত অপেক্ষা প্রকারের উত্সটি পর্যালোচনা করুন। স্পষ্টতই আপনি এমএস এর বাইরে এটি করতে পারবেন না, তবে আমি বলতে পারি যে এই অপেক্ষা প্রকারটি লেখার সময় যখন প্রিন্সিপাল একটি এলএসএন শক্ত করার জন্য আয়নাটির জন্য অপেক্ষা করছিল তখন তার জন্য ব্যবহৃত অপেক্ষাটি বোঝায়, যার অর্থ এটি লেনদেনের অংশ যার অংশ হতে পারে না । এটি তাত্ক্ষণিকভাবে সমস্যার দিকে বিশেষভাবে ইঙ্গিত করে যে অধ্যক্ষটি আয়নাতে অপেক্ষা করার কারণে অধ্যক্ষ লেনদেন করতে পারবেন না। এখন আমাদের তদন্ত করতে হবে যে আয়না কেন লেনদেন করছে না বা অধ্যক্ষ কেন তা জানেন না।
এমএসডিবি সিস্টেম টেবিলগুলি পর্যালোচনা করুন

(ক) সমস্যার সময় উত্পন্ন লগগুলির আকার স্বাভাবিকের চেয়ে উল্লেখযোগ্যভাবে বেশি হয় কিনা তা দেখতে [ব্যাকআপসেট] টেবিলটি দেখুন। যদি তারা ব্যতিক্রমীভাবে বড় হয় তবে এটি হতে পারে যে আয়নাটি লেনদেনের সাথে প্লাবিত হয়েছিল এবং খালি ভলিউমটি ধরে রাখতে পারে না। এই কারণেই অনলাইনে বই আপনাকে মাঝে মাঝে মিররিং অক্ষম করতে বলবে যদি আপনাকে কোনও সূচক পুনর্নির্মাণের মতো ব্যতিক্রমী বড় লগড অপারেশন করতে হয়। (এটি http://technet.microsoft.com/en-us/library/cc917681.aspx এ কেন রয়েছে তার রেফারেন্স )। এখানে আমি নিম্নলিখিত টিএসকিউএল ব্যবহার করেছি

SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go

select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'

(খ) দ্বিতীয়ত আমি সারণিতে থাকা ডেটা [dbm_monitor_data] এর দিকে চেয়েছিলাম looked এখানে মূল কীটি হ'ল সময়সীমার সন্ধান করা যেখানে আমাদের কোনও সমস্যা ছিল এবং তারপরে দেখুন আমরা নীচের যে কোনও একটিতে উল্লেখযোগ্য পরিবর্তন আসছি কিনা:

log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate

এগুলি অংশ (ক) এর অনুরূপ সমস্ত সূচক যা তারা কোনও উপাদান বা আর্কিটেকচারের অংশটি প্রদর্শন করতে পারে যা সাড়া দিচ্ছে না। উদাহরণস্বরূপ যদি সেন্ড_কিউ হঠাৎই বৃদ্ধি পেতে শুরু করে তবে পুনরায় সারিটি বাড়তে থাকে না, তবে বোঝা যাচ্ছে যে অধ্যক্ষটি আয়নায় লগ রেকর্ডগুলি প্রেরণ করতে পারবেন না যাতে আপনি সংযোগটি দেখতে চান, অথবা পরিষেবা ব্রোকারের সারিগুলি ues প্রকৃত সংক্রমণ সঙ্গে ডিল।

এই নির্দিষ্ট দৃশ্যে আমরা উল্লেখ করেছি যে সমস্ত কাউন্টারে অদ্ভুত মান রয়েছে বলে মনে হয়েছিল যে লগ ব্যাকআপগুলি স্বাভাবিক আকারের চলছিল, তবে কোনও স্থিতি পরিবর্তন হয়নি, 0 প্রেরণ সারি, 0 পুনরায় সারি, একটি ফ্ল্যাট প্রেরণের হার এবং একটি ফ্ল্যাট পুনরায় হার। এটি অত্যন্ত আশ্চর্যজনক যেহেতু ইঙ্গিত দেয় যে সমস্যাকালীন সময়ে ডিবিএম মনিটর কোথাও কোনও মান রেকর্ড করতে পারেনি।

এসকিউএল সার্ভার ত্রুটি লগগুলি পর্যালোচনা করুন। এক্ষেত্রে কোনও ত্রুটি বা তথ্য বার্তা ছিল না, তবে অন্যান্য পরিস্থিতিতে যেমন 1400 রেঞ্জের ত্রুটিগুলি রিপোর্ট করা খুব সাধারণ বিষয়, এর উদাহরণগুলি যেমন আপনি আমার অন্যান্য মিররিং ব্লগগুলিতে অন্য জায়গায় খুঁজে পেতে পারেন, যেমন এই ত্রুটি 1413 উদাহরণ

ডিফল্ট ট্রেস ফাইলগুলি পর্যালোচনা করুন - এই দৃশ্যে আমাকে ডিফল্ট ট্রেস সরবরাহ করা হয়নি তবে তারা ডিবিএম সমস্যা সম্পর্কিত তথ্যের দুর্দান্ত উত্স, কারণ তারা সমস্ত অংশীদারদের উপর রাষ্ট্র পরিবর্তন ইভেন্টগুলি রেকর্ড করে hisএটি এখানে নথিযুক্ত:

ডেটাবেস মিররিং স্টেট চেঞ্জ ইভেন্ট ক্লাস

এটি প্রায়শই আপনাকে দৃশ্যের দুর্দান্ত চিত্র দেয় যেমন কোনও অংশীদারদের মধ্যে একজন বা সমস্তের মধ্যে যখন নেটওয়ার্ক সংযোগ ব্যর্থ হয় এবং এরপরে অংশীদারিত্বের অবস্থা কী হয়ে যায়।

সবিশেষ বক্তব্য হচ্ছে,

এই নির্দিষ্ট দৃশ্যে আমি বর্তমানে 2 টি মূল পয়েন্টের অনুপস্থিত রয়েছি, তবে এর বাইরে আমি উপরের তথ্যের উপর যুক্তিসঙ্গত অনুমান করতে পারি। আমরা অবশ্যই বলতে পারি যে ব্লককারীরা DBMIRROR_DBM_EVENT অপেক্ষার প্রকারের অপেক্ষায় থাকার কারণে DBM সক্ষম হয়েছিল এই কারণে was যেহেতু আমরা জানি যে আমরা একটি বৃহত লগড অপারেশন দিয়ে আয়না প্লাবিত করি নি এবং এই মোতায়েনটি সাধারণত এই মোডে আনন্দের সাথে চালিত হয় তাই আমরা অস্বাভাবিক বড় অপারেশনগুলি বাদ দিতে পারি। এর অর্থ এই পর্যায়ে আমাদের 2 জন সম্ভাব্য প্রার্থী রয়েছেন:

কিছু বা সমস্ত অংশীদারদের মধ্যে সংযোগের ক্ষেত্রে হার্ডওয়্যার সমস্যা।
মিরর সার্ভারে সিপিইউ ক্লান্তি - কেবল রেডোগুলি ধরে রাখতে অক্ষম - সিপিইউ ক্লান্তি নিজেই এসকিউএল সার্ভারের বাইরে বা এই আয়না অংশীদারিত্বের বাইরের কোনও প্রক্রিয়া হতে পারে।
মিররিং কোড নিজেই একটি সমস্যা (যদিও এটি নিশ্চিত করতে আমাদের কিছু মেমরি ডাম্প প্রয়োজন)।

অভিজ্ঞতার ভিত্তিতে আমি সন্দেহ করি 1 বা 2, তবে আমি প্রায় 3 টি সম্পর্কেও সর্বদা উন্মুক্ত থাকি, এই সমস্যাটি আরও বিশদে দেখার জন্য আমরা এখন আরও কিছু ডেটা সংগ্রহ করার চেষ্টা করছি।

— ম্যাক্স ভার্নন
সূত্র

আর একটি জিনিস যাচাই করা হবে আইপিএসেক। প্রায়শই আইপিসেক সংযোগের প্রচেষ্টাতে বিলম্ব বা অবরুদ্ধ করতে পারে। সময়সীমা বন্ধ হয়ে যায় কিনা তা দেখতে IPSec অক্ষম করুন।

— রবার্ট এল ডেভিস