বাল্ক সন্নিবেশ সময় বড় বৈচিত্র

Question

সুতরাং আমার স্টেজিং টেবিল থেকে ডেটা নেওয়ার জন্য এবং এটি আমাদের ডেটামার্টে সরাতে আমার কাছে একটি সাধারণ বাল্ক সন্নিবেশ প্রক্রিয়া রয়েছে।

প্রক্রিয়াটি "প্রতি ব্যাচ সারি" এর জন্য ডিফল্ট সেটিংস সহ একটি সহজ ডেটা ফ্লো টাস্ক এবং বিকল্পগুলি "ট্যাবলক" এবং "কোনও চেক সীমাবদ্ধতা" নয়।

টেবিলটি মোটামুটি বড়। ৫৮7,১62২,৯86 একটি ডেটা আকারের সাথে 201 গিগাবাইট এবং 49 জিবি সূচী স্পেস। টেবিলের জন্য ক্লাস্টারড ইনডেক্স।

CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
    DOC_ID ASC,
    ACCT_NUM ASC,
    MasterID ASC
)

এবং প্রাথমিক কীটি হ'ল:

ALTER TABLE dbo.ImageData 
ADD CONSTRAINT ImageData 
PRIMARY KEY NONCLUSTERED 
(
    ImageID ASC,
    DT_CRTE_DOC ASC
)

এখন আমাদের একটা সমস্যা হচ্ছে যেখানে BULK INSERTএসএসআইএসের মাধ্যমে অবিশ্বাস্যভাবে ধীর গতিতে চলছে। এক মিলিয়ন সারি toোকাতে 1 ঘন্টা। সারণীটি তৈরি করে এমন ক্যোয়ারী ইতিমধ্যে বাছাই করা হয়েছে এবং পপুলেট করার ক্যোয়ারী চালাতে এক মিনিটের মধ্যে সময় নেয়।

প্রক্রিয়াটি চলমান থাকাকালীন আমি বুক সন্নিবেশের অপেক্ষায় থাকা কোয়েরিটি দেখতে পাচ্ছি যা 5 থেকে 20 সেকেন্ডের মধ্যে যে কোনও সময় নেয় এবং এর অপেক্ষার প্রকারটি দেখায় PAGEIOLATCH_EX। প্রক্রিয়াটি INSERTএকবারে প্রায় এক হাজার সারি সক্ষম ।

গতকাল আমার ইউএটি পরিবেশের বিরুদ্ধে এই প্রক্রিয়াটি পরীক্ষা করার সময় আমি একই সমস্যাটিতে চলে আসছিলাম। আমি কয়েকবার প্রক্রিয়াটি চালিয়ে যাচ্ছিলাম এবং এই ধীর সন্নিবেশের মূল কারণটি নির্ধারণ করার চেষ্টা করছি। তারপরে হঠাৎ এটি 5 মিনিটের নীচে চলতে শুরু করে। সুতরাং আমি একই ফলাফল দিয়ে আরও কয়েকবার চালিয়েছি। এছাড়াও 5 বালিক সন্নিবেশকারীদের সংখ্যা যা 5 সেকেন্ড বা তার চেয়েও বেশি অপেক্ষা করছিল তা শত শত ফর্ম থেকে নামিয়ে দেয়।

এখন এটি বিস্মিত হচ্ছে কারণ এটি কার্যকলাপের মতো আমাদের কিছুটা বিশাল ড্রপ বন্ধ করার মতো নয়।

সময়কালীন সিপিইউ কম হয়।

সময়গুলি যখন ধীর হয় ততক্ষণে ডিস্কে কম অপেক্ষা করা হয়।

5 মিনিটের মধ্যে প্রক্রিয়াটি চলমান সময়সীমার সময়ে ডিস্কের বিলম্বিতা আসলে বেড়ে যায়।

এবং এই প্রক্রিয়াটি খারাপভাবে চলতে থাকাকালীন আইও অনেক কম ছিল।

আমি ইতিমধ্যে যাচাই করেছি এবং ফাইলগুলি কেবল 70% পূর্ণ হওয়ায় কোনও ফাইলের বৃদ্ধি হয়নি। লগ ফাইল এখনও যেতে 50% আছে। ডিবি সিম্পল রিকভারি মোডে রয়েছে। ডিবিতে কেবল একটি ফাইল গ্রুপ রয়েছে তবে এটি 4 টি ফাইল জুড়ে ছড়িয়ে রয়েছে।

সুতরাং আমি কী আশ্চর্য করছি : কেন আমি এতগুলি বড় পরিমাণের সন্নিবেশগুলিতে এত বড় অপেক্ষা করার সময়টি দেখছিলাম। বি: কী ধরণের ম্যাজিক ঘটেছিল যা এটি দ্রুত চালিত করে?

সাইড নোট. এটি আজ আবার বোকাতির মতো চলে।

আপডেট করুন এটি বর্তমানে বিভাজনযুক্ত। তবে এটি এমন পদ্ধতিতে করা হয়েছে যা সেরা নির্বোধ।

CREATE PARTITION SCHEME [ps_Image] AS PARTITION [pf_Image] 
TO ([FG_Image], [FG_Image], [FG_Image], [FG_Image])

CREATE PARTITION FUNCTION [pf_Image](datetime) AS 
RANGE RIGHT FOR VALUES (
      N'2011-12-01T00:00:00.000'
    , N'2013-04-01T00:00:00.000'
    , N'2013-07-01T00:00:00.000'
);

এটি মূলত 4 র্থ বিভাজনের সমস্ত ডেটা ছেড়ে দেয়। তবে যেহেতু এটি সমস্ত একই ফাইল গ্রুপে যাচ্ছে। এই ফাইলগুলিতে ডেটা বর্তমানে সমানভাবে বিভক্ত।

আপডেট 2 প্রক্রিয়াটি খারাপভাবে চলতে থাকে এগুলি সামগ্রিকভাবে অপেক্ষা করে।

আমি যে প্রক্রিয়াটি চালাতে সক্ষম হয়েছি সেই সময়কালের জন্য এটি অপেক্ষা করছে well

স্টোরেজ সাবসিস্টেমটি স্থানীয়ভাবে সংযুক্ত RAID, কোনও SAN জড়িত। লগগুলি একটি ভিন্ন ড্রাইভে রয়েছে। রাইড কন্ট্রোলারটি 1 জিবি ক্যাশে আকারের পিইআরসি এইচ 800 হয়। (ইউএটি জন্য) প্রোড একটি পিইআরসি (810)।

আমরা কোনও ব্যাকআপ না নিয়ে সাধারণ পুনরুদ্ধারটি ব্যবহার করছি। এটি একটি প্রযোজনার অনুলিপি থেকে রাতে পুনরুদ্ধার করা হয়।

IsSorted property = TRUEডেটা ইতোমধ্যে সাজানো থেকে আমরা এসএসআইএস এও সেট করেছি ।

Comments

ASYNC_NETWORK_IOএর অর্থ এসকিউএল সার্ভার কোথাও কোনও ক্লায়েন্টকে সারি পাঠানোর অপেক্ষায় ছিল । আমি মনে করি যে এটি মঞ্চের সারণী থেকে এসএসআইএস সারি ব্যবহারের ক্রিয়াকলাপটি দেখাচ্ছে।

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

PAGEIOLATCH_EXএবং ASYNC_IO_COMPLETIONইঙ্গিত করছে যে এটি ডিস্ক থেকে মেমরিতে ডেটা পেতে কিছুটা সময় নিয়েছে। এটি ডিস্ক সাবসিস্টেমের সমস্যার একটি সূচক হতে পারে, বা এটি মেমরির বিতর্ক হতে পারে। এসকিউএল সার্ভারে কত স্মৃতি উপলব্ধ রয়েছে?

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

ইমেজডাটার একটি টেবিলের নাম সহ, আপনি আমাকে কৌতূহলী করেছেন - আসল সারণির সংজ্ঞাটি কী? আপনি যদি এলওবি ডেটা টানছেন, আপনি সম্ভবত ডিস্কে বাফারিং করে যাচ্ছেন (যা BLOBTempStoragePath এ যায় যা অপরিবর্তিত থাকলে নির্বাহক ব্যবহারকারীর% TEMP% ডিরেক্টরি ওরফে সি ড্রাইভ হবে)

— বিলিংক

সারণী সংজ্ঞা পোস্ট করতে পারবেন না তবে এটি একটি চিত্রযুক্ত নথি information

— জেন

আমি সন্দেহ করি এটি সমান্তরাল প্রক্রিয়াজাতকরণ সমস্যা। আমি আপনাকে আপনার MAXDOP টিউন করার পরামর্শ দিচ্ছি (1 থেকে 4 থেকে শুরু করে) এবং কীভাবে চলছে তা দেখুন। অন্যদিকে, পরীক্ষার উদ্দেশ্যে, আমি বরং এসএসআইএস প্রতিস্থাপনের জন্য একটি বিসিপি কমান্ড তৈরি করব এবং দেখুন কিনা কোনও পার্থক্য আছে কিনা।

— jyao

Answer 1

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

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

একটি পার্টিশন ফাংশন থাকা ভুল নয় যা সমস্ত বর্তমান সন্নিবেশকে এক টেবিল বিভাজনে ফেলে দেয়, তবে একই ফাইলগ্রুপের পার্টিশনগুলির সাথে পার্টিশনটি কীভাবে কার্যকর হয় তা আমি দেখতে পাচ্ছি না। এবং ডেটটাইম ব্যবহার করা দুর্বল এবং এসকিউএল সার্ভার ২০০৮ সাল থেকে স্পষ্ট রূপান্তর সূত্র ছাড়াই ডেটটাইমের জন্য এবং'YYYY-MM-DD 'প্রকৃতির জন্য একধরণের ভাঙ্গা (এসকিউএল প্রফুল্লভাবে এটিকে YYYY-DD-MM হিসাবে বিবেচনা করতে পারে: মজাদার নয়: আতঙ্কিত হবেন না, কেবল এটি 'YYYYMMDD' এ পরিবর্তন করুন, স্থির: বা কনভার্ট (তারিখের সময়, 'YYYY-MM-DDT00: 00: 00', 126), আমার মনে হয় এটি)। তবে আমি মনে করি পার্টিশনের জন্য তারিখের মানের জন্য প্রক্সি (ইন্ট্রি হিসাবে বছর বা বছর + ত্রৈমাসিক) আরও ভাল কাজ করবে।

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

এটি এমন একটি ডিজাইনের মতো অনুভূত হয়েছে যেখানে ভবিষ্যতে কিছু সময় 1 পার্টিশনের বিষয়বস্তু ফেলে দেওয়ার এবং আরও নতুন ডেটার জন্য আরও একটি নতুন পার্টিশন তৈরি করার পরিকল্পনা রয়েছে তবে এটি এখানে ঘটছে বলে মনে হয় না। কমপক্ষে 2013 সালের পরে এটি ঘটেনি।

Answer 2

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