Ibland blir det nödvändigt att överföra en SQL -databas från en SQL -server till en annan. Datamigrationsprocessen består vanligtvis av att säkerhetskopiera databasen och återställa den till en annan SQL -server. Det verkar dock som att vid en så enkel operation kan alla slags svårigheter uppstå. I den här artikeln kommer vi att försöka hantera några av dem.
1. Om det redan finns en databas med samma namn
Om det under databasöverföringen visar sig att en databas med samma namn redan finns, eller om det uppstår ett fel om att en databasfil med samma namn redan finns, måste du manuellt ange det nya databasnamnet och / eller mappen där de fysiska filerna kommer att finnas. DB. Detta kan göras i SQL Server Managment Studio genom att ange ett nytt databasnamn under återställning på fliken Allmänt
och mappen där databasfilerna ska placeras (fliken Filer)
2. Överföring av Alta-GTD-databasen tillsammans med ytterligare ED-databaser
Om du vill överföra Alta-GTD-databasen tillsammans med ytterligare ED-databaser måste du:
1. Skapa en säkerhetskopia av databasen tillsammans med ytterligare databaser med hjälp av Alta-GTD-programmet. För att göra detta är det nödvändigt att köra Service - SQL Administrator - Backup SQL -databas och sedan svara bekräftande på frågan om behovet av att säkerhetskopiera ytterligare ED -databaser. När operationen för att skapa säkerhetskopior av ytterligare databaser är klar kommer programmet att visa ett informationsfönster med en beskrivning av alla skapade säkerhetskopieringsfiler. Dessa filer, liksom säkerhetskopieringsfilen för produktionsdatabasen, måste överföras till en annan SQL -server.
2. Återställ databaser från säkerhetskopior. Om servern redan har en databas med samma namn måste den återställas med ett annat namn (se avsnitt 1).
3. Om arbetsdatabasen byts namn under återställning är det nödvändigt att köra skriptet för alla ytterligare databaser:
UPDATE [Add_Base_Name] .. SET = " [e -postskyddad] Primary_Base_Name "
4. Om en eller flera ytterligare databaser bytt namn under återställning är det nödvändigt att köra skriptet för var och en av dem
UPDATE [Main_Base_Name] .. SET = "New_And_Base_Name" WHERE = "Old_And_Base_Name"
Från författaren: nyligen kom släktingar på besök. Så på ett par dagar tog de först ut hela matbasen, sedan "slog ut" hela den nervösa och slutligen brände musiken (musikcenter). I allmänhet beslutade jag mig för att snabbt överföra MySQL -databasen. Om du också befinner dig i en sådan situation, läs den här artikeln.
Snabbt sätt att exportera
Låt oss börja med en översikt över phpMyAdmin. För att överföra en bas måste du först skapa en kopia av den. För detta har programmet en speciell funktionalitet. Låt oss överväga denna process i detalj:
Du kan först välja önskad bas i listan till vänster och sedan gå till fliken "Exportera". Om du använder det här alternativet migreras MySQL per tabell. För att göra detta, ställ in "Normal" i "Exportmetod" och välj exportobjekten i "Tabeller".
Om du vill exportera hela databasen (med alla tabeller) går du omedelbart till "Export". Bara här arbetar vi redan inte med bord, utan med baser. I "Exportmetoden" ställer du också in "Normal". Välj sedan önskad databas och välj alternativet "Spara utdata till fil" i avsnittet "Utdata".
Nästa steg är att ange i vilket format kopian av databasen ska sparas. Vi väljer värdet "SQL" i motsvarande lista. Detta säkerställer att kopian kan användas på de flesta plattformar. Men om du ska överföra databasen till en specifik grund, här kan du välja lämpligt format: PHP -array, CSV, PDF och andra.
Nedan i avsnitten "Formatparametrar" och "Datasparparametrar" kan du konfigurera fler "" parametrar för överföring av MySQL -databasen. Men vi kommer inte att stanna vid deras granskning i detalj. Om du inte känner till någon av dem är det bäst att inte (onödigt) ändra standardvärdena. Här kan du konfigurera maximal kompatibilitet med äldre versioner av DBMS och hur tabellerna ska sparas. Endast data eller strukturer kan exporteras. Vi kommer att kopiera tabellerna i sin helhet (struktur och datalternativ).
När du har ställt in alla parametrar för att skapa en kopia av databasen klickar du på "OK" längst ner. Som ett resultat får vi en dubblettdatabas som enkelt kan överföras till en annan server. Som standard sparas den genererade filen i din webbläsares nedladdningsmapp.
Vi importerar
Med phpMyAdmin kan du inte bara skapa kopior av hela servern, databaser och enskilda tabeller. Med programmet kan du enkelt överföra MySQL -data till en annan instans av DBMS. Denna process liknar mycket att exportera en databas. phpMyAdmin kan ansluta både separata tabeller till databasen och flera databaser till servern samtidigt. Om du vill bifoga tabeller till vänster i listan väljer du önskad bas och går sedan till fliken "Importera".
För att ansluta en bas (eller flera baser) till servern, gå omedelbart till den angivna fliken. Markera sedan objektet "Bläddra i din dator" i avsnittet "Fil som ska importeras" och ange platsen för databasfilen genom utforskaren.
Här måste du ange vilken kodning som data i den importerade källan presenteras i. Du bör vara försiktig med denna parameter, annars får du riktiga "hieroglyfer" istället för rader i tabellerna, och du måste anlita en inhemsk japan eller kines för att dechiffrera dem. Och med dem i vårt område - ett verkligt underskott.
Den vanligaste kodningen är UTF-8, som är inställd som standard. Därför, även om du inte vet exakt vilken som används i den bärbara MySQL -databasen, är det värt att prova denna kodning. I vilket fall som helst kan du alltid ta bort den importerade basen och sedan "ladda upp den" igen med en annan kodning.
Jag skyndar mig också att uppröra de "nitiska" fansen av phpMyAdmin. Detta verktyg är endast lämpligt för export-import av små databaser (upp till 2 "meter"). Detta värde är tillräckligt för en delvis (fasad) serveröverföring, vilket kan vara obekvämt och försena hela processen under lång tid.
I avsnittet "Format" anger du värdet "SQL". Om det behövs aktiverar du kompatibilitetsläget. Och inaktivera också automatisk skapande av ett nyckelvärde för kolumner med ett nollvärde (beror på strukturen för de importerade källtabellerna). Och för att slutföra importen, klicka på "Ok".
Om du ska överföra MySQL -databasen från säkerhetskopian, glöm inte att ta bort den "ursprungliga" källan från servern innan du påbörjar importen. Annars får du ett felmeddelande eftersom denna databas redan finns.
Om processen lyckades visar programsystemet ett motsvarande meddelande.
Alternativ programvara
Jag lovade att presentera dig för olika DBMS -administrationsprogram när du lär dig MySQL. Så du kan utöka dina "professionella" horisonter och välja det program som bäst passar dina behov och typ av aktivitet.
Idag kommer vi att testa portabilitet av MySQL med hjälp av en kraftfull, funktionsrik applikation som utvecklats av utvecklarna av DBMS. Du kan ladda ner MySQL Workbench från företagets officiella resurs. Flera tredje parts distributioner (och länkar till dem) som kommer att krävas för att administrera DBMS med denna plattform beskrivs också i detalj.
Jag kommer att upprepa igen: verktyget i fråga har kraftfull funktionalitet, så vi kommer bara att överväga den som är utformad för att importera och exportera enskilda databaser i SQL -format. För att göra detta, starta programmet, klicka på ikonen för önskad anslutning (om det finns flera av dem).
I det nya öppnade fönstret till vänster i panelen "Navigator" väljer du önskad flik (för export eller import). Jag importerar en dubblettdatabas som skapats med phpMyAdmin.
För att överföra MySQL -data, gå igenom objektet "Dataimport". På fliken med samma namn i avsnittet "Importalternativ" väljer du det andra alternativet (anges på bilden).
Eftersom vi inte har några scheman klickar vi längst ner på "Starta import". Nästa flik "Importera framsteg" visar status för överföringen av den angivna filen. Detta alternativ kan vara praktiskt vid import av stora mängder data.
Efter slutet av MySQL -migrering visas db1 i listan över databaser, vars dubblett vi har skapat med phpMyAdmin.
Tja, medan jag "gömde" min MySQL -databas lämnade alla mina släktingar. Eftersom jag var upptagen, och det fanns ingen att fylla på matbasen i kylskåpet. Så här räddade min favorit DBMS mig från en "relaterad" olycka. För vilket stort tack till henne.
Många undrade hur man överför skript från en MySQL -databas till en annan värd. Så jag skrev i den här artikeln hur du överför din databas med SSH / telnet och PHPMyAdmin "a.
Om du har telnet- eller SSH -åtkomst till båda servrarna kommer sekvensen av dina åtgärder att vara följande:
Gå till källservern via telnet / SSH. Exportera innehållet i din databas med följande kommando:
mysqldump -uYourLogin -pYourpassword _mysql YourDatabase> baza.sql
Efter att ha utfört detta kommando kommer allt innehåll i din databas att sparas i filen baza.sql.
Sedan måste du ladda upp den resulterande filen med din databas till mottagarservern. Detta kan göras i samma telnet / SSH -session med ftp -kommandot, eller med någon klient du föredrar (ladda ner filen baza.sql till din dator och ladda sedan upp den till mottagarservern). När din databasfil finns på mottagarens server går du till den här servern via telnet / SSH. Du kan ladda upp din databas till mottagarservern genom att köra följande kommando:
mysql -uYourLogin -pYourpassword _mysql YourDatabase< baza.sql
(lösenord och inloggningar och namn på databaser, naturligtvis måste du ange giltig för mottagarservern). Som ett resultat kommer du att överföra din databas från en server till en annan, utan förlust.
Tekniken som beskrivs ovan kan användas i fall där du har tillgång till båda servrarna via telnet eller SSH och i fall där din databas är tillräckligt stor (flera tiotusentals poster). I de fall där du inte har tillgång till servrarna (eller en av dem) via telnet eller SSH, eller om du inte vet hur du arbetar i en Unix -kommandomiljö och använder en telnet- eller SSH -klient, kan du använda följande teknik:
På källservern går du till skriptet för att arbeta med MySQL -databaser (som regel är detta PHPMyAdmin). Välj den databas som är avsedd för överföring och ange i dess egenskaper "Visa databasen (schema) för databasen" (Det bör noteras att de specifika namnen på menyalternativen kan skilja sig från de som nämns här på grund av att olika versioner av programmet kan användas på olika servrar, och därför är det mycket lämpligt att bekanta sig med relevant dokumentation). Markera kryssrutorna du behöver: "Endast struktur", "Struktur och data", "Endast data" och markera posten "Skicka". När du klickar på "Gå" -knappen efter ett tag kommer du att bli ombedd att ladda ner en fil - detta är innehållet i din databas. När filen laddas ner till din dator.
Du har en MS SQL Server -databas som du behöver överföra till en annan fysisk dator. Du har redan gjort en säkerhetskopia och börjar gärna återställa. Men sedan visar det sig att en äldre version av MS SQL Server är installerad på datorn där du behöver överföra databasen. Stack Overflow försäkrar dig om att det är dåligt. Men är det verkligen så?
Att överföra en databas från en nyare version till en gammal är naturligtvis inte ett klassiskt och inte det mest korrekta scenariot. Men ofta skapas databaser på ett sådant sätt att de stöder fler och fler nya versioner av SQL, som börjar med några, till exempel 2008 R2, sedan Framåtkompatibilitet med MS SQL är mer än utmärkt. Till exempel har din klient redan installerat MS SQL 2016 för sig själv, och du har MS SQL 2014 på testservern för utveckling. Och du vill distribuera en klientdatabas för att ta reda på var han har dataförvirring.
Microsoft förnekade problemet - de säger att de inte har någon bakåtkompatibilitet, och det är det. En säkerhetskopia som skapats på en nyare server kan inte återställas till en äldre server. Ja, de har verktyg som DTS, databaskopiering, export-import, etc. Men de är så obekväma och besvärliga att normal överföring av en stor databas med många tabeller inte är särskilt bekvämt att göra med deras hjälp. Jag lyckades i alla fall inte personligen.
Ja, du kan generera SQL -skript för hela databasen, inklusive data. Men tänk, du har ett gäng blobfält med stora data i din databas, och i allmänhet är storleken på hela databasen 500+ GB. Tänk hur lång tid ett sådant skript kommer att ta, hur lång tid det tar att generera och köra.
Begränsning nummer ett är att du behöver åtkomst via MS SQL Management Studio till både servrar - gamla och nya. Om detta inte är möjligt bör det vara möjligt på den dator från vilken du behöver överföra databasen, installera den version av SQL som du behöver överföra databasen till för att överföra databasen först till den här versionen lokalt och dra den sedan genom säkerhetskopian eller direkt via * df databasfiler (via Lossa / Bifoga) till den nya maskinen (versionen av SQL Server "och i det här fallet kommer den redan att vara densamma).
En annan begränsning är att du behöver ett databasschemaskript (alla objekt, inklusive tabeller, index, begränsningar, lagrade procedurer, utlösare, etc.) utan data, och instruktionerna för att skapa främmande nyckelbegränsningar i detta skript måste gå till slutet , separat från skriptet för att skapa tabellerna själva.
Jag kommer att kort beskriva själva dataöverföringsalgoritmen. Alla åtgärder utförs i Management Studio -sessionen ansluten till servern, på vilken du måste överföra basen.
1) På den nya servern skapar du en tom databas med samma filer och filgrupper som den bärbara databasen.
2) Med hjälp av databasschemaskriptet skapar vi alla databasobjekt (tabeller, index, vyer, triggers, lagrade procedurer och funktioner), men utan att skapa främmande nyckelbegränsningar. Du kan inte skapa ett FK i detta skede, eftersom de kommer att störa datainmatning.
3) Vi ansluter databasen från vilken vi kommer att överföra data, som en länkad server, så att vi kan använda samtal till den gamla databasen i frågor till den nya databasen.
EXEC sp_addlinkedserver @ server = N "LinkedServerAlias", @ srvproduct = N "", @ provider = N "SQLNCLI", @ datasrc = N "LinkedServerHost \ LinkedServerName"; EXEC sp_addlinkedsrvlogin "LinkedServerUser", "false", null, "RealUser", "RealUserPassword";
4) Eftersom databasstrukturerna är desamma, vi använder den inbyggda lagrade proceduren sp_msforeachtable, som låter dig utföra en fråga på varje databastabell för att generera ett skript för att överföra data från den gamla databasen till en ny genom en fråga om formen
SÄTT IN I? VÄLJ FRÅN?
I stället för ett frågetecken ersätter sp_msforeachtable namnet på varje tabell och kör frågan flera gånger (en gång för varje tabell).
Här stötte jag på det största antalet krattor.
A) Problem nummer ett är att för tabeller med IDENTITY -fält måste du ringa:
STÄLL IDENTITY_INSERT PÅ; --INSERT I ... (infoga sig själv); SET IDENTITY_INSERT OFF;
b) Problem nummer två är att detta samtal inte kan göras på tabeller som inte har IDENTITY -fält, därför krävs det dynamiskt att avgöra om det finns en IDENITY -kolumn i tabellen eller inte.
Detta kan göras med följande fråga:
VÄLJ * FRÅN INFORMATION_SCHEMA.COLUMNS WHERE (TABLE_NAME = "SomeTable") OCH (COLUMNPROPERTY (object_id ("dbo.SomeTable"), COLUMN_NAME, "IsIdentity") = 1)
c) Problem nummer tre är att, som det visade sig, i IDENITY_INSERT ON -läget du inte kan göra
SÄTT IN I ... VÄLJ * FRÅN ...
, men du måste lista specifika fält.
Du kan räkna upp tabellfälten i rad med följande fråga:
SELECT SUBSTRING ((SELECT "," + QUOTENAME (COLUMN_NAME) FRÅN INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = "SomeTable" ORDER BY ORDINAL_POSITION FOR XML path ("")), 3, 200000);
4) Skapa ett infogningsskript för alla tabeller:
Skriptgenereringsprocedur
EXEC sp_msforeachtable N "DECLARE @command varchar (MAX); DECLARE @name varchar (200); SET @name =" "?" "; SET @name = SUBSTRING (@name, 8, LEN (@name) -8); SET @command = "" ""; SELECT @command = SUBSTRING ((SELECT "", "" + QUOTENAME (COLUMN_NAME) FRÅN INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = "" "" + @name + "" "" ORDER BY ORDINAL_POSITION FOR XML -sökväg ("" "")), 3, 200000); SET @command = "" INSERT INTO "" + @name + "" ("" + @command + "") SELECT "" + @command + "" FRÅN "" + "" LinkedServerAlias.SourceDatabase. "" + ""? ""; SET @ command = "" IF EXITTS (välj * från INFORMATION_SCHEMA.COLUMNS där (TABLE_NAME = "" "" "" + @Name + "" "" "") OCH (COLUMNPROPERTY (object_id ("" "" dbo. "" [e -postskyddad]+ "" "" ""), COLUMN_NAME, "" "" IsIdentity "" "")) = 1)) SET IDENTITY_INSERT "" + @name + "" ON; "" [e -postskyddad]; UPPSÄTTNING @ [e -postskyddad]+ ""; "" " . "" [e -postskyddad]+ "" "" ""), COLUMN_NAME, "" "" IsIdentity "" "")) = 1)) SET IDENTITY_INSERT "" + @name + "" OFF; ""; UTSKRIFT (@kommando); --EXEC (@kommando); // Om det inte kommenteras kommer körningen att köras omedelbart, inte bara visas "
5) Utför det genererade dataöverföringsskriptet
6) Kör skriptet för att skapa alla främmande nyckelbegränsningar (nu kan du).
7) Klar! Du migrerade databasen från den nya SQL -servern till den gamla, även om den ansågs omöjlig. Dessutom utförs överföringen endast en och en halv gånger långsammare än dataöverföringshastigheten över nätverket, d.v.s. ganska snabbt.
8) Vi städar efter oss själva (inaktiverar länkad server):
EXEC sp_droplinkedsrvlogin "LinkedServerUser", null; sp_dropserver "LinkedServerAlias";
Begränsningar av metoden.
1) Denna metod fungerar inte för att överföra tabeller som har kolumner av XML -typ.
Visst finns det många andra begränsningar, tk. databasen som jag överförde på ett liknande sätt använde inte många av funktionerna i SQL -servern. Du kan skriva om begränsningarna i kommentarerna, så lägger jag till dem i artikeln.
Tack för uppmärksamheten! Hoppas det hjälper någon.
Med överföring av databasen menar vi proceduren för att byta server InterBase både i riktning mot att öka serienumret, och i riktning mot att minska det, samt byta till ett annat operativsystem eller hårdvaruplattform. Vissa källor hänvisar till databasöverföringsproceduren som migration.
För närvarande i versioner InterBase från 4.x till 6.x, och i den sjätte versionen kan databasen skapas på dialekt 1 eller i dialekt 3. I allmänhet kan övergången från den yngre versionen InterBase till den äldre versionen kräver inga speciella åtgärder, och databaserna fungerar bra, men användaren kan inte använda de ytterligare tjänster som tillhandahålls av den äldre versionen. Om databasöverföringsproceduren utförs kommer ytterligare tjänster att finnas tillgängliga. När det gäller dialekter av version 6.x tolkas vissa datatyper på olika sätt. Till exempel i tidigare versioner InterBase och i dialekt 1 version 6.x har en datumtyp definierats Datum, vars värde i början innehåller datumet och sedan tiden. I dialekt 3 version 6.x definieras tre typer - Tidsstämpel, som exakt matchar typen Datum, definieras i tidigare versioner; sorts Datum, som endast innehåller datumvärden och typen Tid, som innehåller tidsvärden.
När du utför databasöverföringsproceduren utförs automatiskt datumtypen endast i definitionerna domäner. Datumtyp i metadata ersätts manuellt.
Varje operativsystem tolkar varje datatyp på sitt eget sätt. När du installerar servern InterBase vilken version som helst, är den konfigurerad för lämpligt operativsystem och hårdvarumiljö.
Varje databas är således "bunden" till serverversionen InterBase, till operativsystemet och hårdvarumiljön.
Detta förklarar behovet av att utföra proceduren för databasöverföring.
Av ovanstående blir det klart att skapa en databasbackup med alternativet Transportabelt gör att versionsinformation inkluderas i säkerhetskopian InterBase operativsystemet och hårdvarumiljön där databasen skapades och drivs.
Vid överföring av en databas till en annan persondator, servern InterBase läser säkerhetskopian och omvandlar datatyper om det behövs och gör inställningar för den nya versionen InterBase operativsystem och hårdvarumiljö.
Man bör komma ihåg att det bara är möjligt att uppgradera till nästa version i ordning. InterBase i både stigande och fallande riktning.
När du överför en databas två eller tre versioner högre (eller lägre) måste du utföra överföringsproceduren för varje mellanliggande versioner ІМегВазе.
För att ändra dialekten (till exempel från den första till den tredje) måste du antingen återskapa databasen eller använda verktyget y / іх.
Algoritm för databasöverföringsproceduren
a. Skapa en databas backup -fil. Filen skapas på ett av de sätt som diskuteras ovan. Det är lämpligt att kontrollera om säkerhetskopian skapades korrekt. För att göra detta, distribuera databasen i en annan katalog på samma persondator och kontrollera dess funktion.
b. Skapa en kopieringsfil av registrerade användare på servern InterBase. Kom ihåg att användarinformation lagras i filen isc4.gdb på servern InterBase och i själva databasen. För att kopiera en fil iscA.gdb du kan använda samma verktyg gbak.
Exempel 12.7. Kopierar filen för registrerade användare av databasen.
gbak -b -användare SYSDBA -lösenord huvudnyckel C: IBServeisc4.gdb C: isc4.gdk
v. Installera om servern InterBase eller byta till en annan persondator. Efter att du har installerat om servern på en persondator (eller bytt till en annan persondator) behöver du filen iscA.gdbåterställa med samma verktyg gbak.
Det är viktigt att komma ihåg att när du uppgraderar till en högre version InterBase alla kunder registrerade i nästa lägre version InterBase, kommer att fungera bra (men utan ytterligare funktioner), och i äldre - instabilt.
För sådana klienter är det lämpligt att installera om klientdelen InterBase på klienters persondatorer.
Exempel 12.8.Överföring av filen för registrerade användare av databasen.
gbak -с -användare SYSDBA -lösenord huvudnyckel C: isc4.gdk C: isc4.gdb
Exempel 12.7 och 12.8 innebär att versionen byts ut InterBase på en dator.
d. Återställ (överför) databasen med en av metoderna som beskrivs ovan.
Ovanstående algoritm fungerar tillförlitligt vid uppgradering av versionen InterBase. Om du behöver sänka versionsnumret InterBase, då måste du ha två persondatorer för att utföra denna operation: den första - med en fungerande databas på en äldre version InterBase, den andra - med den installerade servern InterBase lägre version. Vi startar proceduren för att skapa en säkerhetskopia av databasen (punkt "a" av algoritmen) från den andra datorn. Detta skapar en lägre version av säkerhetskopian. Men följande alternativ är möjliga:
- i den äldre versionen InterBase under skapandet och driften av databasen användes inte mekanismer som saknas i den yngre versionen InterBase, då kommer en fullständig arbetskopia av databasen i den mindre versionen att skapas InterBase ",
- databasen använde de ursprungliga mekanismerna i den äldre versionen InterBase, då kommer en kopia av databasen och en logg över hittade fel att erhållas. Och fel i att knappt återställa databasen i den lägre versionen InterBase måste fixa manuellt.
För tillförlitlig drift av databasen är det nödvändigt att tillhandahålla samma version och dialekt av servern InterBase och klientsidan InterBase varje klient.
Kunder i alla versioner InterBase, till skillnad från klienter som arbetar med dialekt 3 version 6.x, har inte tillgång till:
Till nyckelord:
CURRENTDATE CURRENTTIME CURRENT_ TIMESTAMP COLUMN
TIDSSTÄMPEL
Till citerade identifierare.
