নিরাপদে উত্পাদন ডেটাবেস ডেটা ঠিক করা

Question

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

1. আমাদের জিজ্ঞাসা চালিয়েছে এবং তারা কী দৌড়েছে তা লগ করতে হবে
2. আদর্শভাবে আমাদের ব্যক্তিকে কেবল আগ্রহের টেবিলগুলির বিপরীতে চালানো অনুসন্ধানগুলিতে অ্যাক্সেস দেওয়া দরকার এবং কেবল অল্প সময়ের জন্য
3. অনুসন্ধানগুলি যা চলছে তা স্পষ্ট অনুমতি ছাড়াই দীর্ঘকাল চলমান এবং লকিং এসকিউএলকে না চালানোর জন্য এটি সম্পর্কে কিছু স্মার্ট থাকতে হবে
4. এই প্রক্রিয়াটির DB অজগনীয় হওয়া বা কমপক্ষে DB2, ওরাকল এবং এসকিউএল সার্ভারটি বুঝতে হবে।

আমরা "ভুল কাজ" করা থেকে অ্যাড-হক প্রোড ফিক্স-আপ প্রশ্নের ঝুঁকি হ্রাস করার চেষ্টা করছি এবং একই সাথে প্রক্রিয়াটিতে কিছু সুরক্ষা / অডিটস যুক্ত করব। ভাবনা বা ধারণা?

Comments

পরিচালনটিকে কখনই এটি স্ট্যান্ডার্ড অপারেটিং পদ্ধতি বলে মনে করতে দেবেন না। এটি মাস্ক বা গ্লাভস ছাড়াই জরুরি ওপেন হার্ট শল্য চিকিত্সা bu

— ড্যান পিচেলম্যান

এর কারণ আপনি এইভাবে কাজ করতে চান যে বাগগুলি প্রথম স্থানে ঘটেছিল।

— আয়তাকার

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

— অ্যান্ড্রু হোয়াইট

@ অ্যান্ড্রুউইট আমার ক্ষমাপ্রার্থী অ্যান্ড্রু কোনও অপরাধের উদ্দেশ্য ছিল না।

— আয়তাকার

Answer 1

উত্পাদন ডেটাবেসগুলি ম্যানুয়ালি কখনও আপডেট করবেন না।

স্ক্রিপ্ট লিখুন।

ট্রিপল এগুলি পরীক্ষা করে দেখুন এবং একাধিক লোককে এটি করতে বলুন, কেবলমাত্র একজন ব্যক্তিই এটি তিনবার করে না।

এই স্ক্রিপ্টগুলিতে পরিবর্তন-পরবর্তী বৈধতা প্রশ্নগুলি অন্তর্ভুক্ত করুন।

পরিস্থিতি যখনই মঞ্জুরি দেয়, পরিবর্তন পরবর্তী পোস্টের বৈধতা চলে যাওয়ার পরে, শেষে এমন একটি লেনদেনের মধ্যে পুরো পরিবর্তনটি পরীক্ষা করে দেখুন। ফলাফলগুলির সাথে আত্মবিশ্বাসী হলে রোলব্যাকটি কমিটিকে পরিবর্তন করুন।

পরীক্ষার ডাটাবেসের বিরুদ্ধে এই স্ক্রিপ্টগুলির বিজ্ঞাপনের nauseam পরীক্ষা করুন।

প্রোডাকশন ডাটাবেসের বিরুদ্ধে স্ক্রিপ্ট চালানোর আগে একটি ব্যাকআপ তৈরি করুন।

স্ক্রিপ্টগুলি চালান।

পোস্ট-চেঞ্জ-বৈধতা স্ক্রিপ্টগুলি ব্যবহার করে পরিবর্তিত ডেটা চেক করুন, যাচাই করুন এবং ট্রিপল পরীক্ষা করুন।

যাইহোক একটি চাক্ষুষ চেক করুন।

যদি কিছু বন্ধ মনে হয়, ব্যাক অফ করুন এবং ব্যাকআপটি পুনরুদ্ধার করুন।

উত্পাদনের ডেটা হিসাবে পরিবর্তিত ডেটা নিয়ে অগ্রসর হবেন না যতক্ষণ না আপনি নিশ্চিত হন যে সবকিছু ঠিক আছে এবং আপনি জড়িত (ব্যবসায়) পরিচালকদের কাছ থেকে সাইন আপ করেছেন।

Comments

@ অ্যান্ড্রু যে কোনও অজুহাত নয়: একটি ভুলে যান WHEREএবং আপনার ডাটাবেস সারা দিন বাকি থাকবে down বা সপ্তাহে।

— কোডকাস্টার

@ অ্যান্ড্রুউইট আপনি ডেটা ঠিক করার সবচেয়ে নিরাপদ উপায় চেয়েছিলেন, দ্রুত নয় । :-)

— এরিক কিং

@ অ্যান্ড্রুওয়াইট - আপনার ইতিমধ্যে একটি সমস্যা হয়েছে। আপনি যদি তাড়াতাড়ি তাড়াহুড়ো করেন, তবে আপনার যদি আরও দুটি সমস্যা না হয় তবে আপনি আরও দুটি সমস্যা তৈরি করতে চলেছেন এবং / অথবা আপনি আরও ভাল সমস্যার পরিবর্তে WORSE সমস্যাগুলি তৈরি করতে পারেন।

— মাইকেল কোহেন

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

— ডেভ ই

@ এরিকিং: xkcd.com/349

— রবিন

Answer 2

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

নিম্নলিখিত ক্ষেত্রেটি কল্পনা করুন:

1. সফ্টওয়্যার প্রোডাক্টটিতে একটি ত্রুটি রয়েছে যার ফলে এটি কাজ করা বন্ধ করে দেয় যখন এটি ডেটাবেসে কিছু ডেটা অসঙ্গতি বলে মনে করে তা আবিষ্কার করে,

2. সমস্ত বিকাশকারী যারা আবেদনের মধ্যে বাগটি সংশোধন করতে পারে তারা অ্যাক্সেসযোগ্য নয়,

3. সংস্থাটি বর্তমানে প্রতি ঘন্টা কয়েক হাজার ডলার হারাচ্ছে (ধরা যাক minute 6 000 ডলার, যার অর্থ প্রতি মিনিটে 100 ডলার),

4. বাগটি বেশ কয়েকটি টেবিলকে প্রভাবিত করছে, এর মধ্যে একটি বিশাল এবং এটি শুধুমাত্র ডেটা নিয়ে উদ্বেগ প্রকাশ করে, স্কিমা নয়,

5. বাগটি প্রতিরোধ করার জন্য আপনাকে ডেটা নিয়ে কিছুটা পরীক্ষা করা উচিত, যার মধ্যে এটি মুছে ফেলা এবং পরিবর্তন করা উভয়ই জড়িত,

6. ডাটাবেসটি বড় এবং ব্যাকআপটি নিতে বা পুনরুদ্ধার করতে তিন ঘন্টা সময় লাগে,

7. শেষ পুরো ব্যাকআপটি তিন সপ্তাহ আগে নেওয়া হয়েছিল; এছাড়াও দৈনিক ইনক্রিমেন্টাল ব্যাকআপ রয়েছে এবং সর্বশেষ দৈনিক ইনক্রিমেন্টাল ব্যাকআপ 14 ঘন্টা আগে হয়েছিল,

8. ডাটাবেস ব্যাকআপগুলি নির্ভরযোগ্য বলে ধরে নেওয়া হয়; তাদের কঠোরভাবে পরীক্ষা করা হয়েছিল, সম্প্রতি সহ,

9. 14 ঘন্টা ডেটা হারানো গ্রহণযোগ্য নয়, তবে এক থেকে দুই ঘন্টা ডেটার ক্ষতি হ'ল,

10. মঞ্চ পরিবেশটি সর্বশেষে ছয় মাস আগে ব্যবহৃত হয়েছিল; দেখে মনে হচ্ছে এটি আপ টু ডেট নয় এবং এটি সেট আপ হতে কয়েক ঘন্টা সময় নিতে পারে,

11. ডাটাবেসটি মাইক্রোসফ্ট এসকিউএল সার্ভার ২০০৮ এন্টারপ্রাইজ।

জিনিসগুলি করার পরিষ্কার উপায় হ'ল:

1. মঞ্চ পরিবেশে ব্যাকআপ পুনরুদ্ধার করুন,

2. সেখানে পরীক্ষা,

3. চূড়ান্ত স্ক্রিপ্ট দুবার পরীক্ষা করুন,

4. প্রোডাকশন সার্ভারে স্ক্রিপ্টটি চালান।

আপনার প্রথম সংস্থার জন্য প্রথম পদক্ষেপের জন্য 18,000 ডলার খরচ হবে। যদি আপনি ত্রুটিহীনভাবে তৃতীয় পদক্ষেপটি করেন তবে ঝুঁকিটি খুব কম, তবে যেহেতু আপনি চরম চাপের মধ্যে কাজ করছেন, ঝুঁকিটি আরও বেশি হবে। আপনি কোনও স্ক্রিপ্ট দিয়ে শেষ করতে পারেন যা মঞ্চে পুরোপুরি ভাল কাজ করেছিল, তারপরে প্রোডাকশন ডাটাবেসটিকে স্ক্রু করবে।

পরিবর্তে, আপনি এটি করতে পারে:

1. একটি স্ন্যাপশট তৈরি করুন (মাইক্রোসফ্ট এসকিউএল সার্ভার এটি সমর্থন করে এবং এটি ডাটাবেসের স্ন্যাপশটকে ফিরিয়ে আনতে কয়েক সেকেন্ড সময় নেয়) যা ব্যাকআপ নিতে এক ঘন্টা সময় নেয়; আমি ধারণা করি যে অন্যান্য ডাটাবেস পণ্যগুলিও স্ন্যাপশটগুলিকে সমর্থন করে),

2. সরাসরি উত্পাদন ডাটাবেসে পরীক্ষা করুন, কিছু ভুল হয়ে গেলে স্ন্যাপশটে ফিরে যাওয়া।

যদিও একজন পিউরিস্ট তার ডাটাবেসটিকে একটি পরিষ্কার উপায়ে স্থির করে ফেলবেন এবং তার সংস্থার 20,000 ডলারের বেশি সময় নষ্ট করার সময় সময় চাপের সাথে জিনিসগুলি স্ক্রু করার ঝুঁকি রয়েছে, এমন এক ডাটাবেস অ্যাডমিনিস্ট্রেটর যিনি অ্যাকাউন্টে ব্যবসায়ের সীমাবদ্ধতাগুলি গ্রহণ করেন এটি একটি উপায়ে ডাটাবেস ঠিক করে দেবে যা দ্রুত এটি করার সময় ঝুঁকিগুলি হ্রাস করবে (স্ন্যাপশটগুলির জন্য ধন্যবাদ)।

উপসংহার

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

যদি কোনও আইটি লোক যদি কেবল পরিচ্ছন্নতার জন্য কাজগুলি পরিষ্কার করতে চায় তবে এটি সংস্থার জন্য কয়েক হাজার ডলার ক্ষতি করে, এই আইটি লোকটির তার কাজের একটি গভীর ভুল বোঝাবুঝি রয়েছে।

Comments

এবং সম্ভব হলে আপনার ব্যবসায়ের সময় বন্ধ করুন - যখন সত্যিকারের গ্রাহক কার্যকলাপ ন্যূনতম হয়

— ড্যান পিচেলম্যান

এমনকি যদি আপনার ডাটাবেসটি বড় হয় এবং এর ব্যাক আপ করতে অনেক সময় নেয়, আপনি সম্ভবত কেবলমাত্র সেই ডেটার একটি উপসেট নিতে পারেন এবং সেটির উপর পরীক্ষা করতে পারেন।

— রাদু মুর্জিয়া

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

— কোডকাস্টার

@ কোডকাস্টার: এটি দুঃখজনক, তবে আমি প্রায়শই এটি বড় সংস্থাগুলি সহ বাস্তবে দেখি।

— আর্সেনী মোরজেনকো

সম্ভবত, ব্যবসায়টি এই স্পষ্টতই অবতীর্ণ হয়েছে কারণ তারা সুযোগ পেলে মারজানের পোস্টে দেওয়া পরামর্শ অনুসরণ করেনি।

— এরিক কিং

Answer 3

নিরাপদে উত্পাদন ডেটাবেস ডেটা ঠিক করা। একটি বড় সংস্থার দৃষ্টিকোণ থেকে এটি সম্পর্কে নিরাপদতম উপায় কী? এমন কোন সরঞ্জাম রয়েছে যা সাহায্য করতে পারে?

এটি একটি খারাপ অনুশীলন এবং আরও ডেটা সমস্যা এবং সমস্যার জন্য একটি আমন্ত্রণ গেট। এমন একটি বাক্যাংশও রয়েছে যা এই পদ্ধতিকে " কুইক অ্যান্ড ডার্টি " হিসাবে বর্ণনা করে ।

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

তবে বাগগুলি সেখানে থাকবে এবং এটি ঠিক করা দরকার। ডি ফ্যাক্টো শিল্প মান একটি উপর প্যাচ / (স্থাপনার স্ক্রিপ্ট) প্রযোজ্য হয় স্টেজিং (শঙ্কু ডাটাবেসের সর্বশেষ কপি সঙ্গে প্রাক উৎপাদন পরিবেশ) এবং ডেটা বিশ্লেষক / QA তে ফিক্স যাচাই করতে দিন। সমস্যাগুলি এড়ানোর জন্য একই স্ক্রিপ্টটি সংস্করণটি নিয়ন্ত্রণ করা উচিত এবং উত্পাদন পরিবেশে প্রয়োগ করা উচিত ।

এই সম্পর্কিত পোস্টে বেশ কয়েকটি ভাল অভ্যাসের উল্লেখ রয়েছে - ডেটাবেজ ভাল অভ্যাসগুলি

দেখার জন্য উল্লেখের ভাল সেট হ'ল:

• আপনি কত দ্রুত উত্পাদনে একটি স্থির ত্রুটি পেতে পারেন?
• সফটওয়্যার ডেভলপমেন্ট ব্যয় পিরামিড
• টেস্টিং এবং বাগ ফিক্সিংয়ের জন্য কতটা সময় বরাদ্দ করা উচিত

Answer 4

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

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

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

প্রতিটি ব্যবসা অনন্য এবং কিছু ডেটা আপডেট করার ঝুঁকি অন্যদের তুলনায় স্পষ্টতই বেশি।

এই আপডেটগুলি করার জন্য লোকেদের ঝাঁপিয়ে পড়ে এমন একটি প্রক্রিয়া তৈরি করার মাধ্যমে, আশা করি আপনি এমন একটি সংস্কৃতি প্রচার করেছেন যা লোকেদের এটি একটি সর্বশেষ অবলম্বন হিসাবে বিবেচনা করতে এবং এই স্টাফের চারপাশে একটি স্বাস্থ্যকর "ডাবল চেক, ট্রিপল চেক" মনোভাব তৈরি করে।

Comments

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

— ওয়েইন এম

Answer 5

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

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

উত্পাদনের ডেটা পরিবর্তনের জন্য সমস্ত স্ক্রিপ্টগুলিতে নিম্নলিখিতটি অন্তর্ভুক্ত করা উচিত:

তাদের সুস্পষ্ট লেনদেন হতে হবে এবং একটি ট্রাই ক্যাচ ব্লক থাকা উচিত।

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

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

উত্পাদনে যেকোন কিছু পরিবর্তন করার জন্য সমস্ত স্ক্রিপ্টগুলি কোড পর্যালোচনা করে উত্স নিয়ন্ত্রণে রাখা হয়। তাদের সব - ব্যতিক্রম ছাড়া।

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

Answer 6

প্রোডাকশন ডাটাবেস চালাতে আমি অনেকবার ডেটা আপডেট করেছি। আমি উপরের উত্তরের সাথে একমত, এটি কখনও স্ট্যান্ডার্ড অপারেটিং পদ্ধতি হবে না।

এটি ব্যয়বহুলও হবে (আমরা প্রত্যেকের কাঁধে নজর দেব এবং সম্ভবত 2 বা 3 আলোচনা করব)

এবং সুবর্ণ নিয়ম: সর্বদা একটি আপডেট / ডিলিট / সন্নিবেশ বিবৃতি করার আগে কী হবে তা দেখানোর জন্য সর্বদা একটি নির্বাচনী বিবৃতি দিন

সোনার নিয়মটি প্রয়োগ করা হচ্ছে দলে থাকা অন্য দুই ব্যক্তি!

Answer 7

পুনঃ ময়নামার উত্তর ...

সফ্টওয়্যার প্রোডাক্টটিতে একটি ত্রুটি রয়েছে যার ফলে এটি কাজ করা বন্ধ করে দেয় যখন এটি ডেটাবেসে কিছু ডেটা অসঙ্গতি বলে মনে করে তা আবিষ্কার করে,

• আপনি কীভাবে জানবেন যে এটি একটি "বাগ"? সফ্টওয়্যার পণ্য বিকাশকারী নির্ধারিত নিয়ম অনুসারে ডেটা বেমানান।

সমস্ত বিকাশকারী যারা আবেদনের মধ্যে বাগটি সংশোধন করতে পারে তারা অ্যাক্সেসযোগ্য নয়,

সংস্থাটি বর্তমানে প্রতি ঘন্টা কয়েক হাজার ডলার হারাচ্ছে (ধরা যাক minute 6 000 ডলার, যার অর্থ প্রতি মিনিটে 100 ডলার),

• স্পষ্টতই 100 ডলার / মিনিটের ক্ষতি হ'ল সংস্থা ম্যানেজমেন্টের পক্ষে তাদের সনাক্ত করতে এবং বীমা করাতে সক্ষম করা যথেষ্ট নয় যে উপযুক্ত বিকাশকারীরা তাদের ভুলটি সংশোধন করতে এবং আপনাকে ডেটাবেস পুনরুদ্ধার করতে সহায়তা করে return

বাগটি বেশ কয়েকটি টেবিলকে প্রভাবিত করছে, এর মধ্যে একটি বিশাল এবং এটি শুধুমাত্র ডেটা নিয়ে উদ্বেগ প্রকাশ করে, স্কিমা নয়,

• সমস্ত ডাটাবেস সমস্যা স্কিমাকে "উদ্বেগ" করে। স্কিমা কীভাবে ডিজাইন করা হয়েছে তা হ'ল আপনি কীভাবে এই সমস্যার সমাধান করবেন তা নির্ধারণ করতে চলেছে।

বাগটি প্রতিরোধ করার জন্য আপনাকে ডেটা নিয়ে কিছুটা পরীক্ষা করা উচিত, যার মধ্যে এটি মুছে ফেলা এবং পরিবর্তন করা উভয়ই জড়িত,

• আপনার স্টেজিং ডাটাবেসের জন্য এটিই। আপনি সম্পূর্ণ সম্পূর্ণ অনলাইন ব্যাকআপ উত্পাদনের ব্যাকআপ নেওয়ার পরে আপনাকে প্রোডাকশন ডাটাবেস থেকে "দূষিত" ডেটা দিয়ে এটি পুনরায় তৈরি করতে হবে।

ডাটাবেসটি বড় এবং ব্যাকআপটি নিতে বা পুনরুদ্ধার করতে তিন ঘন্টা সময় লাগে,

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

শেষ পুরো ব্যাকআপটি তিন সপ্তাহ আগে নেওয়া হয়েছিল; এছাড়াও দৈনিক ইনক্রিমেন্টাল ব্যাকআপ রয়েছে এবং সর্বশেষ দৈনিক ইনক্রিমেন্টাল ব্যাকআপ 14 ঘন্টা আগে হয়েছিল,

• আপনার কমপক্ষে দৈনিক পূর্ণ অনলাইন ব্যাকআপ নেই? আপনি মাতাল. তবে আপনি সম্ভবত অভ্যস্ত। উপরে আপনি যে ভাল ব্যাকআপ শুরু করেছেন তা ভাল চলছে। প্রতিদিনের অনলাইন ব্যাকআপ সহ এড়ানো যেত এমন ব্যয়ের প্রতি মিনিটে ম্যানেজমেন্ট ট্র্যাক্টগুলি নিশ্চিত করুন।

ডাটাবেস ব্যাকআপগুলি নির্ভরযোগ্য বলে ধরে নেওয়া হয়; তাদের কঠোরভাবে পরীক্ষা করা হয়েছিল, সম্প্রতি সহ,

• অসাধারণ! তাহলে আপনাকে একাধিকবার ডাটাবেস পুনরুদ্ধার করতে হবে না।

14 ঘন্টা ডেটা হারানো গ্রহণযোগ্য নয়, তবে এক থেকে দুই ঘন্টা ডেটার ক্ষতি হ'ল,

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

মঞ্চ পরিবেশটি সর্বশেষে ছয় মাস আগে ব্যবহৃত হয়েছিল; দেখে মনে হচ্ছে এটি আপ টু ডেট নয় এবং এটি সেট আপ হতে কয়েক ঘন্টা সময় নিতে পারে,

• যদি আপনার ব্যাকআপ সিস্টেমটি অনলাইন ব্যাকআপগুলিকে সমর্থন করে (যেমন ব্যাকআপের সময় সম্পূর্ণ ডাটাবেসযুক্ত), তবে আপনার যদি ব্যাকআপটি কমে না যাওয়ার পক্ষে পর্যাপ্ত হার্ডওয়্যার সংস্থান থাকে তবে আপনি একই সময়ে স্টেজিং ডাটাবেসটিকে পুনরায় তৈরি করতে পারেন the

ডাটাবেসটি মাইক্রোসফ্ট এসকিউএল সার্ভার ২০০৮ এন্টারপ্রাইজ।

• এই সব করা কঠিন তবে অসম্ভব নয়। শুভকামনা!