اشياء لم يتم التطرق لها في قواعد بيانات فايربيرد

[Delphi4Us]

لرؤية نتائج الاختبارات التي تم اجراءها على كل نسخ فايربيرد يمكن مطالعة هذا الرابط حيث يوجد اختبار حتى للنسخة القادمة 6

https://www.firebirdtest.com/

12 خطأ شائعًا أثناء النسخ الاحتياطي لقواعد البيانات

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

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

2. الكتابة فوق قاعدة بيانات موجودة أثناء استعادتها من نسخة احتياطية

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

يتمتع Firebird بنوع من الحماية ضد هذا الخطأ - لن يكون من الممكن استعادة قاعدة بيانات من نسخة احتياطية بمساعدة الأداة المساعدة gbak إذا كان مفتاح الإنشاء الافتراضي الخاص به قيد التشغيل وإذا كان اسم الملف المحدد يشير إلى قاعدة بيانات موجودة. لسوء الحظ، هناك طريقة للالتفاف على هذه الحماية: لا يزال المفتاح –rep يسمح لك بالكتابة فوق الملف الموجود.

توصية : لا تقم أبدًا بالكتابة فوق ملف قاعدة بيانات عاملة

توصية لـ Firebird : استخدم FBDataGuard لأنه لا يقوم أبدًا بالكتابة فوق ملف قاعدة البيانات.

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

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

التوصيات : لا تستخدم النسخ الاحتياطي/الاستعادة بخطوة واحدة في الوضع التلقائي وتحقق دائمًا من توفر نسخة محدثة بدرجة كافية في الوضع اليدوي.

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

التوصيات : لا تقم بتخزين النسخ الاحتياطية وقاعدة البيانات على جهاز واحد بغض النظر عن مدى موثوقيتها.

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

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

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

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

6. لا يوجد التحقق من صحة النسخ الاحتياطي
حقيقة أن النسخ الاحتياطية مخزنة في مكان ما لا تعني أنه يمكن قراءتها من هناك.

ولهذا السبب يجب عليك التحقق بانتظام من النسخ الاحتياطية التي تقوم بإنشائها للتأكد من عدم تلفها أو نسخها إلى /dev/null.

توصية لـ Firebird : يمكنك أتمتة التحقق من صحة النسخ الاحتياطي بمساعدة FBDataGuard.

7. لا توجد فحوصات لسلامة قاعدة البيانات أثناء استخدام النسخ الاحتياطية التي لم يتم التحقق منها
عادة، تستخدم قواعد البيانات عدة أنواع من النسخ الاحتياطية - عمليات التفريغ، والنسخ الاحتياطية العادية، وما إلى ذلك. وبدون الخوض في التفاصيل، يمكننا تحديد فئتين: تم التحقق منها ولم يتم التحقق منها. في حالة Firebird، فهو gbak و nbackup .

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

يقوم Nbackup (المعروف أيضًا باسم النسخ الاحتياطي التزايدي) بتأمين ملف قاعدة البيانات الرئيسية مؤقتًا للتحديثات (في الحالة المتسقة) ويجعل من الممكن نسخ ملف قاعدة البيانات بسرعة (كليًا أو جزئيًا/تزايديًا).

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

لتجنب ذلك، يجب عليك استخدام التحقق عبر الإنترنت لقاعدة البيانات الأصلية (يتوفر التحقق عبر الإنترنت بمساعدة gfix بدءًا من إصدار Firebird 2.5.4 بينما تدعم أداة FBDataGuard الخاصة بنا التحقق من صحة قاعدة البيانات عبر الإنترنت للإصدارات 1.5-2.5).

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

توصية لـ Firebird : إلى جانب الفحص الصحي عبر الإنترنت، يسمح لك FBDataGuard باختبار عملية استعادة النسخة الاحتياطية في الوضع التلقائي.

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

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

التوصيات : استخدم أدوات النسخ الاحتياطي التي تتنبأ بحجم النسخة الاحتياطية وتحذرك من احتمال نقص المساحة الحرة.

توصية لـ Firebird : يتحكم FBDataGuard في حجم المساحة الحرة لأغراض النسخ الاحتياطي وأيضًا حجم المساحة الحرة على القرص مع قواعد البيانات وكذلك على قرص النظام.

9. لا يوجد تحكم في الوقت الذي يستغرقه إنشاء نسخة احتياطية
استغرقت عملية النسخ الاحتياطي 40 دقيقة منذ نصف عام، ثم فجأة استغرقت ثلاث ساعات بالفعل - لماذا؟ قد يكون حجم قاعدة البيانات قد زاد أو قد يكون القرص قد انسحب من مصفوفة RAID الخاصة بك مما أدى إلى تباطؤ أداء الكتابة بشكل كبير وقد تكون جميع النسخ الاحتياطية الخاصة بك على وشك الخروج من هذا العالم. أو ربما قام أحد زملائك الجيدين بتشغيل نظام نسخ احتياطي آخر في نفس الوقت (بالمناسبة، يسمح لك Firebird بتشغيل العديد من عمليات النسخ الاحتياطي في وقت واحد على الرغم من أنه ليس من الواضح تمامًا سبب احتياج الشخص إليه على الإطلاق). إذا لم تتحكم في الوقت الذي يستغرقه عمل نسخة احتياطية، فقد تتجاهل مشكلة ظهرت حديثًا وتضيع فرصة إصلاحها قبل أن تتفاقم.

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

التوصيات : استخدم الأدوات التي تتحكم في الوقت الذي تستغرقه عملية النسخ الاحتياطي!

توصية لـ Firebird : يتحكم FBDataGuard في الوقت الذي تستغرقه عملية النسخ الاحتياطي.

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

التوصيات : جدولة تحديثات نظام التشغيل عندما لا تتداخل مع عملية النسخ الاحتياطي.

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

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

بالنسبة لأولئك الذين يرغبون في عمل نسخة احتياطية من قواعد البيانات الخاصة بهم بمساعدة أدوات النسخ الاحتياطي للملفات أو الجهاز الظاهري، يمكننا تقديم طريقتين:

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

بالنسبة إلى Firebird، من الضروري قفل الملف الرئيسي لقاعدة البيانات بمساعدة nbackup قبل بدء عملية النسخ الاحتياطي وفتحه بعد انتهاء العملية. بالنسبة لأنظمة إدارة قواعد البيانات الأخرى، توجد أدوات مماثلة لتشغيل/إيقاف الأوضاع المقابلة.

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

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

التوصيات : لا تستخدم أدوات النسخ الاحتياطي للملفات والأجهزة الافتراضية بدون أدوات التشغيل الآلي المقابلة لقواعد البيانات.

توصية لـ Firebird : استخدم FBDataGuard (من حزمة التوزيع HQbird)، فهو يوفر التكامل مع أدوات النسخ الاحتياطي المدركة لـ VSS.

12. استبدال النسخة الاحتياطية بالنسخ المتماثل
يتم استخدام النسخ الاحتياطي للبيانات وتكرار البيانات لزيادة الموثوقية ومنع فقدان البيانات، لكنهما لا يزالان مختلفين تمامًا.

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

التوصيات : إذا قمت بتكوين النسخ المتماثل، فلا تهمل النسخ الاحتياطية، استخدم كليهما.

توصية لـ Firebird : استخدم حزمة التوزيع HQbird Enterprise، فهي تشتمل على أدوات النسخ الاحتياطي والنسخ المتماثل.

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


المصدر :
https://ib-aid.com/en/articles/12-common...databases/

[أبو معاذ]

بارك الله فيك أخي الحبيب على هذا النقل النافع.

و أيضا مما لاحظته عند بعض الزبائن هو قيامه بنسخ قاعدة البيانات (Copy past )،

و التطبيق الخاص بها شغال ، مما يؤدي إلى تلف ملف قاعدة البيانات.

هناك برنامج اسمه Cobian Backup ، يمكن استعماله في تنفيذ الأوامر التي يكون تنفيذها بشكل دوري. و هو برنامج مجاني (https://www.cobiansoft.com/).

بالمناسبة فقط برنامج FBDataGuard هو برنامج غير مجاني.

[Delphi4Us]

شكرا اخ ابو معاذ وأمين وأجمعين

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

ايضا فايربيرد ياتي معه اداة لاجراء نسخ احتياطي واستعادة عن طريق الاداة Gbak

ما هو Gbak ؟
Gbak هي أداة قياسية لسطر أوامر Firebird ، وهي مصممة لإجراء 1) نسخ احتياطي كامل لقاعدة البيانات: فهي تقرأ كل سجل في قاعدة البيانات وتخزنها في ملف النسخ الاحتياطي، 2) استعادة النسخة الاحتياطية إلى الإصدار الجديد قاعدة البيانات.
بالنسبة للمطورين والمسؤولين ذوي الخبرة مع RDBMS الأخرى، قد يكون مصطلح "النسخ الاحتياطي" مربكًا بعض الشيء، نظرًا لأن gbak لا ينتج النسخة الدقيقة من قاعدة البيانات، ولكن الملف بتنسيق غير قاعدة بيانات، فقط مع البيانات (يتم تخزين الفهارس كـ التصريحات).
لإنشاء قاعدة بيانات من ملف النسخ الاحتياطي gbak، يجب إجراء عملية الاستعادة باستخدام gbak.

[Code]
gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
[code/]

في هذا المثال، تصل أداة gbak إلى ملف قاعدة البيانات باستخدام الوصول المحلي أو المضمن.

Firebird 3.0: الوصول المضمن في التكوين الافتراضي لـ Firebird 3.0 (مع المعلمة في firebird.conf ServerMode = SuperServer) سيحاول وضع قفل حصري على قاعدة البيانات، لذلك لن تتمكن الاتصالات الأخرى من الوصول إلى قاعدة البيانات (أو ستفشل محاولة gbak) بسبب الاتصالات النشطة).

Firebird 2.5: مع Firebird 2.5 على نظام التشغيل Windows، سيعمل الأمر بشكل جيد من خلال بروتوكول XNET (إذا كان لديك مثيل Firebird الوحيد قيد التشغيل، بالطبع). في نظام التشغيل Linux، سيحاول Firebird استخدام الوصول المضمن، وإذا لم يكن من الممكن الوصول إليه، فسيحاول الاتصال تلقائيًا (وضمنيًا) عبر TCP/IP. (إذا كنت لا تعرف معنى XNET وINET وما إلى ذلك، يرجى قراءة بروتوكولات الاتصال في Firebird 3 )

ملاحظة 1 : يعمل هذا الأمر ضمن حساب مستخدم نظام التشغيل (أي حسابك)، ويستخدم أذوناته للوصول إلى النسخ الاحتياطي وملفات قاعدة البيانات.
عادةً، يتم تشغيل خدمة Firebird على Windows باستخدام حساب LocalSystem، وعلى Linux ضمن حساب المستخدم "firebird"، ولكن يتم تشغيل وحدة التحكم عادةً ضمن حساب المستخدم الخاص بك.
إذا لم يكن لدى حساب المستخدم هذا حق الوصول إلى مسار قاعدة البيانات أو مسار النسخ الاحتياطي، فسوف يفشل gbak مع ظهور الخطأ "لا يمكن فتح ملف النسخ الاحتياطي" (انظر المثال في الملحق أ. الأخطاء، رقم 5).

ملاحظة 2 : يقوم gbak -b بالكتابة بصمت فوق ملف النسخ الاحتياطي. لذلك، إذا كان لديك نسخة احتياطية 1.fbk بالفعل، فسيتم استبدالها.

ملاحظة 3 : في نظام التشغيل Linux، سيقوم أمر gbak هذا بإنشاء ملف نسخة احتياطية يكون المالك مساويًا لمستخدم وحدة التحكم.

وقت النسخ الاحتياطي لهذا الأمر: 120 ثانية

النسخ الاحتياطي باستخدام gbak مع سلسلة اتصال TCP/IP
هذا هو أمر gbak الأكثر عالمية لإجراء النسخ الاحتياطي عبر الإنترنت.
شبابيك


gbak -b localhost:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

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

gbak -b localhost/3051:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

وقت النسخ الاحتياطي: 182 ثانية

المصدر
https://ib-aid.com/articles/firebird-gba...and-tricks

[Delphi4Us]

23 طرق أخرى لتسريع فايربيرد

حقيقة هذه الطرق لتسريع فايربيرد عادة يتحدث عنها من لهم قواعد بيانات لشركات فيها الملايين من السجلات حيث ان اي ثانية في اي عملية واحدة تحدث فرق كبير في نتائج الاداء بمحرك ادارة قاعدة البيانات .

فلو قلنا تم تسريع 100 جزء من الثانية في في عملية تحديث سجل لقاعدة بيانات على سحابة ما فهذا الجزء مهم جدا في تحديث 10 مليون سجل .

لماذا "23 أكثر"؟
يتذكر البعض منكم المقال « 45 طريقة لتسريع Firebird »، الذي تم نشره في مايو 2016. حان الوقت الآن لنشر السلسلة التالية من النصائح والحيل، والتي تعتمد في الغالب على تجربة تحسين وصيانة قواعد بيانات Firebird و خوادم ذات عدد كبير من الاتصالات (1000+).
1. اضبط خيارات الطاقة على الأداء العالي في Windows Server 2016 و2019
افتراضيًا، يحتوي Windows Server على خطة طاقة تم تعيينها على "متوازن"، وهي غير مناسبة لخوادم قواعد البيانات. اضبطه على "الأداء العالي" واحصل على ما يقرب من +20% من الأداء للعمليات التي تتطلب وحدة المعالجة المركزية بشكل مكثف. يمكن ضبطه عبر الإنترنت، دون إعادة التشغيل أو إعادة التشغيل. توضح الصورة أدناه الرسم البياني لوحدة المعالجة المركزية، والذي يوضح ميزة خطة الطاقة "عالية الأداء"

[image]
https://ib-aid.com/images/perfhqbird/CPU...rmance.png
]image/]

2. قم بتمكين «التفاعل مع سطح المكتب» على الإصدار الكلاسيكي لنظام التشغيل Windows
إذا كنت تستخدم Firebird مع البنية الكلاسيكية على نظام التشغيل Windows، فقم بتمكين علامة الاختيار «السماح للخدمة بالتفاعل مع سطح المكتب». بدون هذا الإعداد، يكون المورد «كومة سطح المكتب» محدودًا بواسطة Windows، ولا يمكن لـ Firebird فتح أكثر من 250-300 اتصال (يعتمد على البيانات التعريفية لقاعدة البيانات واستهلاك الذاكرة ذات الصلة) - سيكون هناك خطأ نفاد الذاكرة

https://ib-aid.com/images/allow_service_...ekstop.png

3. احذر: وحدة تحكم المجال
المشكلة هي أن Windows مع دور وحدة تحكم المجال يقوم بتعطيل ذاكرة التخزين المؤقت للكتابة على القرص باستخدام قاعدة بيانات Active Directory.
إنه يؤثر على Firebird بطرق مختلفة (بالإضافة إلى التطبيقات الأخرى بالطبع)، ويظهر أداءً أسوأ بكثير من الخوادم التي لا تحتوي على أدوار Active Directory.
يرجى ملاحظة أن هذه المشكلة تؤثر على إصدار Windows الشائع مثل Windows Small Business Server 2011، بالإضافة إلى الإصدارات الأخرى مع DC.

وانتبه إلى السطر الذي يحتوي على الحد الأقصى لعدد الملفات المفتوحة.
يمكن أن يستخدم Firebird ما يصل إلى 4 مقابض لكل اتصال، وإذا كنت تريد شيئًا مثل هذا:
Max open files 4096 4096 files

هذا يعني أن إجمالي عدد الاتصالات التي تخدمها عملية Firebird سيقتصر على حوالي 1000.
يرجى ملاحظة - إذا كان لديك 4 قواعد بيانات على الخادم، فسيتم احتساب الاتصال لكل قاعدة بيانات.
تعيين المزيد – أوصي بـ 65535.
لا تنس التحقق مرة أخرى بعد إعادة تشغيل عملية Firebird: هل تم تطبيقه أم لا.
بالنسبة للهندسة المعمارية الكلاسيكية، من الضروري التحقق من الحدود الخاصة بمستخدم «firebird» وزيادتها.

6. قم بحجز 40% من ذاكرة الوصول العشوائي (RAM) للتخزين المؤقت للملفات في Windows
لدى OS Memory Manager آثار فيما يتعلق بتخصيص الذاكرة، ويتطلب Windows بشكل افتراضي 40% من ذاكرة الوصول العشوائي (RAM) للتخزين المؤقت للملفات.
لسوء الحظ، تُظهر الأداة الضعيفة "إدارة مهام Windows" الذاكرة المستخدمة للتخزين المؤقت للملفات على أنها "مجانية"، ويحاول بعض المسؤولين جعل Firebird يستهلك كل هذه الذاكرة المجانية، لذلك يقومون بتعيين معلمة DefaultDBCachePage في firebird.conf على قيم عالية جدًا، و وعادة ما يؤدي إلى المبادلة.

استخدم دائمًا أداة RAMMap لمعرفة الاستخدام الفعلي للذاكرة على نظام Windows.

القاعدة التجريبية لـ Windows Server (المخصصة للاستخدام كخادم Firebird) هي التالية: يجب أن تكون ذاكرة Firebird (مجموعة العمل) أقل من 40% من إجمالي ذاكرة الوصول العشوائي (RAM). إذا كان الحجم الإجمالي لمجموعات العمل لجميع العمليات أكثر من 50%، فيمكن بدء التبديل بواسطة Windows.

يرجى ملاحظة: "الاحتياطي" هنا لا يعني فقط "عدم تعيين عدد كبير جدًا من المخازن المؤقتة للصفحات في Firebird"، ولكن من المهم أيضًا تقييد استخدام الذاكرة للبرامج الأخرى. على سبيل المثال، إذا كان لديك MS Exchange أو MSSQL على نفس الخادم مع Firebird، فتأكد من تقييد شهيتهم للذاكرة.

7. احتفظ بنسبة 30% من ذاكرة الوصول العشوائي (RAM) لذاكرة التخزين المؤقت للملفات في Linux
يعمل Linux مع ذاكرة التخزين المؤقت للملفات بطريقة مختلفة عن Windows، وبشكل عام، يمكن أن يكون مقدار ذاكرة الوصول العشوائي المستخدمة في ذاكرة التخزين المؤقت للملفات أقل بكثير مما هو عليه في Windows، دون تدهور ملحوظ في أداء Firebird. ومع ذلك، لضمان الأداء العالي للنظام مع عدد كبير من الاتصالات، خاصة في Classic وSuperClassic، ستكون الفكرة الجيدة هي حجز 30% من ذاكرة الوصول العشوائي لذاكرة التخزين المؤقت للملفات.

9. بالنسبة للأجهزة الافتراضية – احذر من الإفراط في الالتزام بالذاكرة
يمكن تكوين الجهاز الظاهري ليحتوي على ذاكرة أكبر من تلك الموجودة فعليًا على الجهاز المضيف - مع ميزة تُعرف باسم Memory Overcommit (يمكن أن يختلف الاسم باختلاف أنظمة المحاكاة الافتراضية). وهذا يعني أنه في حالة ذروة استهلاك الذاكرة (على VM مع خادم قاعدة البيانات أو على VM المجاور)، يمكن بدء المبادلة، مما سيؤدي إلى تأخيرات كبيرة. بالنسبة للأجهزة الافتراضية عالية الأداء المخصصة لخادم قاعدة البيانات، يجب أن تكون كل الذاكرة ثابتة.

10. بالنسبة للأجهزة الافتراضية – تحقق من حدود الأجهزة الافتراضية
غالبًا ما يتم إنشاء الأجهزة الافتراضية باستخدام حدود وحدة المعالجة المركزية (CPU) ووحدات الإدخال/الإخراج الافتراضية، والتي يمكن أن تكون منخفضة جدًا، مثل 50 IOPS و10% من وحدة المعالجة المركزية (CPU). تحقق من إعدادات VM لخادمك وقم بإزالة أي حدود - يجب أن يحتوي خادم قاعدة البيانات عالي الأداء على كل وحدة المعالجة المركزية (CPU) وعرض النطاق الترددي وIO الممكنة.
11. تنظيف ملفات Firebird المؤقتة
يقوم Firebird بإنشاء العديد من الملفات المؤقتة لعمليات مختلفة: الفرز، ومعالجة BLOB، والتتبع. يتم تخزين هذه الملفات في المواقع التالية: على Windows C:\ProgramData\firebird ، على Linux / tmp / firebird
عادةً يجب تنظيف هذه الملفات تلقائيًا، ومع ذلك، لا يحدث ذلك في بعض الأحيان (على سبيل المثال، في حالة إعادة تشغيل الخادم) .
قم بفحص هذه المجلدات بشكل دوري وقم بتنظيف الملفات القديمة - قد يكون هناك العديد من الجيجابايت من الملفات القديمة fb_NNN، وسيؤدي تنظيفها إلى تحرير مساحة على محرك أقراص النظام.

12. لا تنس تمكين ذاكرة التخزين المؤقت للملفات باستخدام ذاكرة التخزين المؤقت الكبيرة لـ Firebird
كما تعلم، يتم تحديد ذاكرة التخزين المؤقت لـ Firebird (وتسمى أيضًا «المخازن المؤقتة للصفحات») بواسطة المعلمة DefaultDBCachePages في firebird.conf/databases.conf، أو مباشرة في رأس قاعدة البيانات.
في Firebird 3 SuperServer، يمكن تعيين حجم ذاكرة التخزين المؤقت هذه على مستوى عالٍ جدًا، ولكن من المهم أن تتذكر معلمة أخرى: FileSystemCacheThreshold.
إذا كان FileSystemCacheThreshold أقل من DefaultDBCachePages أو المخازن المؤقتة للصفحات، فلن يتم استخدام ذاكرة التخزين المؤقت لملفات نظام التشغيل، مما قد يؤدي إلى مشاكل في الأداء.
في 99% من الحالات، من الأفضل تمكين ذاكرة التخزين المؤقت للملفات.
ولضمان ذلك، قم دائمًا بتعيين المعلمات وفقًا للقاعدة التالية:
DefaultDBCachePages = X
FileSystemCacheThreshold = X+ N, N>1
هناك حالات نادرة يؤدي فيها تعطيل ذاكرة التخزين المؤقت للملفات إلى تحسين الأداء - إذا كان لديك مثل هذا المثال، يرجى الاتصال بي - ak@ib-aid.com !
13. تسريع قاعدة البيانات الأمنية
ينشئ كل اتصال بقاعدة بيانات Firebird اتصالاً بقاعدة بيانات الأمان (security3.fdb في حالة Firebird 3)، ويقوم بعدة عمليات قراءة وكتابة (صفحات المعاملات، وصفحة الرأس). إذا كانت لديك اتصالات متكررة، فقد يصبح أداء قاعدة بيانات الأمان الخاصة بك مشكلة.
كحد أدنى، يمكنك القيام بما يلي:
زيادة المخازن المؤقتة للصفحات لـ SecurityN.fdb (المثالي التجريبي هو 256 مخزنًا مؤقتًا)
انقل Security3.fdb إلى محرك الأقراص السريع (وهي ميزة قياسية في Firebird 3، وفي الإصدار 2.5 ستتطلب إعادة التثبيت)
بعد ذلك، يمكنك تعيين Forced Writes OFF لقاعدة بيانات الأمان - فالاحتمال الضئيل للفساد لا يمثل مشكلة في هذه الحالة.
الطريقة الأكثر تطرفًا هي جعل قاعدة بيانات الأمان للقراءة فقط، مما يؤدي إلى إزالة كافة عمليات الكتابة إليها.
إذا كنت لا تقوم في كثير من الأحيان بتغيير المستخدمين في قاعدة بيانات الأمان، فهذا هو الحل الأفضل.
14. جرب SuperClassic على Firebird 3
في Firebird 3، تم الإعلان بشكل كبير عن بنية SuperServer باعتبارها الحل النهائي للأداء، ولكن هناك بعض أنواع التحميل التي توضح أداء أفضل مع SuperClassic (ولكن ليس Classic - فهو يعمل دائمًا بشكل أبطأ من SuperServer/SuperClassic).
​كيفية
تنفيذ هذه التجربة في طريقة آمنة؟ اتبع الخطوات التالية:

To try SuperClassic
Set in firebird.conf
ServerMode=SuperClassic
DefaultDbCachePages=1024
gfix –buff 0
Restart Firebird
To revert to SuperServer
Set in firebird.conf
ServerMode=SuperServer
DefaultDbCachePages=N # N*page size*databases_count < 25% RAM
FileSystemCacheThreshold = N+1
gfix –buff 0
Restart Firebird

15. قاعدة بيانات كبيرة؟ زيادة حجم الصفحة
بشكل افتراضي، تحتوي قواعد بيانات Firebird على أحجام الصفحات التالية:
2.5 – 4096 بايت
3.0 - 8192 بايت
ومع ذلك، الحد الأقصى لحجم الصفحة هو 16 كيلو بايت (في 4.0 - 32 كيلو بايت).
بالنسبة لقواعد البيانات التي يزيد حجمها عن 100 جيجابايت في 95% من الحالات، فمن الأفضل أن يكون لديك أعلى حجم متاح للصفحة، من أجل:
تقليل عمق المؤشرات. من المستحسن أن يكون لديك مؤشرات ذات عمق أقل أو تساوي 3. المؤشرات ذات العمق 4 و 5 ستكون أبطأ بكثير
زيادة الاستفادة من ذاكرة الوصول العشوائي. يتم تحديد ذاكرة التخزين المؤقت لـ Firebird في الصفحات، وستكون 1000 صفحة بحجم صفحة 8 كيلو بايت بمثابة 8 ميجا بايت من الذاكرة الفعلية، وبحجم 16 كيلو بايت - 16 ميجا بايت.
تقليل عدد صفحات النظام. سيؤدي ذلك إلى تسريع الوصول إلى سجلات الجداول الكبيرة (صفحة بيانات مؤشر القفزات الأقل)، ويساعد في إعداد استعلامات SQL الكبيرة. لزيادة حجم صفحة قاعدة البيانات، يجب عمل نسخة احتياطية لقاعدة البيانات باستخدام أداة gbak ثم استعادتها باستخدام المعلمة –page ( gbak –c –page 16384 ).
يرجى ملاحظة: إذا كانت لديك قاعدة بيانات تحتوي على العديد من النقط الصغيرة، فإن زيادة حجم الصفحة يمكن أن يؤدي إلى تقليل التجزئة أو زيادة التجزئة، ومن الصعب التنبؤ بما إذا كانت ستؤدي إلى زيادة الأداء أم نقصانه.
16. لا تستخدم علامة no_reserve
العلامة no_reserve تجعل Firebird لا يحتفظ بمساحة خالية (30%) على صفحات البيانات لإصدارات السجل المحتملة، والتي تحدث بعد التحديث أو الحذف. تسمح هذه العلامة بتخزين البيانات بطريقة أكثر إحكاما (وحجم قاعدة البيانات أقل أيضًا)، ولكن في حالة التحديث/الحذف، تنتقل جميع التغييرات إلى صفحة البيانات الجديدة. ونتيجة لذلك، تكون عمليات التحديث/الحذف في قاعدة البيانات ذات العلامة no_reserve أبطأ.
لذا، إذا لم تكن قاعدة البيانات الخاصة بك للقراءة فقط، فإنني أوصي بإزالة علامة no_reserve . كيفية التحقق من تعيينه أم الآن - راجع سمات السطر في إخراج

gstat –h database

كيفية التعطيل:

gfix -use reserve database

بعد هذا الأمر، سيتم إنشاء صفحات البيانات الجديدة بمساحة محجوزة.
ومع ذلك، لتحقيق التأثير الكامل، من الضروري إجراء نسخ احتياطي لقاعدة البيانات باستخدام gbak ثم استعادتها، وفي هذه الحالة، ستكون جميع صفحات البيانات بمساحة محجوزة.
يرجى ملاحظة: حجم قاعدة البيانات سيزداد بعد إزالة علامة no_reserve والنسخ الاحتياطي/الاستعادة.
17. قم بتعيين حجم أولي مرتفع لجدول قفل Firebird
قفل الجدول هو آلية Firebird المستخدمة لمزامنة الوصول إلى كائنات المحرك الداخلي.
يمكن أن تنمو طاولة قفل Firebird تلقائيًا، لكن زيادتها تكون عملية بطيئة، مما قد يؤدي إلى تجميدات صغيرة. يمكن أن ينمو جدول القفل فقط بدءًا من الحجم الأولي (تم تعيينه في firebird.conf).
لمنع جولات متعددة من زيادة جدول القفل، ستكون الفكرة الجيدة هي مراقبة حجم جدول القفل في نهاية فترة العمل (يوم، أسبوع، إلخ)، ثم تعيينه كحجم أولي في firebird.conf.
LockMemSize=99999999
كمرجع لك: LockMemSize في أنظمة التحميل العالية التي تضم حوالي 1000 مستخدم يكون عادةً أقل من 200 ميجابايت.
18. استخدم fb_lock_print لحساب عدد الاتصالات بقاعدة البيانات
يعد الحصول على عدد اتصالات قاعدة البيانات مهمة متكررة لمطوري قواعد البيانات: يمكن أن يكون ضروريًا لأغراض الترخيص، على سبيل المثال.
غالبًا ما يستخدم المطورون الاستعلام SELECT count(*) FROM MON$ATTACHMENTS للحصول على هذه القيمة، ولكنها ليست الطريقة المثلى: يمكن أن تشكل الاستعلامات المتكررة لجداول MON$ عبئًا على قاعدة البيانات، لذا من الأفضل استخدام البديل:
تشغيل
fb_lock_print –d database_name | alias
والتحقق من قيمة المالكين - سيُظهر العدد الحالي للاتصالات بقاعدة البيانات.

19. تجنب الصلات اليسرى غير الضرورية
غالبًا ما أرى استفسارات تتعلق بالبناء مثل هذا:
T1 LEFT JOIN T2 ON (...) حيث T2.Field_condition
بشكل أساسي، الشرط الموجود في T2 يستبعد القيم الخالية من مخرجات LEFT JOIN T2، لذلك من الممكن تغيير LEFT JOIN إلى INNER JOIN - لن يؤثر ذلك على نتيجة الاستعلام.
يمنح INNER JOIN مزيدًا من الحرية لمُحسِّن Firebird، وفي الإصدارات الحديثة من Firebird، تم تحسينه بشكل أفضل بكثير من LEFT.
خاصة أنه منطقي في الحالات التالية:
No condition for T1 in WHERE clause
T2 is a small table

22. لا تحتفظ بالاستعلامات في حالتها المعدة إلا للضرورة
غالبًا ما نرى ما بين 500 إلى 1000 عبارة معدة في كل اتصال (يمكن التحقق منها باستخدام استعلامات MON ​​$).
تعمل الغالبية العظمى منها مرة واحدة فقط، ثم تبقى في ذاكرة الوصول العشوائي (RAM)، مما يجعل مجموعة عمل Firebird أكبر، ويبطئ استعلامات MON ​​$.
التوصية هي الاحتفاظ باستعلامات SQL في الحالة المعدة فقط، حيث يكون من المفترض أن تبدأ عدة مرات، أو إذا كان وقت إعدادها كبيرًا (يمكن أن يكون الأمر كذلك بالنسبة للاستعلامات الكبيرة جدًا التي تحتوي على الكثير من الصلات والوصول إلى الجداول الضخمة).
23. قم دائمًا بإغلاق الاستعلامات ذات الفرز الكبير
حتى يتم إغلاق استعلام SQL مع الفرز (ORDER BY، GROUP BY، UNION، متميز)، يحتفظ Firebird بالسجلات التي تم فرزها في الذاكرة. يتم تعيين حجم الذاكرة المخصصة للفرز بواسطة معلمة TempCacheLimit في firebird.conf، بشكل افتراضي هو 64 ميجابايت.
حتى مع زيادة TempCacheLimit، فإن الاستعلامات طويلة الأمد التي تحتوي على عدد كبير من السجلات التي تم فرزها سوف تستهلك كل الكمية المخصصة في النهاية، ونتيجة لذلك، سينتقل الفرز إلى الملفات المؤقتة (أي القرص). ونتيجة لذلك، يمكن أن يؤدي إلى بطء كبير.
التوصية هي إغلاق كافة هذه الاستعلامات في الوقت المناسب.

المصدر
https://ib-aid.com/en/articles/23-more-w...-firebird/

[Delphi4Us]

يحتوي ملف firebird.conf على إعدادات التكوين لخادم Firebird. قد تحتاج إلى ضبط بعض الإعدادات في هذا الملف وفقًا لحالة الاستخدام والبيئة المحددة لديك. فيما يلي بعض الإعدادات التي قد ترغب في أخذها في الاعتبار:
RemoteServiceBindAddress: يحدد هذا الإعداد عنوان IP الذي يستمع عليه خادم Firebird للاتصالات عن بعد. افتراضيًا، يتم تعيينه على 0.0.0.0، مما يعني أن الخادم يستمع إلى جميع واجهات الشبكة المتاحة. إذا كان سطح المكتب البعيد الخاص بك يحتوي على واجهات شبكة متعددة، فقد تحتاج إلى تعيين هذه القيمة على عنوان IP الخاص بالواجهة التي تريد قبول الاتصالات عن بعد عليها.
RemoteFileOpenAbility: يتحكم هذا الإعداد فيما إذا كان خادم Firebird يسمح للاتصالات عن بعد بفتح الملفات. بشكل افتراضي، يتم تعيينه على 0، مما يعطل الوصول إلى الملفات. إذا كان التطبيق الخاص بك يتطلب الوصول إلى الملفات، فقد تحتاج إلى تعيين هذه القيمة إلى 1.
WireCrypt: يتحكم هذا الإعداد فيما إذا كان خادم Firebird يستخدم التشفير للاتصال بالشبكة. بشكل افتراضي، يتم تعيينه على 0، مما يعني تعطيل التشفير. إذا كنت تحتاج إلى اتصال آمن، فقد تحتاج إلى تعيين هذه القيمة إلى 1.
لضبط هذه الإعدادات، يمكنك اتباع الخطوات التالية:
حدد موقع ملف firebird.conf على سطح المكتب البعيد. افتراضيًا، يكون موجودًا في دليل تثبيت Firebird.
افتح الملف في محرر النصوص وحدد الإعدادات ذات الصلة.
قم بتغيير القيم حسب الضرورة واحفظ الملف.
أعد تشغيل خادم Firebird لتصبح التغييرات سارية المفعول.
لاحظ أن تغيير ملف firebird.conf يمكن أن يكون له تأثيرات كبيرة على سلوك خادم Firebird، لذلك من المهم اختبار تغييراتك بدقة قبل نشرها في بيئة الإنتاج. بالإضافة إلى ذلك، من الجيد دائمًا عمل نسخة احتياطية من ملف firebird.conf قبل إجراء أي تغييرات، بحيث يمكنك العودة بسهولة إلى التكوين السابق إذا لزم الأمر.

[Delphi4Us]

لقد جربت طريقة لحفظ البيانات في حقل مشابه للمصفوفة واردت مشاركتها معكم
حيث بدل من انشاء جدول لحفظ بيانات فرعية يمكن حفظها في حقل واحد بنفس الجدول

حيث لدي مجموعة من المكاتب
----------------------------------------
رقم التعريف | اسم المكتب
01- مكتب الاول
03 - المكتب الثاني
155- المكتب الثالث

لدي سجل فيه اسم الوثيقة ونسخة منها ، وفي الحقل السابق أخزن أرقام جميع المكاتب التي لها حق الوصول إلى الوثيقة، وقيمتها مثلا هي كما يلي:
1,3,155
وبالطبع يمكنني الاستفسار عن رقم أي مكتب ومعرفة ما إذا كان لديه صلاحية الاطلاع على هذه الوثيقة

Select inbox.id
from inbox
where inbox.to_office containing '01'

كانت المشكلة أن عبارة الاستعلام السابقة لم تفرق بين الرقم 1 والرقم 10 لأن الرقم 10 يحتوي على الرقم 1. لقد قمت بحل هذه المشكلة بوضع 0 قبل الرقم 1، فأصبح 01.
لكن المشكلة ستبقى إذا كان عدد المكاتب أكثر من 100، لأن الاستعلام لن يفرق مثلا بين 15 والرقم 115.
ولحل المشكلة يمكن تحويل رقم التعريف إلى ثلاثة أرقام مثل 001، 002، 003 وغيرها

او اللجؤ الى وضع الارقام بين علامتي تنصيص مثل '1','12','100'
ويتغير الاستعلام ليبحث عن رقم بين علامتي تنصيص وبذلك لا مشكلة في استخدام اي تنسيق للارقام

ارى ان هذه الطريقة اسهل من استخدام المصفوفات او بمثل سهولتها وتؤدي الغرض وتقلل كثرة الاستعلامات من الجداول الفرعية .
ويمكن استخدامها مع قواعد البيانات التي لا تدعم المصفوفات

[bouh25]

عند قاعدة معطيات Access معبئة اريد تحويلها الى FireBird هل هناك طريقة مضمونة مع لتحويل وحفظ المعطيات المخزنة

[larbiparadox]

جرب هذا البرنامج
DMSoft DBConvert for Access and Firebird

[Delphi4Us]

توجد طريقة في فايربيرد وهي استخدام computed column لانشاء عمود او حقل جديد يعرض قيمة هي للقراءة فقط مثل ان يجمع قيمة حقلين او يضربهم
مثال
اعرض بهذا الحقل قيمة ضرب سعر المنتج مع الكمية
مثال اخر اعرض لي بهذا الحقل اسم المكتب الذي رقم ID له كذا

كود :

CREATE TABLE DOC (
    DOC_ID         INTEGER NOT NULL,
    SFILE          VARCHAR(21),
    DEP_HERE       INTEGER NOT NULL,
    DEP_STR        COMPUTED BY ((Select DEP_NAME from DEPARTMENT where DEP_ID = DEP_HERE)),
    MNOTE2         VARCHAR(51)
);

هنا عندي DEP_HERE احفظ فيه اسم القسم او المكتب وفي الحقل DEP_STR اعرض اسم القسم او المكتب من جدول اخر

هذه الميزة لا توجد الا في فايربيرد لان قواعد البيانات الاخرى تحتاج الى استخدام Function لاجل ذلك

وهذه الميزة تعمل مثل الاستعلامات المترابطة Views ولكن تجعل من الممكن التعديل على الجدول بعكس استخدام View
وهي تعمل مثل حقول Calculated او lookup في دلفي

ملاحظة قد لا تكون هذه الطريقة مفيدة عند استخدامها على سيرفر للعديد من المستخدمين ولكثير من البيانات لان هذه الطريقة سيتم تنفيذها بجانب السيرفر وليس العميل