দক্ষতার সাথে বিশাল পরিমাণে (84 মিলিয়ন সারি) ডেটা স্থানান্তর করা

Question

আমার প্রায় 84 মিলিয়ন সারি রয়েছে। তাদের সকলেরই একই সার্ভারে একটি পৃথক ডাটাবেসে স্থানান্তরিত হওয়া দরকার, তবে আমি উত্স ডাটাবেস থেকে প্রায় 60 মিলিয়ন সারি মুছে ফেলতে মুছি।

৮৪ মিলিয়ন সারিগুলি একই টেবিলে রয়েছে। এই টেবিলটি একাই পুরো ডাটাবেসের 90% ভাগ করে নেয়।

সুতরাং ... উত্স: 84 মিলিয়ন সারি -> 24 মিলিয়ন সারি গন্তব্য: 0 টি সারি -> 84 মিলিয়ন সারি

উত্সটি পুরো পুনরুদ্ধার মোডে চলছে, গন্তব্যটি সহজ চলছে।

আমি ভাবছি এটি করার সবচেয়ে দক্ষ উপায়টি কী হবে?

পরিকল্পনা একটি:

1) উত্স থেকে গন্তব্য নির্বাচন করুন * নির্বাচন করুন

2) ট্রান্সকেট উত্স

3) INSERT INTO উত্সটি নির্বাচন করুন * গন্তব্য থেকে যেখানে রাখুন_কন্ডিশন = 1

পরিকল্পনা বি:

1) গন্তব্য ডাটাবেস হিসাবে উত্স ডাটাবেসের একটি ব্যাকআপ পুনরুদ্ধার

2) গন্তব্য ডেটাবেজে প্রয়োজনীয় একটি ব্যতীত প্রতিটি টেবিল বাদ দিন

3) ট্রান্সকেট উত্স

4) INSERT INTO উত্সটি নির্বাচন করুন * গন্তব্য থেকে যেখানে রাখুন_সমর্থন = 1 1

পরিকল্পনা সি:

1) উত্স থেকে গন্তব্য নির্বাচন করুন * নির্বাচন করুন

2) উত্সটি যেখানে রাখুন_শক্তি = 0 মুছুন

অথবা অন্য কিছু?

ধন্যবাদ

Comments

আপনি কেন আমদানি এবং রফতানি ডেটা উইজার্ড ব্যবহার করবেন না? এটি এসকিউএল সার্ভারের ইনস্টলেশন সহ একটি সরঞ্জাম।

— হানি এল মৌল্লেম

নতুন মিলিতে 24 মিল সারিগুলি অনুলিপি করা কি সম্ভব, তবে কেবল দু'টির প্রয়োজন অনুসারে নতুন নামকরণ করুন যাতে আপনি অকারণে 84 মিলিয়ন সারি সরিয়ে নিচ্ছেন না?

— লোলিডিবিএ

এটি কি একসময়ের বা চলমান প্রক্রিয়া? আমি জিজ্ঞাসা করছি কারণ, ৮০ এম সারিগুলি প্রক্রিয়া করার জন্য যে সময় দেওয়া হয়েছে, সম্ভবত এটি উত্সে থাকা উত্স সারিগুলিতে ডেটা পরিবর্তন হতে পারে যা এখন ডিস্টিনেশনে বাস করা উচিত।

— মাইকেল গ্রিন

এটি একটি এক্সওয়াই সমস্যার মতো দেখাচ্ছে: আপনার একটি ডিবিতে সমস্ত 84 মিমি সারি এবং দ্বিতীয় ডিবিতে থাকা 24 মিলিমিটারের শেষ হওয়া উচিত। কোন ব্যবসায়ের প্রয়োজনীয়তার জন্য কেবল 24 মিমি সরানোর পরিবর্তে 84 মিমি সরানো এবং 60 এম মুছে ফেলা দরকার? লিঙ্ক: মেটা.স্ট্যাকেক্সেঞ্জিং :: প্রশ্নগুলি / 636377/// কি- আইস-থি-অক্সি- প্রব্লেম )

— পিটার জেরকেনস

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

— বিলাওস্কি

Answer 1

আমি এটি যুক্ত করব, তবে আপনি এটির কাছে যাওয়ার সিদ্ধান্ত নিয়েছেন, আপনাকে এই লেনদেনের ব্যাচ করতে হবে । আমি লিঙ্কিত নিবন্ধটির ইদানীং খুব ভাল ভাগ্য পেয়েছি এবং আমি দেখতে পাচ্ছি যে বেশিরভাগ ব্যাচযুক্ত সমাধানের বিপরীতে এটি সূচকের সুবিধা গ্রহণ করে।

এমনকি লঘুভাবে লগইন করা, সেগুলি বড় লেনদেন এবং আপনার অস্বাভাবিক লগ বৃদ্ধির (ভিএলএফ, ছাঁটাই, ডান-সাইজিং ইত্যাদি) সামঞ্জস্যতা নিয়ে কাজ করতে অনেক সময় ব্যয় হতে পারে।

ধন্যবাদ

Answer 2

"দক্ষ" লগ ফাইলের ব্যবহার, আই / ও পারফরম্যান্স, সিপিইউ সময় বা প্রয়োগের সময় প্রয়োগ করতে পারে।

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

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

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

তারপরে আবারও, আপনার টেবিল এবং ডেটার নির্দিষ্টকরণগুলি না জেনে আপনার অন্য বিকল্পগুলির মধ্যে আরও ভাল পারফরম্যান্স করতে পারে। ব্যবহার করার চেষ্টা করুন

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. এবং দেখুন যে সবচেয়ে ভাল কাজ করে।

সম্পাদনা : বাল্ক- লগড ক্রিয়াকলাপগুলি সম্পাদন করার সময়, আপনার পয়েন্ট-ইন-টাইম পুনঃস্থাপনের সক্ষমতা প্রয়োজন হলে অপারেশনের আগে এবং পরে আপনি একটি ব্যাকআপ (পূর্ণ বা লেনদেন লগ) তৈরি করেছেন তা নিশ্চিত করুন এবং ডাটাবেসে অন্য ক্রিয়াকলাপ চলছে বলে সন্দেহ করছেন at আপনার ETL কাজটি একই সময়ে চলছে।

আমি কিছুক্ষণ আগে ন্যূনতম লগ করা অপারেশনগুলিতে একটি ব্লগ পোস্ট লিখেছিলাম , সেখানে অন্যান্য পোস্ট এবং ডকুমেন্টেশনের লিঙ্ক রয়েছে।

Comments

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

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

কেবল একটি প্রশ্ন, আপনি ডাটাবেসটি বাল্ক লগড মোডে থাকা অবস্থায় পুনরুদ্ধার করার সময় বিন্দুটি করার চেষ্টা করলে কী হবে? আমার মনে হয়েছিল যে কোনও লেনদেন যা "বাল্ক" হিসাবে যোগ্য নয় এটি পুনরুদ্ধারযোগ্য হবে।

— elty123

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

— রাবারচিকেনলিডার

@ উইন্ডআরভেন এটি সঠিক নয় - নীচে আমার উত্তর দেখুন।

— wobi

@ ভোবি এবং @ উইন্ডআরভেন, BULK_LOGGEDমোডটি ব্যবহার করার আগে এবং পরে ব্যাকআপ নেওয়ার প্রয়োজনীয়তার প্রতিফলন করার জন্য আমি আমার উত্তর আপডেট করেছি । ধন্যবাদ!

— ড্যানিয়েল হুটমাচার

Answer 3

বিসিপি কেন নয়?

1. সোর্সডিব ব্যাক আপ
2. সোর্সডিবকে বাল্ক-লগ-এ পরিবর্তন করুন

3. কমান্ড প্রম্পট ওপেন করুন

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. তথ্য পরীক্ষা করুন

8. এসএসএমএস থেকে সর্সডিব টেবিলটি ছাঁটাই
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. সোর্সডিব পুরোতে ফিরে যান

Comments

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

— ডব্লিউবি

Answer 4

আপনার আগে এবং পরে কোনও সম্পূর্ণ ডাটাবেস ব্যাকআপ বা টি-লগ ব্যাকআপ না করে পুনরুদ্ধারের মডেলটি পরিবর্তন করার পরামর্শ দেওয়া উচিত বলে মনে করবেন না । BULK_LOGGED পুনরুদ্ধার মডেলটির একটি বৈশিষ্ট্য হ'ল আপনি বাল্ক-লগড ক্রিয়াকলাপযুক্ত টি-লগগুলির জন্য পয়েন্ট-ইন-টাইম পুনরুদ্ধার করার ক্ষমতা হারাবেন। ক্লাসিক পরিস্থিতি: রাত্রে পুরো ব্যাকআপ, প্রতি ঘন্টা টি-লগ ব্যাকআপ। আপনি পুনরুদ্ধার মডেলটি বাল্ক-লগ-এ পরিবর্তন করেন এবং আপনার ক্রিয়াকলাপ শুরু করেন। কিছু ভুল হয়ে যায় এবং লেনদেনটি পিছনে ফিরে আসে (বা আপনি এটি ব্যবহার করেননি)। তবে আপনি নিশ্চিত নন যে ডাটাবেসে আর কি চলছে তা আপনি কোনও পরিচিত ভাল পয়েন্টে পুনরুদ্ধার করতে চান।

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

Answer 5

টেবিলের বাইরে পার্টিশন ফেলে দেওয়া একটি টেবিল থেকে বিশাল অংশের ডেটা সরিয়ে ফেলার জন্য একটি দ্রুত এবং সংস্থান-দক্ষ পদ্ধতি। যদি এই টেবিলটি এমনভাবে विभाजित করা হয়েছিল যা আপনার উত্স / গন্তব্য বিভক্তিকে সমর্থন করে তবে উত্তরটি হ'ল কোনও অনুলিপি পুনরুদ্ধার করা, গন্তব্য থেকে অপ্রয়োজনীয় টেবিলগুলি এবং অপ্রয়োজনীয় বিভাজন (গুলি) ছেড়ে দেওয়া এবং উত্স থেকে পরিপূরক পার্টিশনগুলি ফেলে দেওয়া।

পার্টিশন সক্ষম করার ব্যয় সামগ্রিকভাবে এটি আরও ব্যয়বহুল অপারেশন করতে পারে।