استعادة قواعد بيانات MySQL باستخدام الطرق اليدوية و"الميكانيكية". استعادة قاعدة البيانات

15.06.2019

ويبدو أن ما نشرته الأسبوع الماضي قد أثار بعض الاهتمام، لكنه، للأسف، لم يكن يحتوي على "ممارسة". نعم، يقول كيف يمكنك حفظ البيانات، ولكن لا توجد أمثلة.
في البداية، أردت أن أقوم بترجمة أخرى لنفس المؤلف، لكن بعد التفكير في الأمر، قررت أن أكتب تدوينة "بمفردي"، كما لو كانت "مبنية عليها". سأصف الأسباب التي دفعتني للقيام بذلك في نهاية المنشور في الملاحظات.

استعادة قواعد البيانات في SQL Server

كما ذكرنا في المقالة السابقة، في حالة تلف صفحات الفهرس المجمع أو الكومة، يتم فقدان البيانات الموجودة في هذه الصفحات والخيار الوحيد لاستعادتها هو استعادة قاعدة البيانات مباشرة.

يوفر SQL Server العديد من الخيارات لاستعادة قاعدة البيانات. أولا، هذه هي استعادة قاعدة البيانات بأكملها - قد يستغرق الأمر الكثير من الوقت (اعتمادا على حجم قاعدة البيانات وسرعة محركات الأقراص الثابتة). ثانيًا، استرداد مجموعات الملفات الفردية، أو الملفات إذا كانت قاعدة البيانات الخاصة بك تتكون من عدة مجموعات ملفات (أو ملفات على التوالي). في هذه الحالة، من الممكن استعادة الأجزاء التالفة فقط من قاعدة البيانات دون التأثير على الباقي. يتم استخدام هذين النوعين من استرداد قاعدة البيانات في كثير من الأحيان ولن تتم مناقشتهما بشكل أكبر.
ثالثا، في SQL Server 2005، أصبح من الممكن استعادة صفحات قاعدة البيانات الفردية - في هذه الحالة، سيتم استعادة الصفحات المحددة فقط من النسخة الاحتياطية. سيكون هذا الاسترداد مهمًا بشكل خاص إذا عثر DBCC CHECKDB على عدة صفحات تالفة في بعض الجداول الضخمة "الكذب" في ملف ضخم. نظرًا لحقيقة أنه لن يتم استعادة الملف بأكمله، ولا حتى الجدول بأكمله، ولكن سيتم استعادة بضع صفحات فقط، يمكن تقليل وقت التوقف عن العمل بشكل كبير.

المتطلبات والقيود

نموذج الاسترداد وتوافر النسخ الاحتياطية لسجل المعاملات

أهم شيء يجب تذكره هو أنه لاستعادة الصفحات الفردية، يجب أن تستخدم قاعدة البيانات نموذج استرداد كامل أو مُسجل بشكل مجمّع. إذا كانت قواعد البيانات الخاصة بك في نموذج استرداد بسيط، فلن تضطر إلى قراءة المزيد.
الشرط الثاني هو أن النسخ الاحتياطية الكاملة وسجلات المعاملات الخاصة بك يجب أن تشكل سلسلة سجل غير منقطعة. إذا لم تقم مطلقًا بإصدار الأمر BACKUP LOG With TRUNCATE_ONLY (NO_LOG) ولم تقم بالتبديل إلى نموذج الاسترداد البسيط لتقليل سجل المعاملات، وكان لديك جميع النسخ الاحتياطية لسجل المعاملات منذ آخر نسخة احتياطية كاملة لا تحتوي على صفحات تالفة (بما في ذلك هذه النسخة الاحتياطية الأكثر اكتمالا) - لا داعي للقلق بشأن سلسلة السجل.
في نموذج الاسترداد المجمع، من الناحية النظرية، يجب أن تعمل عملية استرداد الصفحات الفردية بشكل جيد طالما تم استيفاء الشروط الموضحة أعلاه ولم يتم تعديل الصفحات التي يتم استردادها من خلال عمليات التسجيل المجرد.

إصدارات SQL Server

يمكن استعادة الصفحات في أي إصدار من SQL Server، ولكن بالنسبة لإصدار Enterprise وإصدار المطورين، من الممكن استعادة الصفحات التالفة عبر الإنترنت، أي. يمكن الوصول إلى قاعدة البيانات أثناء الاسترداد (وعلاوة على ذلك، يمكنك حتى الوصول إلى الجدول الذي تنتمي إليه الصفحات التي يتم استعادتها حاليًا، إذا لم يتم "لمس" هذه الصفحات نفسها - وإلا فسيفشل الطلب مع وجود خطأ). بالنسبة للإصدارات "الأقل من" Enterprise Edition، تتم استعادة الصفحة دون الاتصال بالإنترنت وتصبح قاعدة البيانات غير قابلة للوصول أثناء فترة الاستعادة.

نوع الصفحة التالفة

في حالة تلف صفحات الفهرس أو البيانات، يمكن استعادتها عبر الإنترنت في Enterprise Edition.
يمكن استعادة الصفحات التي تنتمي إلى جداول النظام الهامة، ولكن قاعدة البيانات، عند استعادتها، لن تكون متاحة في أي إصدار من SQL Server.
لا يمكن استعادة "بطاقات التنسيب" "بشكل منفصل". في حالة تلف صفحات GAM وSGAM وPFS وML وDIFF، فمن الضروري استعادة قاعدة البيانات بأكملها. الاستثناء الوحيد هو صفحات IAM. وعلى الرغم من تصنيفها على أنها "خرائط مواقع"، إلا أنها تصف جدولًا واحدًا فقط، وليس قاعدة البيانات بأكملها، ويمكن استعادتها.
لا يمكن استعادة صفحة تحميل قاعدة البيانات (الصفحة التاسعة في ملف قاعدة البيانات الأول) وصفحة رأس الملف (الصفحة 0 في كل ملف) "بشكل منفصل"؛

في الواقع، استعادة

والآن، أخيرًا، ننتقل من النظرية إلى التطبيق.
بادئ ذي بدء، للتدريب، تحتاج إلى قاعدة بيانات تالفة.

نقل قاعدة البيانات

بالنسبة لتجاربي، سأستخدم قاعدة بيانات AdventureWorks التي تأتي مع SQL Server. إذا لم تقم بتثبيته، يمكنك تنزيله إذا كنت ترغب في ذلك. أقوم بترجمته إلى نموذج الاسترداد الكامل:
تغيير قاعدة بيانات AdventureWorks SET RECOVERY FULL أتأكد من عدم وجود أخطاء فيها حتى الآن:
DBCC CHECKDB("AdventureWorks") مع NO_INFOMSGS وALL_ERRORMSGS وDATA_PURITY وإنشاء نسخة احتياطية كاملة:
قاعدة بيانات النسخ الاحتياطي AdventureWorks إلى القرص = "D:\tmp\aw_backups\aw_full_ok1.bak"

في قاعدة البيانات هذه أقوم بإنشاء جدول الأعطال.
تعطل إنشاء جدول (txt varchar(1000)) سنقوم بإتلاف حقل نوع varchar للتحقق مما سيحدث إذا وجد SQL Server فجأة بيانات تختلف عن ما كتبه هناك.
قبل أن تفسد شيئًا ما، عليك أن تملأه بشيء ما. أقوم بإدخال البيانات اليسرى في الجدول الذي تم إنشاؤه.
قم بتعيين NOCOUNT على DECLARE @i INT SET @i = 1 بينما @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
سجل النسخ الاحتياطي AdventureWorks على القرص = "D:\tmp\aw_backups\aw_log_ok1.trn"

الآن دعونا نغير البيانات قليلاً:

لذلك، كل شيء جاهز. نقوم بفصل قاعدة البيانات ونفتح ملف mdf باستخدام FAR (أو ما هو أكثر ملاءمة لك)، ونبحث عن السطر "zzzzzzz" فيه ونستبدل العديد من "z" بأحرف عشوائية:

الآن بعد أن أصبحت قاعدة البيانات تالفة، نقوم بتوصيلها. ونعم، أتذكر أنه في المقالة السابقة تم النص بوضوح على أنه لا ينبغي عليك فصل/إرفاق قاعدة البيانات. ولكن في حالتنا فهو "آمن" تمامًا - لن تسقط قاعدة البيانات في الحالة "المشتبه بها".

تبحث عن الأخطاء

وبذلك، عادت قاعدة البيانات التالفة إلى الخدمة بنجاح. لنجري فحص النزاهة مرة أخرى:
DBCC CHECKDB("AdventureWorks") مع NO_INFOMSGS، ALL_ERRORMSGS، DATA_PURITY والنتيجة هي ما كنا ننتظره ( تأكد من تذكر عدد الصفحات التالفة!):

Msg 8928، المستوى 16، الحالة 1، السطر 1
معرف الكائن 1883153754، معرف الفهرس 0، معرف القسم 72057594054246400، معرف وحدة التخصيص 72057594061651968 (اكتب البيانات في الصف): تعذرت معالجة الصفحة (1:20455). راجع الأخطاء الأخرى للحصول على التفاصيل.
Msg 8939، المستوى 16، الحالة 98، السطر 1
خطأ في الجدول: معرف الكائن 1883153754، معرف الفهرس 0، معرف القسم 72057594054246400، معرف الوحدة المخصصة 72057594061651968 (اكتب البيانات في الصف)، الصفحة (1:20455). فشل الاختبار (IS_OFF (BUF_IOERR, pBUF->bstat))). القيم هي 29493257 و -4.
عثر CHECKDB على 0 أخطاء في التخصيص وخطأين في التناسق في الجدول "تعطل" (معرف الكائن 1883153754).
عثر CHECKDB على 0 أخطاء تخصيص و2 أخطاء تناسق في قاعدة البيانات "AdventureWorks".
يعتبر Repair_allow_data_loss هو الحد الأدنى لمستوى الإصلاح للأخطاء التي تم العثور عليها بواسطة DBCC CHECKDB (AdventureWorks).
في هذه الحالة، تكون البيانات نفسها الموجودة في الكومة (معرف الفهرس = 0) تالفة، لذلك لن يتمكن SQL Server من استرداد هذه البيانات.
الآن لدينا ثلاثة خيارات:

اقبل فقدان البيانات وقم بتشغيل DBCC CHECKDB("AdventureWorks"، REPAIR_ALLOW_DATA_LOSS)
قم بعمل نسخة احتياطية للجزء النشط من سجل المعاملات واستعادة قاعدة البيانات بأكملها - لن يكون هناك فقدان للبيانات نتيجة لذلك، ولكن الأمر سيستغرق وقتًا طويلاً
قم بعمل نسخة احتياطية من الجزء النشط من سجل المعاملات واستعادة صفحة واحدة فقط (!) تالفة

مع الخيار الثاني، يجب أن يكون كل شيء واضحا، لكنني سأوضح ما يحدث إذا قمت بتشغيل DBCC CHECKDB أو كيفية استعادة الصفحات الفردية.

استعادة الصفحة التالفة

أولاً، نحتاج إلى عمل نسخة احتياطية للجزء الأخير من سجل المعاملات (النسخ الاحتياطي الخلفي). في الوقت نفسه، إذا كان لديك إصدار Enterprise، فلن يتعين عليك إضافة معلمة NORECOVERY، والتي ستضع قاعدة البيانات في حالة "الاستعادة"، نظرًا لأن هذا الإصدار يدعم استعادة الصفحات عبر الإنترنت. علاوة على ذلك، إذا كان لديك نسخ احتياطية لسجل المعاملات يتم إجراؤها بشكل منتظم، حتى لا يتم كسر سلسلة السجل، في Enterprise Edition، يمكنك عمل نسخة احتياطية COPY_ONLY.
أتبع مسار الاسترداد دون الاتصال بالإنترنت وأقوم بما يلي:
سجل النسخ الاحتياطي AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" مع NORECOVERY

الآن، يمكنك استعادة الصفحة التالفة. أولاً، نستخدم نسخة احتياطية كاملة (aw_full_ok1.bak):

استعادة صفحة قاعدة بيانات AdventureWorks = "1:20455" من القرص = "D:\tmp\aw_backups\aw_full_ok1.bak" مع NORECOVERY
ونتيجة لذلك، لدينا:

يرجى ملاحظة أنك بحاجة إلى استخدام خيار NORECOVERY، حيث لا يزال يتعين علينا إنشاء نسخ احتياطية لسجل المعاملات عليه.
استعادة سجل AdventureWorks من القرص = "D:\tmp\aw_backups\aw_log_ok1.trn" مع NORECOVERY و
استعادة سجل AdventureWorks من القرص = "D:\tmp\aw_backups\aw_log_fail3.trn" مع الاسترداد

يبدو أن كل شيء قد سار على ما يرام، فلنقم بتشغيل DBCC CHECKDB و...

كانت عملية الترميم ناجحة.
يرجى ملاحظة أنه يتم تقليل وقت التوقف عن العمل نظرًا لحقيقة أنه من خلال النسخة الاحتياطية الكاملة، لا نقوم باستعادة قاعدة البيانات بأكملها، ولكن فقط الصفحات التالفة (إذا كنت قد استعدت النسخة الاحتياطية بأكملها، فسيتم استعادة النسخة الاحتياطية في 8.5 ثانية، ولكن كلما زاد حجم النسخة الاحتياطية) حجم قاعدة البيانات، سيكون هناك فارق زمني أكبر). المحظوظون الذين يستخدمون SQL Server Enterprise Edition والذين يستخدمون الاسترداد عبر الإنترنت سيوفرون أيضًا الوقت في الاستعادة من النسخ الاحتياطية للسجل، ومع الاسترداد دون اتصال، للأسف، ستتم معالجة السجلات بالكامل.
ومن الجدير بالذكر أيضًا أنه في SQL Server 2005، 2008، 2008 R2، لا يمكن استعادة صفحة واحدة إلا باستخدام T-SQL في Denali، وأصبح من الممكن القيام بذلك من خلال واجهة المستخدم الرسومية.

ولكن ماذا لو كان DBCC CHECKDB؟

تحسبًا لذلك، قررت التحقق مما سيفعله SQL Server إذا قمت بتشغيل DBCC CHECKDB باستخدام المعلمة REPAIR_ALLOW_DATA_LOSS. لا يزال نفس الخطأ:

أولاً، نقوم بتحويل قاعدة البيانات إلى وضع SINGLE_USER:
تغيير مجموعة قاعدة بيانات AdventureWorks SINGLE_USER وبعد ذلك نبدأ عملية الاسترداد:
DBCC CHECKDB("AdventureWorks"، REPAIR_ALLOW_DATA_LOSS) مع NO_INFOMSGS، ALL_ERRORMSGS، DATA_PURITY ونتيجة لذلك:
الإصلاح: تم إلغاء تخصيص الصفحة (1:20455) من معرف الكائن 1883153754، معرف الفهرس 0، معرف القسم 72057594054246400، تخصيص معرف الوحدة 72057594061651968 (اكتب البيانات في الصف).
نعم، قام SQL Server بحذف الصفحة "التالفة". نقوم بتحويل قاعدة البيانات إلى وضع MULTI_USER بحيث تصبح في متناول الجميع ونتحقق مما هو مفقود:

بالنظر إلى أن حجم الصفحة في SQL Server هو 8 كيلو بايت، وأقل قليلاً متاح لبيانات المستخدم، كل شيء طبيعي، فقد "فقد الجدول وزنه" بمقدار 7 سجلات (في البداية كان هناك 99999). نظرًا لعدم وجود فهرس مجمع في هذا الجدول، يمكن تخزين البيانات بترتيب عشوائي، أي. لم نتمكن حتى من معرفة البيانات التي ستفقد.

فلماذا، في نهاية المطاف، لا توجد ترجمة؟

فلماذا لا تكون هذه ترجمة، بل تدوينة "مبنية على"؟ الحقيقة هي أن مقالة "استعادة الصفحة" التي كتبها جيل شو ليست متاحة للجمهور. يوجد مثل هذا القسم في كتاب SQL Server MVP Deep Dives vol.2، والذي يتم بيعه بمبلغ كبير جدًا من المال (ولكن، بالطبع، يمكن العثور عليه بسهولة على الإنترنت) ولست متأكدًا من نشر الترجمة هل أم... صحيح أو شيء من هذا.
بشكل عام، قرأت المقال، وسجلت النقاط الرئيسية، ثم كتبت النص بنفسي وأجريت تجربة ترميم على طول الطريق. آمل أن تكون هذه التجربة مفيدة لشخص ما.
وأيها السادة، آمل مخلصًا أنه إذا قررتم تكرار هذه التجربة، فستكونون حذرين للغاية (على سبيل المثال، لن تجربوا قاعدة البيانات الرئيسية على خادم الإنتاج). وتذكر أنني لا أتحمل أي مسؤولية عن أفعالك.

أحد المتطلبات الرئيسية لنظام إدارة قواعد البيانات (DBMS) هو موثوقية تخزين البيانات في الذاكرة الخارجية. تعني موثوقية التخزين أن نظام إدارة قواعد البيانات (DBMS) يجب أن يكون قادرًا على استعادة آخر حالة متسقة لقاعدة البيانات بعد أي فشل في الأجهزة أو البرامج. عادة، يتم أخذ نوعين محتملين من أعطال الأجهزة في الاعتبار: ما يسمى بالأعطال البسيطة، والتي يمكن تفسيرها على أنها توقف مفاجئ للكمبيوتر (على سبيل المثال، انقطاع التيار الكهربائي في حالات الطوارئ)، والأعطال الصلبة، التي تتميز بفقدان المعلومات على الأجهزة الخارجية وسائط الذاكرة. يمكن أن تكون أمثلة فشل البرامج: تعطل نظام إدارة قواعد البيانات (بسبب خطأ في البرنامج أو نتيجة لفشل بعض الأجهزة) أو تعطل برنامج المستخدم، ونتيجة لذلك تظل بعض المعاملات غير مكتملة. يمكن اعتبار الحالة الأولى بمثابة نوع خاص من فشل الأجهزة البسيطة؛ وعندما يحدث هذا الأخير، فمن الضروري إزالة عواقب معاملة واحدة فقط.

على أية حال، لاستعادة قاعدة البيانات، يجب أن يكون لديك بعض المعلومات الإضافية. بمعنى آخر، يتطلب الحفاظ على موثوقية تخزين البيانات في قاعدة البيانات تكرار تخزين البيانات، ويجب تخزين جزء البيانات المستخدم للاسترداد بشكل موثوق بشكل خاص. الطريقة الأكثر شيوعًا للاحتفاظ بهذه المعلومات المتكررة هي الاحتفاظ بسجل تغيير قاعدة البيانات.

السجل هو جزء خاص من قاعدة البيانات، لا يمكن لمستخدمي نظام إدارة قواعد البيانات الوصول إليه ويتم صيانته بعناية خاصة (في بعض الأحيان يتم الاحتفاظ بنسختين من السجل، موجودتين على أقراص فعلية مختلفة)، والذي يتلقى سجلات لجميع التغييرات في الجزء الرئيسي من قاعدة البيانات. عند الاحتفاظ بمجلة، يتم اتباع استراتيجية تسجيل "استباقية"، مما يعني أن سجل التغيير في أي كائن قاعدة بيانات يجب أن يدخل إلى الذاكرة الخارجية للمجلة قبل أن يدخل الكائن الذي تم تغييره إلى الذاكرة الخارجية للجزء الرئيسي من قاعدة البيانات. ومن المعروف أنه إذا تمت ملاحظة هذا الشرط بشكل صحيح في نظام إدارة قواعد البيانات، فباستخدام السجل يمكنك حل جميع مشاكل استعادة قاعدة البيانات بعد أي فشل.

أثناء الفشل البسيط، قد تحتوي الذاكرة الخارجية للجزء الرئيسي من قاعدة البيانات على كائنات معدلة بواسطة معاملات لم تكتمل في وقت الفشل، وقد لا يكون هناك كائنات معدلة بواسطة معاملات اكتملت بنجاح في وقت الفشل ولكن لم تتم كتابتها على الذاكرة الخارجية. الهدف من عملية الاسترداد بعد فشل بسيط هو حالة الذاكرة الخارجية للجزء الرئيسي من قاعدة البيانات، والتي قد تنشأ إذا تم تسجيل تغييرات جميع المعاملات المكتملة في الذاكرة الخارجية والتي لن تحتوي على أي آثار غير مكتملة المعاملات. ومن أجل تحقيق ذلك، يقومون أولاً باستعادة المعاملات غير المكتملة، ثم يعيدون تشغيل عمليات المعاملات المكتملة التي لا يتم عرض نتائجها في الذاكرة الخارجية. لاستعادة قاعدة بيانات بعد فشل كبير، استخدم سجلاً ونسخة مؤرشفة من قاعدة البيانات. نسخة الأرشيف هي نسخة كاملة من قاعدة البيانات في الوقت الذي بدأ فيه ملء السجل. لاستعادة قاعدة البيانات العادية بعد فشل كبير، من الضروري ألا يختفي السجل. ثم يتكون استرداد قاعدة البيانات من إعادة إنتاج عمل جميع المعاملات التي انتهت في وقت الفشل باستخدام السجل، بناءً على نسخة الأرشيف.

على الرغم من وجود متطلبات خاصة للحفاظ على السجل من حيث الموثوقية، إلا أنه من الممكن، من حيث المبدأ، فقدانه. ثم الطريقة الوحيدة لاستعادة قاعدة البيانات هي العودة إلى النسخة الاحتياطية. وبطبيعة الحال، في هذه الحالة لن تتمكن من الحصول على آخر حالة متسقة لقاعدة البيانات، لكنه أفضل من لا شيء.

أسهل طريقة لأرشفة قاعدة بيانات عند حدوث تجاوز سعة السجل. يتم تقديم ما يسمى بـ "المنطقة الصفراء" في المجلة، وعند الوصول إليها يتم حظر تكوين المعاملات الجديدة مؤقتًا. عند اكتمال جميع المعاملات، وبالتالي تكون قاعدة البيانات في حالة متسقة، يمكنك أرشفتها، ثم البدء في ملء السجل مرة أخرى.

يمكنك عمل نسخة احتياطية لقاعدة البيانات الخاصة بك في كثير من الأحيان أقل من امتلاء السجل. عندما يمتلئ السجل وتنتهي جميع المعاملات التي بدأت، يمكنك أرشفة السجل نفسه. نظرًا لأن مثل هذا السجل المؤرشف مطلوب فقط لإعادة إنشاء النسخة المؤرشفة من قاعدة البيانات، فيمكن ضغط معلومات السجل بشكل كبير أثناء الأرشفة.

غالبًا ما يحتاج مطورو ومسؤولو Microsoft SQL Server إلى ذلك استعادة قاعدة البيانات من الأرشيف(النسخ الاحتياطي)، على سبيل المثال لإنشاء نسخة من قاعدة البيانات التي سيتم استخدامها لاختبار التطبيق، أو على سبيل المثال، قمت بإعادة تثبيت نظام التشغيل وتحتاج إلى استعادة قاعدة البيانات، هذا ما سنفعله اليوم.

في هذه المقالة سنلقي نظرة على استعادة قاعدة البيانات باستخدام نظام إدارة قواعد البيانات (DBMS) كمثال. مايكروسوفت SQL خادم 2000. من أجل استعادة قاعدة البيانات، يجب أن يكون لديك أرشيف لقاعدة البيانات هذه. تم إنشاؤه بامتداد *.dat. أوصي الجميع بإنشاء أرشيفات لقواعد بياناتهم، وأرشيفات يومية؛ إذا حدث أي شيء، سيكون لديك دائمًا أرشيف لاستعادته.

وصف عملية استعادة قاعدة البيانات من النسخة الاحتياطية

لنبدأ، افتح Enterprise Manager، وحدد قاعدة البيانات التي تريد استعادتها، أو إذا قمت للتو بتثبيت نظام إدارة قواعد البيانات (DBMS) ولا توجد قواعد بيانات هناك حتى الآن، فما عليك سوى إنشاء قاعدة بيانات واستعادتها من الأرشيف. افتح القائمة " الأدوات->استعادة قاعدة البيانات"وستفتح النافذة التالية:

يختار " من الجهاز" وانقر " حدد الأجهزة».

(تحميل موضع البانر 3

انقر فوق موافق وفي " اختر استعادة قاعدة البيانات»انقر أيضًا على موافق. وفي النافذة الرئيسية " استعادة قاعدة البيانات"لا تتعجل في النقر فوق "موافق" بعد، انتقل إلى علامة التبويب " خيارات» وحدد المربع كما في الصورة.

هنا أيضًا، قم بتعيين المسار لملفات قاعدة البيانات، لأنه قد يكون غير صحيح، ويمكنك الكتابة فوق، على سبيل المثال، قاعدة بيانات موجودة إذا قمت بإنشاء نسخة من قاعدة البيانات، ولكن إذا قمت للتو بتثبيت كل شيء (DBMS)، فأنت ليس من الضروري تغييره.

هذا كل شيء، وبعد ذلك يمكنك النقر فوق موافق. وبعد مرور بعض الوقت، سيتم استعادة قاعدة البيانات ويمكنك استخدامها.

بالمناسبة، إذا كان أي شخص مهتمًا بلغة T-SQL ( هو امتداد للغة SQL في Microsoft SQL Server)، ثم يمكنني أن أوصي بالكتاب " مسار مبرمج T-SQL. البرنامج التعليمي للغة SQL للعمليات"، بعد قراءتها ستتمكن من البرمجة بسهولة في T-SQL.