Vi skulle flytta till en ny server. Den har SQL och 1C. I jämförelse med de gamla var det mycket svalare. Och Gilevs test bekräftade också detta: mot 10-15 på gamla servrar gav det 39. Därför, direkt efter köpet, överförde vi databasen och började arbeta.

Men någon gång gick något fel - användare började klaga på långsamt arbete. Vi gjorde vissa inställningar för servern och tjänsterna (som är ämnet för ett separat inlägg) och beslutade att starta om servern, eftersom omstartshastigheten är 2 minuter (på andra servrar var det upp till 10 minuter). Efter det, när vi går in i 1C, får vi följande meddelande:

"Uppmärksamhet!!! Ett fel uppstod vid uppdatering av data sedan den senaste omstruktureringen. Vill du försöka uppdateringen igen?" "Inte riktigt"

Efter att ha klickat på "Ja"-knappen visas följande:

En ofullständig konfigurationssparningsåtgärd upptäcktes. För att fortsätta arbeta måste du slutföra operationen."

Det första jag bestämde mig för att göra - CHECKDB på i Managment Studio - efter 2 timmars väntan (bas 500 GB) - är allt OK.

I det stora nätverket hittade jag information om att samma fel inträffar med dynamiska uppdateringar.

De lösningar som föreslagits på nätverket hjälpte inte direkt, men tillsammans med andra åtgärder gav de resultat. Så vad jag gjorde:

Lösning:

Vad saknades för lösningar från nätverket:

sp_configure 'tillåt uppdateringar', 1
konfigurera om med åsidosättande
gå

2. Vi överför databasen till återställningsläge

ändra databasuppsättning EMERGENCY, SINGLE_USER

3. Vi utför testning av basen:

dbcc checkdb ('db_name', REPAIR_ALLOW_DATA_LOSS)

4. Vi tar databasen ur återställningsläge:

ändra databasuppsättning ONLINE, MULTI_USER

5. I princip, om du är säker på att allt är ok med själva basen, så kan du hoppa över 2-4 poäng. Därefter kör vi två frågor i SQL-profileraren:

radera från config där filnamn = 'commit'
ta bort från config där filnamn = 'dbStruFinal'

Dessa poster är ansvariga för dynamisk uppdatering - du kan inte vara rädd för att radera dem.

I fungerande versioner av databaser, frågor:

välj * från Config WHERE FileName = 'commit'

välj * från Config WHERE FileName = 'dbStruFinal'

kommer att vara tom.

6.återställa inställningarna:

sp_configure 'tillåt uppdateringar', 0
gå

7. Efter det lyckades vi starta konfiguratorn och databasen började fungera.

Dessutom kan basen fungera efter att den första flaggan tagits bort.

Sandlåda

auktoritet 18 september 2013 klockan 15:24

1C, återställande av infobaskonfigurationen med MS SQL

Vid ett tillfälle stötte jag på ett problem: vid uppdatering av konfigurationen från förvaret inträffade ett fel och 1C stängdes.

Som det visade sig senare förstördes konfigurationsförrådet, och när konfigurationen uppdaterades flög även databaskonfigurationen från förvaret. Ett liknande fel inträffade tidigare med en dynamisk informationssäkerhetsuppdatering.

Eftersom Detta problem har uppstått mer än en gång. Jag bestämde mig för att dela ett behandlingsalternativ.

Vid nästa lansering av konfiguratorn uppstod ett fel: "Obs !!! Ett fel uppstod vid uppdatering av data sedan den senaste omstruktureringen. Vill du försöka uppdateringen igen?" om svaret är ja får vi meddelandet: "En ofullständig konfigurationslagring upptäcktes. För att fortsätta arbeta måste du slutföra operationen "varefter applikationen stängs.

Vid analys av detta problem fann man flera alternativ för att lösa problemet, varje lösning fungerar i olika fall.

Alternativ 1 (om du har en SQL-säkerhetskopia med en kopia med identisk konfiguration):

En kopia av informationssäkerheten distribueras och följande fråga exekveras:
ANVÄND GÅ DELETE FROM .. GÅ SÄTT IN I .. VÄLJ * FRÅN .. GÅ
I detta fall fylls tabellen i vilken IB-konfigurationen är lagrad på nytt. Det är tillrådligt att testa och korrigera informationssäkerheten efter denna operation.

Alternativ 2 (i avsaknad av säkerhetskopia):

Detta alternativ behandlades som droppen. Eftersom konfigurationen var under utveckling och säkerhetskopieringen glömdes bort lite, beroende på förvaret.
I databasen raderas två poster från "Config"-tabellen med värdet i kolumnen "FileName" - dbStruFinal och commit

Följande fråga exekveras:
ANVÄND GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "commit" GO
Konstigt nog vaknar basen till liv.

Taggar: 1c enterprise 8.2, SQL, konfigurationsåterställning

Den här artikeln kan inte kommenteras eftersom författaren ännu inte är en fullvärdig medlem av communityn. Du kommer att kunna kontakta författaren först efter att han har tagit emot

När du arbetar i 1C: Enterprise kan följande meddelande visas: "För att arbeta med den nya versionen av 1C: Enterprise måste infobasen konverteras." Varför visas det här fönstret och hur kan jag lösa felet?

I de flesta fall är anledningen till fönstrets utseende den senaste övergången av programmet från en föråldrad version av plattformen till en nyare. Olika plattformar informationsbas 1C bildas på sitt sätt och får en annan sammansättning. Allt som behöver göras är att konvertera databasen (vars struktur motsvarar den föråldrade plattformen) till det senaste formatet.

Databaskonvertering

Denna procedur är enkel, men först rekommenderas det att skapa en säkerhetskopia av databasen, om ett fel inträffar under konverteringen (till exempel stängs datorn av, som ett resultat informationsbas 1C, såväl som själva programmet, kan vara skadat). Använd sedan följande sekvens av åtgärder:

Öppna databasen i konfiguratorläget;
Du kommer att se ett meddelande som ber dig att konvertera infobasen. Klicka på bekräftelse;

Stäng konfiguratorn.

Öppna databasen - den bör starta utan problem. Om felfönstret fortsätter att visas efter konverteringen kan du prova proceduren igen. Om detta inte hjälper måste du kontakta 1C-programmeraren. Ibland kan programmet frysa när du utför en operation. Det finns ingen anledning att vidta några åtgärder för närvarande.

Viktig! Informationsbas 1C konverterad av den senaste versionen av programmet kan inte öppnas på tidigare versioner.

Bakgrund

Vi behövde skapa ett nytt "MessageTrackingLog"-informationsregister. Lades till i konfigurationen, laddade data. Sedan startade optimeringsarbetet. Jag var tvungen att ändra strukturen på registret. Men det var inte där!

Allt är klart här. Inläggen har blivit icke-unika, du måste ta bort dem!

Det enklaste sättet är:

NewRecord = InformationRegisters.MessageTrackingLogin.CreateRecordSet (); NewWrite.Write ();

Med denna metod kommer vi att rensa registret i 1C mycket snabbt (men detta kommer också att vara vårt misstag).

Fel

Det verkar som att registret är tomt och du kan uppdatera 1C. Jag vill inte överraska dig, men det kommer ett fel igen:

Vad är felet:

Ett kritiskt fel inträffade vid uppdatering av infobasen
Därför att:
Försöker infoga ett icke-unikt värde i ett unikt index:
Microsoft SQL Server Native Client 11.0: CREATE UNIQUE INDEX-satsen avslutades eftersom en dubblettnyckel hittades för objektnamnet "dbo._InfoRgChngR34546NG" och indexnamnet "_InfoR34546_ByNodeMsg_RNTSRRRRRRRNG". Dupliceringsnyckelvärdet är (0x00000011, d7, , 27 september 4015 22:22, 768404.00,00,00,00,00,00).
HRESULT = 80040E2F, SQLSrvr: SQLSTATE = 23000, tillstånd = 1, Allvarlighet = 10, ursprunglig = 1505, rad = 1

Förklaring

Låt oss förstå strukturen för SQL. Vi har ett register "MessageTrackingLog", det finns i tabellen i SQL " _InfoR34546 ". Du kan kontrollera detta med speciella behandlingar eller genom att skriva (vi kommer inte att behöva göra detta, eftersom namnet på tabellen redan är angivet i feltexten).

Nu ska jag förklara vad som hände. När vi laddade in data i registret, i SQL hamnade de i tabellen " _InfoR34546 ". När vi rensade tabellen med koden i 1C, raderades denna data från tabellen." _InfoR34546 "men de kopierades till bordet" _InfoRgChngR34546 ". Det här var problemet.

Lösning

För att lösa problemet måste vi rensa "_InfoRgChngR34546" SQL-tabellen.

Jag ska berätta om exemplet med "Microsoft SQL Server Management Studio". Vi går till " Management Studio ". Hitta vår bas, öppna flikarna med tabeller, klicka på någon och tryck på knappen" Ny fråga ": Nu skriver vi frågan

Trunkera tabellen "_InfoRgChngR34546"

Du kan ha ett annat bord också! Glöm inte!

Och vi trycker på execute eller "F5"-tangenten. Detta borde bli resultatet:

Det är det, nu kan du säkert uppdatera 1C, och det kommer inte att uppstå några fel!