img

نقش تغییر دهنده مدیر پایگاه اطلاعاتی

/
/
/

بیش از ده ها سال از زمانی که سیستم مدیریت پایگاه اطلاعاتی (DBMS) به شکل یک تکنولوژی روزمره درآمده می گذرد و نقش مدیر پایگاه اطلاعاتی(DBA) به طور چشمگیری تغییر کرده است. اپلیکیشن ها و محیط های عملیاتی بسیار پیچیده تر شده اند و کاهش تعداد کارمندان یک سازمان و برون سپاری ها(اوت سورسینگ) حاکی از آن است که افراد کمتری مشغول انجام این کار هستند.
کمی درباره تاریخچه سیستم مدیریت پایگاه اطلاعاتی (DBMS)
وقتی DBMS رابطه ای اولین بار در سال ۱۹۸۰ معرفی شد، بسیاری از شرکت های بزرگ و متوسط دارای مین فریم (یا کامپیوتر بزرگ) IBM بودند که DB2 و دیگر محصولات قانونی DBMS را اجرا می کردند. سازمان های دیگر دارای سیستم های “میدرنج” (یا کامپیوترهای متوسط) بودند که اوراکل یا DBMS های روز را اجرا می کردند. (میدرنج را در داخل کوتیشن قرار دادیم چون امروزه این سیستم ها به اندازه یک مین فریم متوسط و یا حتی بیشتر از آن قدرتمند هستند). DBMS های دیگر همچون سیستم های مبتنی بر یونیکس و اینتل قدرت و محبوبیت خاصی پیدا کردند.

محیط DBMS امروزی
امروزه، اکثر کمپانی ها از دو یا چند DBMS برای انجام کارهای شرکتی خود در انواع محیط های عملیاتی استفاده می کنند. جدول زیر بسیاری از این اپلیکیشن ها و محیط ها را نشان میدهد.
تمام DBMSهای اصلی از اپلیکیشن های تجاری پشتیبانی می کنند که به دسترسی بالا، هزاران کاربر و پایگاه های اطلاعاتی بسیار بزرگ (اغلب در اندازه ترابایت) نیاز دارند. با وجود این که فروشندگان ممکن است دلایل فنی مجاب کننده ای برای تغییر DBMS موجود به یک DBMS متفاوت ارائه دهند، اما اکثر این تصمیمات به دلیل بهره وری و هزینه ها گرفته می شود. وقتی بحث پلت فرم ها یا سیستم عامل ها یا نرم افزارهای حمایتی به میان می آید، همین بحث دوباره مطرح می شود. در صورت استفاده از دو یا چند DBMS ، می توان از ابزارهای کراس- پلت فرم که یک رابط کاربر پایدار جهت راحتی اجرا و کاهش منحنی یادگیری ارائه می دهند، بهره گرفت . Embarcadero یک گزینه معروف برای محیط های غیر یکنواخت است.
در حال حاضر موضوعات داغ، ماشین های پایگاه اطلاعاتی همچون Exadata اوراکل و Neteza و PureSystems شرکت آی بی ام و بیگ دیتا یا کلان داده هستند. این محصولات طراحی ساده شده و اجرا را ارتقاء می بخشند، بنابراین مدیر پایگاه اطلاعاتی برای مدیریت به زمان زیادی نیاز ندارد. این محصولات دارای حافظه زیادی برای اسکن سریع داده ها هستند و نیازی به شاخص ندارند. البته شاخص ها برای پشتیبانی از کلید اصلی لازمند و همینطور ماشین های پایگاه اطلاعاتی مناسب حجم های کاری عملیاتی نیستند.
بیگ دیتا از نمایش ستونی داده ها استفاده می کند و مبتنی بر Hadoop و دیگر محصولات منابع آزاد است. فروشندگان این قابلیت ها را افزوده اند و پشتیبانی می کنند.

تاریخچه معروفیت DBMS
محصولات جدید، منبع اصلی در آمد تبلیغاتی رسانه ها را تشکیل می دهند. توصیه ها و نکاتی که در خصوص استفاده بهتر از تکنولوژی موجود ارائه می شود بسیار ارزشمندند اما اغلب از دید تبلیغ کنندگان پنهان می مانند.
بسیاری از DBMهایی که در سال های ۱۹۸۰ معرفی شدند هنوز هم وجود دارند. ویژگی های جدید به صورت یک مجموعه گردهم آمده اند. خط زمانی زیر برخی از رویدادهای بزرگ را که طی سی سال گذشته در مورد DBMS های رابطه ای رخ داده اند، نشان می دهد.
رویدادهای اواسط دهه ۱۹۸۰ نشان می دهند که محصولات چقدر مورد توجه قرار گرفته اند.
اکتبر ۱۹۸۵: دوازده قانون پایگاه اطلاعاتی رابطه ای دکتر E.F.Codd منتشر شد. این مقاله منجر به بحث و مناظره بین دکتر Codd و یک فروشنده سرشناس گردید و درنهایت در سال ۱۹۸۹ به شرکت CA فروخته شد.
۱۹۸۷ : که “سال پایگاه اطلاعاتی رابطه ی” معرفی شد. در پایان سال ۱۹۸۷ مجبور بودیم تمام اپلیکیشن ها را به RDBMS تبدیل کنیم یا اینکه طرح هایی را تنظیم کنیم تا این فرآیند طی ۵ سال کامل شود.
۱۹۸۸ : که “سال پایکاه اطلاعاتی توزیع شده” معرفی شد. در پایان سال ۱۹۸۸، ما مجبور بودیم تمام اپلیکیشن ها را برای استفاده از تکنولوژی توزیع شده تبدیل کنیم یا طرح هایی را برای تکمیل این فرآیند در ۵ سال تنظیم کنیم.
امروزه، تکنولوژی پایگاه های اطلاعاتی اساساً رابطه ای است، اما اکثر سازمان های بزرگ هنوز هم اپلیکیشن های به ارث رسیده ای دارند که بخش های مهم تجارت آن ها را انجام می دهند. پایگاه اطلاعاتی توزیع شده امروزه در جاهایی استفاده می شود که قابل فهم و منطقی هستند، اما پذیرش و حمایت فروشندگان در مقایسه با چهارچوب زمانی که در سال ۱۹۸۸ پیش بینی می شد، کندتر است.
در طی این سال ها، بحث هایی در مورد DBMS بعدی مطرح شد. صحبت از DBMS شی گرا به عنوان DBMS بعدی بود. در عوض، ویژگی های جدیدی مثل آبجکت های بزرگ(LOBs) و XML در محصولات رابطه ای موجود گنجانده شده اند. این ویژگی ها توسط هر کمپانی استفاده نمی شوند، بلکه هنگام طراحی اپلکیشن های جدید، گزینه های بیشتری را ارائه می دهند.
چالش های مدیر پایگاه اطلاعاتی
وقتی RDBMS ها در سال های ۱۹۸۰ معرفی شدند، عنوان شده بود که DBMهای رابطه ای آنقدر ساده هستند که مدیر پایگاه اطلاعاتی کار زیادی برای انجام دادن ندارد. تعریف و طراحی داده ها ساده بودند! خب این یعنی اینکه مدیران پایگاه اطلاعاتی زمان بیشتری برای کار کردن روی مسائل اپلیکیشن داشتند و به کار نزدیکتر بودند.
تقریبا تمام سازمان ها چندین DBMS دارند که باید آن ها را مدیریت کنند، چه محصولات به ارث رسیده باشند، چه استراتژیک یا خریداری شده برای یک اپلیکیشن خاص یا برای مصارف اداری. این محصولات ممکن است بدون مشورت با مدیر پایگاه اطلاعاتی یا دیگر حوزه های فنی، خریداری شوند. اما پشتیبانی لازم و ضروریست. با بودجه های فعلی، ممکن است آموزش به راحتی میسر نباشد.
البته مسائل قدیمی مدیریت اجرا و بازیابی هنوز هم در RDBMS وجود دارند، امکانات اضافه شده در DBMS پیشرفت کرده است و بسیاری از محصولات فروشی به عنوان راه حل های مسائل مختلف عرضه می شوند. DBMS رابطه ای براساس اندازه و پیچیدگی محیط، ابزارهای جدیدی را در نظر می گرفت و فروشندگان آن ها را به یک صنعت چند بیلیون دلاری تبدیل می کردند.
مدیریت زمان و برنامه، چالش های روزمره یک مدیر پایگاه اطلاعاتی هستند. در مواقع اضطراری، حتی فعالیت هایی که به دقت طرح ریزی شده اند به تاخیر می افتند. اولویت بندی در یک فروشگاه شلوغ بسیار مهم است. اغلب زمان کافی برای کارهای وقت گیری همچون تنظیم عملکرد، بررسی طراحی و برنامه ریزی برای بازیابی وجود ندارد. اغلب این مسائل به تاخیر می افتند تا زمانی که به یک نقطه بحرانی می رسند.
حال ما Exadata، Netezza و Teradata و دیگران را داریم که تبلیغات صورت گرفته پیرامون آن ها نشان می دهند که نیازی به تنظیم عملکرد ندارند. با وجود فشار کاری زیاد برای انجام کار بیشتر با کارمندان کمتر و همچنین برون سپاری ها، مدیران پایگاه اطلاعاتی چگونه باید از کارشان دفاع کنند؟ حال نگاهی می اندازیم به آنچه مدیران پایگاه اطلاعاتی باید انجام دهند.
فعالیت های اصلی مدیران پایگاه اطلاعاتی
لیست فعالیت های اصلی یک مدیر پایگاه اطلاعاتی در قالب کارهای لازم یک شرکت ممکن است ترسناک به نظر برسد. براساس زمان داده شده در طول یک روز، برخی فعالیت ها مثل تنظیم عملکرد، ممکن است کل روز طول بکشد و یا اینکه ممکن است بتاخیر بیافتد تا اینکه یک مشکل یا بحران رخ دهد. اولویت کارهای روزانه یک مدیر پایگاه اطلاعاتی معمولی از این قرار است :
۱- اطمینان از قابلیت دسترسی
۲- انجام کارهای مربوط به حفظ و نگهداری در صورت نیاز
۳- هماهنگی در توسعه
۴- پشتیبانی از تولید
۵- بازیابی در زمان لازم
۶- تنظیم عملکرد و انجام کارهای دیگر در صورت داشتن وقت
دسترسی مهم است و نظارت و چاره سازی هم باید در مواقع ضروری انجام شود. کارهایی که برای حفظ و نگهداری روزانه جهت حمایت از قابلیت دسترسی انجام می شود، بررسی وضعیت پشتیبان گیری ها، اطمینان از این مسئله که هیچکدام از آبجکت های پایگاه اطلاعاتی در وضعیت استثنایی نباشند ، بررسی یوتیلیتی ها و اطلاعات دیگر مربوط به وضعیت پایگاه اطلاعاتی. مدیر پایگاه اطلاعاتی فعالیت های بعدی حفظ و نگهداری را طرح ریزی و زمانبندی می کند.
همکاری در توسعه شامل ساخت و تغییر تعریف آبجکت ها و مهاجرت آبجکت ها بین محیط های آزمایشی از جمله توسعه اسکریپت های مهاجرت می باشد. محیط های آزمایشی باید ساخته و مدیریت و در صورت نیاز بازگردانده شوند. در صورت داشتن زمان، بررسی طراحی و کمک به برنامه نویسی SQL نیز از جمله کارهای مدیر پایگاه اطلاعاتی محسوب می شود.
دو وظیفه مهم مدیر پایگاه اطلاعاتی که گه گاه مورد نیاز واقع می شود، تنظیم عملکرد و بازیابی است. بازیابی بعد از خرابی یا خطا مهارت اصلی هر مدیر پایگاه اطلاعاتی محسوب می گردد.
تنظیم عملکرد حوزه های متفاوتی را شامل می شود، از تنظیم پارامترهای پایگاه اطلاعاتی گرفته تا تنظیم SQL و شاخص ها. گرچه تنظیمات اغلب به تاخیر می افتند، اما بازیابی و تنظیم عملکرد و اجرا، این شانس را به مدیر پایگاه اطلاعاتی می دهد که بدرخشد و به عنوان یک قهرمان شناخته شود.
می خواهید جزء کدام یک از قهرمان های DBA باشید؟
معمولا مشکلاتی که رخ می دهند به اجرا و بازیابی مربوط می شوند. بسیاری از این مشکلات برای مدیران رده بالا قابل رویت هستند و اگر شما موفق به حل این مشکلات شوید، به چشم یک قهرمان به شما نگاه خواهد شد.

اجرا
قهرمان های اجرا باعث می شوند کارها سریع تر پیش برود. اگر اپلیکیشن جدید کند است، احتمالا بلااستفاده باقی می ماند تا زمانی که در هفته های اول تولید تنظیماتی روی آن صورت بگیرد. اگر اپلیکیشن موجود کند باشد، اولین سوالی که مطرح می شود این است که چه چیزی تغییر می کند؟ با وجود اینکه فشار زمانی همیشه وجود دارد، ابزارهای تنظیم کننده همانند Embarcadero DB Optimizer می توانند با تعریف گلوگاه ها، تجزیه و تحلیل کردن زمان انتظار، ارائه پیشنهادات و شبیه سازی حجم کارهای تولید، این فرآیند را ساده تر کنند. فرآیند تنظیم میتواند از چند دقیقه تا چند روز طول بکشد، اما وقتی همه چیز سرجای خودش قرار گرفت، جایگاه شما به عنوان یک قهرمان تثبیت می شود.

بازیابی
قهرمان بازیابی باید کاری کند که سیستم های تولید پس از یک خرابی، بالا بیایند و در صورت امکان هرچه سریع تر کار کنند. زمان بازیابی براساس نوع خرابی، ماهیت بازیابی و وضعیت آمادگی تعیین می شود.
برخی بازیابی ها فقط چندثانیه یا چند دقیقه طول می کشند. بازیابی ها ممکن است شامل Reset کردن تغییر نادرست یک پارامتر یا خنثی کردن عمل های کوچک دیگری از این قبیل باشند. طبیعتاً فرد مسئول می گوید “متاسفم” ولی مدیریت باید به او تذکر دهد که این کار مجددا تکرار نشود.
بسیاری از بازیابی ها مستلزم مدت زمان بیشتری هستند، گاهی به دلیل خرابی سخت افزاری، خرابی نرم افزاری یا خطای عملیاتی این بازیابی ۲ تا ۶ ساعت طول می کشد. در تولید، زمانی که شما مشغول بازیابی هستید افراد منتظر می مانند و شما را تماشا می کنند و هرگونه تاخیری مشکل را بدتر می کند.
در موارد نادر، بازیابی ممکن است بیش از چند ساعت طول بکشد. فاکتورهایی نظیر: برگرداندن میلیون ها سطر از یک عمل SQL، مشکل پیش آمده در خصوص پشتیبان گیری، تغییر مسائل مدیریتی و غیره می توانند برخی از دلایل این بازیابی های طولانی باشند. قهرمان بازیابی باید ۲۴ ساعته کار کند و حتی به منزل هم نرود و تنها زمانی می تواند میز خود را ترک کند که سیستم پشتیبانی شود. در پایان بازیابی، مدیریت آنقدر تحت تاثیر کار قرار گرفته که بندرت به دنبال علت اصلی مشگل می گردد.
مهارت های فنی گذرا و منسوخ شدنی هستند بخصوص مهارت های بازیابی که مبتنی بر پیچیدگی هایشان می باشد. قبل از هرگونه بازیابی تولید، انجام آزمایشات و تمرین های بازیابی ضروریست. در دنیای واقعی ممکن است بازیابی مورد نیاز متفاوت از بازیابی های آزمایشی باشد، اما بدون داشتن تجربه این کار ممکن است مدت زمان بیشتری طول بکشد.

تغییر در نحوه استخدام و گزینش (Staffing)
طی ۳۰ سال گذشته میزان استخدام ها به شکل چشمگیری کاهش یافته است وقتی DB2 اولین بار معرفی شد و تعداد پروژه های توسعه ای داخل سازمانی بیشتر گردید، برخی سازمان ها به ازای هر ۱۰ توسعه دهنده یک مدیر پایگاه اطلاعاتی داشتند. در اواسط سال های ۱۹۹۰ این تعداد به ازای هر ۱۰۰ توسعه دهنده ، یک مدیر پایگاه اطلاعاتی تغییر کرد. از آنجائیکه پشتیبانی تولید هنوز هم باید انجام بگیرد، باید گفت زمان زیادی برای انجام فعالیت هایی نظیر بررسی طراحی باقی نمی ماند.

بخشی از راهکار؟
مدیران پایگاه اطلاعاتی در تمام بخش های اداری کار می کنند تا فعالیت های مرتبط با پایگاه اطلاعاتی را هماهنگ کنند و اغلب مسائلی را مخاطب قرار می دهند که توسط تیم های کاربردی همچون بازیابی، امنیت و عملیاتی نادیده گرفته می شوند. مدیر پایگاه اطلاعاتی مسئول پشتیبانی تولید یک اپلیکیشن با طراحی ضعیف است. و همین باعث شده تا مدیران پایگاه اطلاعاتی در یک موقعیت پرمخاطره قرار بگیرند، آن ها ممکن است برای تغییرات در یک اپلیکیشن بجنگند در حالی که تیم توسعه فشار زمانی خودشان را دارند تا اپلیکیشن مطابق برنامه به مرحله تولید برسد. گاهی اوقات مدیران پایگاه اطلاعاتی همانند یک سد در مقابل ارائه یک ویژگی جدید می ایستند. آیا گروه مدیران پایگاه اطلاعاتی میتوانند مانع رسیدن یک اپلیکیشن با طراحی ضعیف به مرحله تولید شوند؟
مدیران پایگاه اطلاعاتی نقش تکنیکی بالایی دارند که مستلزم حضور در بحث ها، کنفرانس ها و در گروه کاربران است تا اطلاعات موجود و جدید را جمع آوری کنند. این آموزش ارزان نیست.
البته ابزارهای لازم برای اجرا، مدیریت و بازاریابی و غیره هم ارزان نیستند. آموزش های چند جانبه برای پلت فرم های جدید هم باید در نظر گرفته شوند. در نتیجه کنفرانس های مجازی و سیمنارهای اینترنتی به همین منظور بسیار متداول شده اند.
از آنجائیکه سازمان ها بدنبال کاهش هزینه های IT هستند، آموزش جزء اولین چیزهاییست که احتمال حذف آن وجود دارد. همچنین وقت آن رسیده تا بر روی ابزارهای مربوط به بهره وری پایگاه های اطلاعاتی سرمایه گذاری کنیم، ابزارهایی که از چندین پلت فرم پشتیبانی می کنند.
برون سپاری و ابر
برونسپاری یا اوت سورسینگ در واقع تایید این موضوع است که هزینه های IT بسیار بالاست و برای شرکت هایی که اینکار را انجام می دهند، دیگر مزیت استراتژیکی ندارد. پس از عقد قرارداد، عملیات و برنامه نویسی سیستم توسط شرکتی که برون سپاری به آن واگذار شده، انجام می گیرد. مدیر پایگاه اطلاعاتی می تواند بخشی از این قرارداد برون سپاری باشد و یا اینکه نباشد.
شرکت های خوبی وجود دارند که کار برون سپاری را انجام می دهند و قراردادهای آن ها شامل چهارچوب زمانی برای ارتقاء به نسخه های جدید، کارمندانی که طراحی و تنظیمات اولیه را انجام می دهند و پیشروی دائمی فرایند کار برای مشتریان است. کارمندان شرکت هایی که بخشی از کارشان را به شرکت های شخص ثالث واگذار می کنند، کار زیادی برای انجام دادن ندارند و این فرصت را در اختیار دارند تا در طرح های آموزشی و کنفرانس ها حضور پیدا کنند.
Cloud در واقع پیشکشی از سوی دفاتر خدماتی با قابلیت دسترسی بالاست: آنچه نیاز دارید را با پکیج های نرم افزاری و سخت افزاری استاندارد خریداری کنید. در سال های ۱۹۷۰ منابع مین فرم مشترک معرفی شدند و در سال های ۱۹۹۰ برون سپاری با سخت افزار خصوصی و افراد مشترک ارائه شد و در حال حاضر ما هر دو را با هم داریم.
صرف نظر از Cloud یا همان برون سپاری ها، داشتن افراد تکنیکی برای نظارت بر اجرا و همچنین کسی که بتواند بازیابی محیط را درک کند، مطلوب و لازم بنظر می رسد.

خلاصه
نقش مدیر پایگاه اطلاعاتی یا همان DBA همچنان در شرکت ها احساس می شود. افرادی باید باشند که داده ها را بفهمند، ذخیره سازی داده ها را براساس نیازهای کاری طراحی کنند، عملیات را پشتیبانی نمایند، مدیریت امنیت و تغییر را عهده دار باشد، پشتیبان گیری و بازیابی و اجرای DBMS را هم مدیریت نمایند. تکنولوژی رابطه ای در هماهنگ سازی ایده ها و امکانات جدید بسیار موثر است و اگر برخی از تکنولوژی های جدید از تکنولوژی رابطه ای حذف شوند، چیزی به سرعت جای آن ها را نمی گیرد. برای متعادل کردن اثرات افزایش پلت فرم های بیشتر و کاهش سرشماری، ابزارهای اجرایی و مدیریتی کراس پلت فرم می توانند باعث بهبود بهره وری و کاهش خطاها و کاهش زمان آموزش پلت فرم های جدید شوند.

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text