هجرة SQL Server 2016 إلى PostgreSQL على VPS

‏تنص سياسة دورة الحياة لدى ‏Microsoft على عشر سنوات من الدعم لكل إصدار من ‏SQL Server‏: خمس سنوات دعم عادي ثم خمس سنوات دعم ممتد. بالنسبة لـ ‏SQL Server 2016، انتهى الدعم الممتد في 14 يوليو 2026. بعد هذا التاريخ، لا تُصدر ‏Microsoft أي تحديثات أمنية أو إصلاحات حرجة لهذا الإصدار. يتراكم على أي خادم ‏SQL Server 2016 متصل بالشبكة بعد هذا التاريخ ثغرات أمنية غير مسدودة. تشترط المتطلبات التنظيمية — ‏PCI-DSS‏ و‏GDPR‏ و‏ISO 27001 — عموماً أن تتلقى مكونات البنية التحتية التحديثات الأمنية المتاحة. وبالتالي فإن الاستمرار على ‏SQL Server 2016 بعد يوليو 2026 يُعدّ انحرافاً موثقاً قابلاً للرصد في أي تدقيق.

‏قبل كتابة أي أمر للهجرة، لا بد من تدقيق الهيكل. العناصر التي تُهاجَر دون عائق: الجداول البسيطة ذات الأنواع المعيارية، وقيود ‏PRIMARY KEY وFOREIGN KEY وUNIQUE وNOT NULL، والمؤشرات من نوع ‏B-tree، والعروض الخالية من صياغة ‏T-SQL الخاصة، والتسلسلات. العناصر التي تستلزم عملاً صريحاً: الإجراءات المخزنة ودوال ‏T-SQL (صياغة غير متوافقة، يجب إعادة كتابتها بـ ‏PL/pgSQL أو نقلها إلى طبقة التطبيق)، والمحفزات التي تستخدم الجداول الوهمية ‏INSERTED وDELETED (المقابل في ‏PostgreSQL‏: ‏NEW وOLD)، وأعمدة ‏ROWVERSION/TIMESTAMP المستخدمة لاكتشاف التزامن التفاؤلي، والأعمدة المحسوبة، وتلميحات القفل (‏WITH (NOLOCK) و‏WITH (UPDLOCK))، والجداول المؤقتة العامة (‏##temp). يمكن الحصول على قائمة كاملة بعناصر ‏SQL Server عبر استعلام ‏INFORMATION_SCHEMA وعروض النظام ‏sys‎.objects وsys‎.procedures وsys‎.triggers.

‏ثمة بنى ‏T-SQL شائعة لا مقابل مباشر لها في ‏SQL المعياري وتستلزم إعادة كتابة.

‏TOP N بدون ORDER BY‏: يقبل ‏SQL Server ‏SELECT TOP 10 * FROM t بلا ترتيب. يستلزم ‏PostgreSQL استخدام ‏LIMIT 10؛ وإن كان الترتيب مهماً فأضف ‏ORDER BY صريحاً.

‏ISNULL(expr, value)‏: تقابلها الدالة المعيارية ‏COALESCE(expr, value). السلوك متطابق للحالات الشائعة.

‏GETDATE()‎ و‏GETUTCDATE()‎‏: تصبحان ‏NOW()‎ (طابع زمني مع منطقة الجلسة) و‏NOW() AT TIME ZONE 'UTC'‎ أو ‏CURRENT_TIMESTAMP على التوالي.

‏DATEDIFF و‏DATEADD‏: يستخدم ‏PostgreSQL حساب الفترات: ‏date + INTERVAL '7 days'‎، ويُرجع ‏date2 - date1 قيمة ‏INTERVAL.

‏تلميح ‏WITH (NOLOCK)‏: يطلب هذا التلميح قراءة بلا قفل مشترك. لا يدعم ‏PostgreSQL هذا التلميح؛ يغطي مستوى عزل ‏READ COMMITTED (الافتراضي) معظم حالات الاستخدام. لتقارير التحليل التي تتحمل بيانات قديمة قليلاً، النسخة المتماثلة للقراءة هي الحل البنيوي.

‏PRINT في الإجراءات: استخدم ‏RAISE NOTICE 'message'‎ في ‏PL/pgSQL.

‏GO كفاصل دُفعات: لا وجود لهذا الفاصل في ‏PostgreSQL؛ يجب إعادة هيكلة السكريبتات إلى معاملات أو كتل ‏DO $$...$$‎ منفصلة.

‏التثبيت الافتراضي لـ ‏PostgreSQL غير مضبوط للإنتاج. المعاملات التالية في ‏postgresql‎.conf هي نقطة انطلاق لـ ‏VPS بذاكرة 4 ‏GB.

‏shared_buffers‏: اضبطها على 25% من الذاكرة المتاحة، أي ‏1GB لـ 4 ‏GB. يحدد هذا المعامل الذاكرة المخصصة للذاكرة المؤقتة الداخلية لـ ‏PostgreSQL.

‏effective_cache_size‏: اضبطها على 75% من إجمالي الذاكرة، أي ‏3GB. يُعلم هذا المعامل مُخطِّط الاستعلامات بالذاكرة المتاحة لذاكرة نظام التشغيل المؤقتة.

‏work_mem‏: من ‏16MB إلى ‏64MB حسب تعقيد استعلامات الترتيب. يُطبَّق هذا المعامل لكل عملية ترتيب ولكل اتصال؛ قيمة مرتفعة جداً على خادم يحمل اتصالات متزامنة كثيرة تُنهك الذاكرة.

‏maintenance_work_mem‏: ‏256MB لعمليات الصيانة (‏VACUUM وCREATE INDEX).

‏max_connections‏: ‏100 كافٍ لمعظم التطبيقات التي تستخدم مجمّع اتصالات. إن كان التطبيق يفتح اتصالاً لكل طلب بلا مجمّع، استخدم ‏PgBouncer أمامه.

‏في ‏pg_hba‎.conf‏، اقصر الاتصالات البعيدة على عنوان ‏IP خادم التطبيق واشترط ‏TLS‏: ‏hostssl all appuser 10.0.0.5/32 scram-sha-256.

‏فعّل ‏TLS بتوليد شهادة (‏Let's Encrypt أو شهادة داخلية) وضبط ‏ssl = on وssl_cert_file وssl_key_file في ‏postgresql‎.conf.

‏الإجراءات المخزنة بـ ‏T-SQL هي نقطة الاحتكاك الرئيسية في الهجرة من ‏SQL Server إلى ‏PostgreSQL. ‏T-SQL لهجة خاصة بهياكل تحكم ومعالجة مؤشرات ومعالجة أخطاء (كتل ‏TRY..‎.CATCH) لا مقابل مباشر لها في ‏PL/pgSQL.

‏مؤشرات ‏FAST_FORWARD في ‏SQL Server تصبح حلقات ‏FOR في ‏PL/pgSQL، لكن الأداء مماثل ويجب في كل الأحوال التساؤل عن ضرورة المؤشرات: الاستعلام المبني على مجموعات البيانات يحل محل المؤشر بشكل أكثر كفاءة في الغالب.

‏كتلة ‏TRY..‎.CATCH تصبح ‏BEGIN..‎.EXCEPTION WHEN OTHERS THEN في ‏PL/pgSQL.

‏الجداول المؤقتة المحلية (‏#temp) تقابلها الجداول المؤقتة للجلسة في ‏PostgreSQL المنشأة بـ ‏CREATE TEMPORARY TABLE. الجداول المؤقتة العامة (‏##temp) لا مقابل مباشر لها — يجب استبدالها بجداول دائمة مع إدارة صريحة لدورة الحياة.

‏المحفزات التي تُشير إلى ‏INSERTED وDELETED (الجداول الوهمية في ‏SQL Server) يجب إعادة كتابتها لاستخدام ‏NEW وOLD في ‏PostgreSQL. هيكل التشغيل يختلف أيضاً: يُميز ‏PostgreSQL بين محفزات ‏BEFORE وAFTER، وبين ‏FOR EACH ROW وFOR EACH STATEMENT.

‏نهج عملي يقضي بنقل منطق الإجراءات المخزنة إلى طبقة التطبيق أثناء الهجرة، مما يبسّط الاختبار ويقلل الارتباط بين التطبيق وقاعدة البيانات.

‏ثمة فئات من الأخطاء تتكرر بانتظام في الهجرات الأولى.

‏ERROR: column is of type uuid but expression is of type character varying‏: عمود ‏UNIQUEIDENTIFIER مُهاجَر إلى ‏UUID يتلقى سلسلة بتنسيق ‏UUID بلا تحويل صريح. كيّف استعلام التطبيق ليُرسل نوع ‏UUID حقيقياً، أو أضف تحويلاً ضمنياً في ‏PostgreSQL (‏CREATE CAST)، أو هاجر العمود إلى ‏TEXT إن لم تُستغل دلالات ‏UUID.

‏ERROR: operator does not exist: boolean = integer‏: عمود ‏BIT مُهاجَر إلى ‏BOOLEAN يُقارَن بـ ‏0 أو ‏1. استبدل ‏col = 1 بـ ‏col = true أو ببساطة ‏col في جمل ‏WHERE.

‏ERROR: function isnull(character varying, text) does not exist‏: استبدل جميع استدعاءات ‏ISNULL بـ ‏COALESCE.

‏ERROR: syntax error at or near "TOP"‏: صياغة ‏SELECT TOP N غير موجودة في ‏PostgreSQL. استبدلها بـ ‏SELECT ... LIMIT N.

‏تجاوزات صامتة على أعمدة ‏MONEY ← NUMERIC‏: تحقق من أن القيم القصوى في الجدول المصدر تتسع ضمن الدقة المستهدفة ‏NUMERIC(19,4). نطاق ‏MONEY في ‏SQL Server هو ‏±922,337,203,685,477.5807؛ يغطي ‏NUMERIC(19,4) النطاق ‏±999,999,999,999,999.9999، وهو كافٍ في جميع الحالات تقريباً.

‏فقدان بيانات على أعمدة ‏DATETIME بلا منطقة زمنية: ‏DATETIME وDATETIME2 في ‏SQL Server لا يخزنان المنطقة الزمنية. إن كانت قاعدة البيانات تُغذَّى من تطبيقات في مناطق زمنية متعددة، ستُفسَّر الطوابع الزمنية المُهاجَرة إلى ‏TIMESTAMPTZ بلا تحويل سابق على أنها ‏UTC. حدد اتفاقية (‏UTC أو التوقيت المحلي) وطبّق تحويل ‏AT TIME ZONE أثناء الهجرة إن لزم.

‏بعد التبديل، تُقلل قائمة التحقق المنظمة من خطر إعادة المستخدمين إلى قاعدة بيانات ناقصة.

‏تحقق من عدد الصفوف لجميع الجداول الحرجة: استعلام على ‏information_schema‎.tables مع ‏COUNT(*)‎ لكل جدول، مقارنةً بالأرقام المسجلة من ‏SQL Server قبل الهجرة.

‏تحقق من النزاهة المرجعية: ‏SELECT * FROM pg_constraint WHERE contype = 'f'‎ يُدرج جميع قيود المفتاح الخارجي؛ حاول إدراجاً ينتهك قيداً للتأكد من فعاليتها.

‏تحقق من المؤشرات: ‏SELECT indexname, indexdef FROM pg_indexes WHERE schemaname = 'public'‎ يُدرج جميع المؤشرات المنشأة. قارنها بقائمة مؤشرات ‏SQL Server.

‏اختبر الوظائف الحرجة في التطبيق: مسار الشراء، والمصادقة، والتقارير، والتصدير — على الأقل المسارات التي تمس الجداول الأكثر حجماً والاستعلامات الأكثر تعقيداً.

‏راقب سجلات ‏PostgreSQL خلال الـ 24 ساعة الأولى: ‏tail -f /var/log/postgresql/postgresql-*‎.log‎. تظهر أخطاء عدم تطابق الأنواع ومهلات الاتصال وخطط الاستعلام دون المستوى الأمثل عادةً في الساعات الأولى من حركة المرور الحقيقية.

‏أبق ‏SQL Server في وضع القراءة فقط 48 ساعة مع تقييد الوصول للفريق التقني. التراجع يعني توجيه ‏DSN التطبيق مجدداً نحو ‏SQL Server وإعادة تشغيل البيانات المكتوبة في ‏PostgreSQL خلال نافذة التبديل.