अलग-अलग नामों वाली दो तालिकाओं के बीच प्रतिकृति और जिनके अलग-अलग कॉलम नाम हैं। क्या ऐसी प्रतिकृति बनाना संभव है

जाहिर है, इसका उत्तर है:"जब आप लेख को परिभाषित करते हैं, तो आपको @vertical_partition सेट करना होगा। पैरामीटर को सही पर सेट करें और फिर sp_articlecolumn . के साथ इच्छित कॉलम जोड़ें ।"

हालांकि, मुझे पूछना है कि आप ऐसा क्यों कर रहे हैं। मेरे दिमाग में प्रतिकृति विपरीत डेटाबेस के बीच डेटा को स्थानांतरित करने के लिए एक सामान्य उपकरण नहीं है बल्कि दो समान डेटाबेस को सिंक में रखने के लिए है।

अन्य विचार मंथन विचार:

आप एक नई स्रोत तालिका बना सकते हैं जो गंतव्य तालिका से मेल खाती हो, और स्रोत तालिका को सिंक्रनाइज़ रखने के लिए ट्रिगर का उपयोग करें।
स्रोत तालिका को गंतव्य तक अक्षुण्ण रखें और गंतव्य डेटाबेस में MERGE करें।
प्रतिकृति वास्तव में यहां सही समाधान नहीं हो सकता है। व्यावसायिक नियम और आवश्यकताएं क्या हैं जो इसे करने के लिए कह रही हैं? क्या आपने एसएसआईएस का उपयोग करने पर विचार किया है?
यदि दो तालिकाओं को हर समय सटीक सिंक्रनाइज़ेशन में रहने की आवश्यकता है, तो स्रोत तालिका में परिवर्तन का चैनल क्या है - एक अनुप्रयोग? ऐसा लगता है कि आपके एप्लिकेशन को अबास्ट्रक्शन के एक नए स्तर की आवश्यकता है, एक डेटा लेखन परत जो एक ही समय में दो स्रोतों को लिखना जानता है।

दो अलग-अलग डेटाबेस के बीच डेटा को सिंक्रोनाइज़ करने की कोशिश करना एक समस्या हो सकती है। दौड़ की स्थिति, वितरित लेनदेन की कमी (विफलताओं की स्थिरता और प्रतिक्रिया को प्रभावित करना), वितरित लेनदेन नहीं होने से निपटने के लिए बनाए गए वर्कअराउंड के साथ समस्याएं, और इसी तरह के साथ सभी प्रकार की सूक्ष्म समस्याएं हो सकती हैं। क्या आप इसके बजाय एक लिंक किया गया सर्वर और कुछ दृश्य बना सकते हैं जो वास्तव में एक डेटाबेस में डेटा को दूसरे से रीयल-टाइम एक्सेस करते हैं?

कृपया हमें अपनी आवश्यकताओं के बारे में और बताएं कि आपको ऐसा करने की आवश्यकता क्यों है।

अपडेट करें

यदि आप मैन्युअल अपडेट रूट पर जा रहे हैं, तो ध्यान दें कि आप एक समय अवधि के इंसर्ट, अपडेट और ऑपरेशन को सामूहिक रूप से लागू नहीं कर सकते। आपको उन्हें एक-एक करके लागू करना होगा, क्रम में . अगर आप इसके बजाय वर्तमान स्थिति . के साथ काम कर रहे हैं इंटरमीडिएट डेटा ऑपरेशंस के बजाय, आप सभी पंक्तियों को एक साथ कर सकते हैं। मैं आपको MERGE उदाहरण दिखाऊंगा, न कि इतिहास-प्लेबैक वाला।

BEGIN TRAN;

DELETE D
FROM LinkedServer.dbo.Dest D WITH (TABLOCKX, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM Source S
      WHERE D.Key = S.Key
   );

UPDATE D
SET
   D.Col1 = S.Col4,
   D.Col2 = S.Col5,
   D.Col3 = S.Col6,
   D.Col4 = S.Col7,
FROM
   LinkedServer.dbo.Dest D
   INNER JOIN Source S ON D.Key = S.Key
WHERE
   D.Col1 <> S.Col4
   OR EXISTS (
      SELECT D.Col2, D.Col4
      EXCEPT
      SELECT S.Col3, S.Col6
   ); -- or some other way to handle comparison of nullable columns

INSERT LinkedServer.dbo.Dest (Col1, Col2, Col3)
SELECT Col4, Col5, Col6
FROM Source S WITH (TABLOCK, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM LinkedServer.dbo.Dest D
      WHERE S.Key = D.Key
   );

COMMIT TRAN;

आपको पूरी तालिका को पुश करना और गंतव्य सर्वर पर मर्ज ऑपरेशन करना बेहतर लगेगा।

यदि आपके पास एक सुसंगत पॉइंट-इन-टाइम स्नैपशॉट होने जा रहा है, तो मैंने पहली क्वेरी में जो लॉक संकेत दिए हैं, वे महत्वपूर्ण हैं। अगर आपको इसकी परवाह नहीं है, तो लॉक करने के संकेत निकाल लें.

यदि आप पाते हैं कि लिंक किए गए सर्वर पर अपडेट धीमे हैं, तो संपूर्ण तालिका को एक टुकड़े में दूरस्थ सर्वर पर एक अस्थायी स्टेजिंग तालिका में धकेलें, और MERGE को पूरी तरह से दूरस्थ सर्वर पर एक स्क्रिप्ट में करें।