ডাটাবেস 'মালিক' এর উদ্দেশ্য কী?

Question

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

মনে করা হয় এটির সাথে ডিল করার সর্বোত্তম অনুশীলন হ'ল ডাটাবেস মালিককে 'সা' তৈরি করা। আমরা এটি পরিবর্তন করেছি এবং এটি সারিটি সাফ করেছে।

আমার (খুব প্রাথমিক) প্রশ্ন: ডাটাবেসের মালিক কী এবং এর উদ্দেশ্য কী?

Comments

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

Answer 1

একদিকে 'dbo' (একটি ব্যবহারকারী) এবং 'db_owner' (একটি স্থির ভূমিকা) এর ডাটাবেস ধারণা এবং অন্যদিকে 'ডাটাবেস মালিক' এর উদাহরণ ধারণার মধ্যে কিছুটা বিভ্রান্তি আছে। 'Dbo' এবং 'db_owner' কে প্রায়শই 'ডাটাবেস মালিক' বলা হয়। আপনি যা জিজ্ঞাসা করছেন তাতে আপনি ডাটাবেসের মালিক হিসাবে সার্ভার অধ্যক্ষ হিসাবে ডাটাবেস মালিকের বিষয়ে কথা বলছেন।

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

যেহেতু ডাটাবেসটি একটি সার্ভার স্তরের সুরক্ষিত এটি অনুসরণ করে যে এটি ডিফল্টরূপে, প্রাথমিক অধ্যক্ষের মালিকানাধীন হবে যা ক্রিয়েট ডেটাবেসের বিবৃতি জারি করে। অর্থাৎ। প্রবাসী কর্মচারীর এনটি লগইন

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

মূল এনটি লগইনের মালিকানাধীন সুরক্ষামূলক (ডাটাবেস) তৈরির বিষয়ে ক্রেট ডাটাবেসের সামান্য পরিচিত পার্শ্বপ্রতিক্রিয়া এর আগেও অনেক পুড়ে গেছে। প্রতিটি সুরক্ষার জন্য নিয়ম একই, তবে কিছু কারণ DATABASE এর মালিককে ইস্যু করে:

• অন্যান্য সার্ভার স্তরের সিকিওরিবলগুলি (শেষ পয়েন্ট, সার্ভারের ভূমিকা, লগইন) খুব কম ব্যবহৃত হয়, প্রায় সরানো হয় ইত্যাদি are
• ডাটাবেস স্তরের সিকিওরিবলগুলি সাধারণত dbo(ডাটাবেস প্রিন্সিপাল), বা অন্য কোনও ডাটাবেস অধ্যক্ষের মালিকানাধীন হয়ে শেষ হয় এবং এইভাবে মালিক ডাটাবেসটিতে থাকে
• এনটি প্রাথমিক অধ্যক্ষের কাছে ডেটাবেস মালিকানার ডিফল্ট থাকা কন্টেন্ট ইস্যু তৈরি করে (মালিক এডি দ্বারা পরিচালিত একটি এনটি এসআইডি এবং ডেটাবেস ফাইলগুলির সাথে ভ্রমণ করেন না, এনটি অ্যাকাউন্ট থাম্বস্টোন করা যায় ইত্যাদি ইত্যাদি)
• সবচেয়ে গুরুত্বপূর্ণ বিষয়: ডাটাবেসের মালিক গুরুত্বপূর্ণ পার্শ্ব প্রতিক্রিয়া, বিশেষভাবে হয়েছে EXECUTE AS context। এই পরে সমস্যাটি বেশিরভাগ ব্যবহারকারীদের জ্বলিয়ে দেয়। সার্ভিস ব্রোকার যেহেতু এক্সিকিউটি এএস এর বিস্তৃত ব্যবহার করে (বার্তা সরবরাহের ক্ষেত্রে প্রসঙ্গ হিসাবে একটি বিস্মৃত এক্সকিউট রয়েছে, পাশাপাশি সারি ক্রিয়াকলাপ যা একটি স্পষ্ট একটি রয়েছে) সাধারণত পরিষেবা ব্রোকার ব্যবহারকারীরা প্রথমে এই সমস্যাটি আবিষ্কার করেন।

আপনার মূল সমস্যাটি তদন্ত এবং সমাধানের জন্য বিটিডাব্লু, কুডোস :)

Answer 2

ডাটাবেসটি ownerএসকিউএল সেভার 2005 সালে (যথাযথ) স্কিমা চালু হওয়ার আগে কিছুটা সময় নিক্ষেপ করেছিল।

মূলত একটি ডাটাবেস মালিক হ'ল ডাটাবেসের ডিফল্ট dbo(ডাটাবেস মালিক), ডাটাবেস নিজেই একটি ডাটাবেস অবজেক্ট হয় ।

থেকে SQL সার্ভার 2000 ডক্স ...

এটি dboএমন একজন ব্যবহারকারী যা ডেটাবেজে সমস্ত ক্রিয়াকলাপ সম্পাদনের অনুমতিকে বোঝায়।

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

সুতরাং, প্রযুক্তিগতভাবে এসকিউএল সার্ভারের পুরানো সংস্করণগুলিতে (বা আপগ্রেড করা ডেটাবেসগুলি) এটি "ফু" টেবিল ছিল না এটি ছিল "dbo.Foo" টেবিল ... dboমালিক হিসাবে।

এসকিউএল সার্ভার ২০০ 2005 এর আবির্ভাবের সাথে আপনার কাছে স্কিমার মালিকানাধীন ডাটাবেস অবজেক্ট থাকতে পারে যেমন আপনার কাছে "বার" নামে একটি স্কিমা এবং "ফু" নামক টেবিল রয়েছে ... এটি bar.Fooযেমন হয়ে যায় ...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

জটিল অংশটি এই সত্যটি নিয়ে আসে যে ব্যবহারকারী ডেটাবেস তৈরির ফলে স্বয়ংক্রিয়ভাবে মালিক হিসাবে সেট হয়ে যায় যা কর্মচারী প্রবর্তন ইত্যাদির ক্ষেত্রে সমস্যাগুলির দিকে পরিচালিত করে etc.

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

এই নিবন্ধটি প্রবীণ "মালিক" জিনিসগুলি করার পদ্ধতি এবং নতুন "স্কিমা" ভিত্তিক মালিকানা সিস্টেমের মধ্যে পার্থক্যকে বিচ্ছিন্ন করে।

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

Comments

@ রেমাসরুসানু, 'স্কিমা বনাম মালিক' উদাহরণটি ব্যবহার করা কেবল এসকিউএল সার্ভারে কোনও 'মালিক' কেন অন্তর্নিহিত তা সম্পর্কে ধারণাটি বোঝানোর একটি উপায় ছিল। আমি আপনার উত্তর প্রশংসা করি! ঠিক আছে ... তবে আমি বিশ্বাস করি না "সুতরাং অতএব" এই উদাহরণটি / উত্তরকে হ্রাস করে। :)

— জাস্টিন জেনকিনস