Zandbak

Valera 18 september 2013 om 15:24 uur

1C, herstel van infobase-configuratie met behulp van MS SQL

• Microsoft SQL-server,
• Databasebeheer

Ooit kwam ik een probleem tegen: bij het bijwerken van de configuratie vanuit de repository trad er een fout op en werd 1C gesloten.

Zoals later bleek, werd de configuratieopslag vernietigd en bij het updaten van de configuratie werd ook de databaseconfiguratie uit de opslag verwijderd. Een soortgelijke fout deed zich eerder voor tijdens dynamische updates van informatiebeveiliging.

Omdat Dit probleem is meer dan eens voorgekomen en ik besloot een behandelingsoptie te delen.

De volgende keer dat u de configurator startte, verscheen er een foutmelding: “Let op!!! Er is een fout opgetreden bij het bijwerken van gegevens na de laatste herstructurering. Moet ik de update herhalen? Als het antwoord ja is, ontvangen we het bericht: “Er is een onvolledige bewerking voor het opslaan van de configuratie gedetecteerd. Om verder te kunnen werken, moet u de bewerking voltooien, waarna de applicatie wordt gesloten.

Bij het analyseren van dit probleem zijn verschillende oplossingen voor het probleem gevonden, elke oplossing werkt in verschillende gevallen.

Optie 1 (als u een SQL-back-up heeft met een kopie met een identieke configuratie):

Er wordt een kopie van de informatiebeveiliging ingezet en het volgende verzoek wordt uitgevoerd:
GEBRUIK GO DELETE FROM .. GO INSERT IN .. SELECT * FROM .. GO
In dit geval wordt de tabel waarin de inis opgeslagen opnieuw gevuld. Het is raadzaam om na deze operatie de informatiebeveiliging te testen en te corrigeren.

Optie 2 (als er geen back-up is):

Deze optie werd gekozen als de laatste druppel. Omdat de configuratie was in ontwikkeling en ze vergaten de back-up een beetje, vertrouwend op opslag.
In de database worden twee records verwijderd uit de tabel "Config" met de waarde in de kolom "FileName" - dbStruFinal en commit

De volgende query wordt uitgevoerd:
GEBRUIK GA VERWIJDEREN VAN .
WHERE Bestandsnaam = "dbStruFinal" GA VERWIJDEREN VAN .

WHERE Bestandsnaam = "commit" GO

Vreemd genoeg komt de basis tot leven.

Tags: 1C Enterprise 8.2, SQL, configuratieherstel

Twee dagen geleden hebben we de overstap gemaakt van 8.1 naar 8.2 - we hebben de configuratie van UPP 1.2 gewijzigd... naar 1.3.22.1. Dienovereenkomstig leidden veel verschillen met de standaardconfiguratie die werden uitgerold tot een heleboel fouten. Twee dagen lang, zonder te overnachten, veranderen we non-stop de configuratie. De configurator wordt 15 keer per uur opgeslagen. Het was te verwachten dat bij het opslaan de configuratie zou kunnen crashen, en dat is precies wat er gebeurde. Dergelijke problemen werden in conf 8.1 altijd opgelost door het verlaten van gebruikers die nog wel in de database werkten, maar niet meer opnieuw konden inloggen en met exclusieve toegang. In onze nieuwe configuratie 8.2 vertelde de database ons: "Ik ben moe. Ik ga weg"), over het algemeen wordt het probleem beschreven in de aankondiging.

Wat er goed en fout is gedaan. En advies over wat u eerst moet doen.

Allereerst gaan we in de onrust zoeken naar manieren om het probleem op internet op te lossen. Google geeft op dit moment letterlijk 3 artikelen over de tekst van de fout die optreedt. Ik zal ze opsommen.

Over het algemeen is het antwoord op de oplossing voor het huidige probleem in alle drie de artikelen hetzelfde: "Herstel de database vanaf een back-up."

Het is niet nodig om te praten over het belang van back-ups, hun regelmaat enzovoort. Ik denk dat dit voor ons een goede waarschuwing was, hoewel we een back-up hadden van de database nadat deze was opgeslagen in configuratie 1.3, maar weinig mensen volgen hun regelmaat en het feit dat ze klaar zijn (en de harde schijf niet is schoongemaakt enz.). Vergeef daarom de "Captain Obviousness", maar als u een nieuwe back-up heeft, is het eerste wat u moet doen de database ervan herstellen, verspil geen kostbare tijd, waarvoor het management u niet zal bedanken voor de downtime. Je kunt echter proberen de 'gevallen' basis nieuw leven in te blazen, wat dankzij mijn volharding is gelukt. Ik merk op dat een andere programmeur ook pogingen heeft ondernomen om de database op de een of andere manier nieuw leven in te blazen met behulp van 1C-methoden, maar dat deze niet succesvol waren. Ik weet niet alles wat hij deed, maar ik zag pogingen om 1C onmiddellijk in de commandomodus te starten met de lancering van Testing and Correction of Information Security, wat feitelijk niets opleverde.

Ik concentreerde mijn aandacht op SQL. Ik ben bekend met een beetje ervaring in het configureren en beheren van databases en een typische set SQL-opdrachten, maar de hieronder beschreven methode vereist geen diepgaande kennis en vaardigheden in het werken met SQL. Ik heb eenvoudigweg de logica met elkaar verbonden - als de database "viel" terwijl de configuratie werd opgeslagen, concluderen we dat de structuur van één tabel in SQL had kunnen instorten (hoewel ik voorheen niet wist dat de configuratie in versie 8 in één vervolgtabel staat) en deze tabel waarin de databaseconfiguratie is opgeslagen. namelijk de dbo.config-tabel. Later kwam ik erachter dat ik de “kies-je-eigen”-methode gebruikte en, nogmaals, logica, omdat het enige dat ik ontdekte een lokale ontwikkeling was, die mij niet hielp, maar wel heel nuttig was voor de toekomst, namelijk. Dank aan de auteur van het account van mijn collega, met de hulp van wie ik het heb gedownload. Dus ik ga verder met het allerbelangrijkste: pogingen (!) om de database te herstellen, omdat ik je helaas geen garanties kan geven en er een aantal presets zijn die je misschien niet hebt of, zoals ze zeggen, dit is niet jouw geval...

Vereisten en het databaseherstel zelf.

(Let op. Kijk zeker naar de voetnoot hieronder als je wilt proberen de configuratie zelf nieuw leven in te blazen. Vandaag (18/04/2012) is het door middel van experimenten gelukt omdat ik medelijden had met het werk dat er een week aan was gedaan. Het was dus mogelijk om de database nieuw leven in te blazen, waardoor de oude configurator zonder kopieën achterbleef)

Initiële gegevens - SQL-database 1C 8.2, UPP-configuratie 1.3.22.1 (ik geloof dat de beschreven methode geschikt is voor elke 8.2-standaarddatabase). SQL server 2005. De fout beschreven in de aankondiging en de fout die optrad tijdens het opslaan van de configuratie! De belangrijkste en verplichte vereiste!!! Een kopie van de SQL-database met DEZELFDE CONFIGURATIE(!) We hebben automatische uitwisseling met een andere database geconfigureerd en hun configuraties zijn hetzelfde. Omdat we drie 1C-programmeurs zijn, hebben we bovendien elk een geüpload en relatief recent configuratiebestand. In feite zal elke database het doen, ongeacht welke gegevens deze bevat. Het belangrijkste is dat de configuratie daarin overeenkomt met de structuur van de metadata van de database. Ik zou willen opmerken dat de configuratie zelfs iets anders was dan die waarmee de basis crashte. De meest fundamentele vereiste is naar mijn mening dat verschillen in configuratie geen invloed hebben op de metadata. Vergeet niet dat als de configuratie anders is, u uiteindelijk een werkende database ontvangt, maar met de configuratie van uw kopie.

Het herstelproces zelf kost niet veel tijd - letterlijk een paar minuten, maar ik raad ten zeerste aan om eerst een back-up te maken van zelfs een "gevallen" database, maar dit kan enige tijd duren. U krijgt bijvoorbeeld de mogelijkheid om de database te herstellen door terug te gaan naar het logbestand (dat helaas werd “verbannen” in de onrust van het herstel) of op een andere manier. Laat me u er dus aan herinneren dat er ergens een SQL-database moet zijn, ongeacht welke gegevens, maar met dezelfde configuratie. Als uw configuratie een “onaangeroerde” standaardconfiguratie is (wat betekent dat dit probleem is ontstaan ​​tijdens het uitrollen van een nieuwe standaardconfiguratie), kunt u een nieuwe lege database maken en deze vullen met de standaardconfiguratie die u eerder had. Als de gevonden configuratie niet zo recent is, denk er dan over na en neem een ​​beslissing. Misschien zullen de verschillen met de kopie van de configurator, die u in uw database moet herhalen, veel meer tijd en middelen vergen dan het verlies van informatie uit; de 1C-database zelf. Een soort tweesnijdend zwaard) Dus...

1. Maak een back-up van de gecrashte database met behulp van SQL.

2. We wissen de dbo.config-tabel van onze database, die onze kapotte conf bevat. Dit kan gedaan worden vanuit SQL Profiler, bijvoorbeeld door daarin de opdracht uit te voeren:

Verwijderen van.

waarbij Base2009 de naam is van de gecrashte basis.

Opmerking: ik heb ergens op internet wat niet-geverifieerde informatie gelezen dat het soms helpt om de dbo.ConfigSave-tabel leeg te maken, die zogenaamd de opgerolde conf bevat. In onze database bleek deze leeg te zijn, dus ik heb de lege tafel uiteraard niet opgeschoond. Misschien - je kunt op de een of andere manier de 1C-database misleiden en nieuw leven inblazen met behulp van deze tabel, maar zonder het mechanisme te kennen van hoe 1C met deze tabel werkt, zal ik niets zeggen in termen van actie in verband daarmee.

3. Kopieer de tabel uit de database met de volledige configuratie naar onze beschadigde database. In mijn geval bevonden beide databases zich op dezelfde server, dus de kopieeropdracht in SQL-Profiler zag er als volgt uit.

invoegen in .. selecteer * uit ..

waarbij base2009 de naam is van de gecrashte database, BaseCopy de naam is van de database met een kopie van de configurator

4. We lanceren 1C, en als dat lukt, zijn we, net als ik, blij dat we erin zijn geslaagd de database nieuw leven in te blazen zonder enig verlies van informatie.

5. (Kapitein duidelijk) we controleren, debuggen en monitoren het systeem voor het maken van databaseback-ups en gaan zeer verantwoordelijk om met het proces van het bijwerken van de configuratie (we doen dit niet via het netwerk, maar bij voorkeur op de server, waarbij we indien mogelijk een maak eerst een back-up). Vooral als je 1C-versie 8.2 is geworden. Voor zover ik begrijp uit artikelen op internet en de eerste twee dagen dat ik ermee werkte, is het gevoeliger en grilliger vergeleken met 8.1, waarmee dergelijke problemen niet bestonden.

5a. Als de configuratie van de database waaruit je de conf-tabel gaat kopiëren nog steeds anders is (zonder dat er verschillen zijn in de metadata, wat ik al noemde), en ergens is er je relatief nieuwe cf-bestand met de ongeladen conf - rol het dan naar de nieuw leven ingeblazen basis . Anders moet u alle verschillen herhalen die aanwezig waren bij de kopie van de configurator. Denk dus nog eens goed na en analyseer wat belangrijker is: uw werk aan het wijzigen van de configuratie (en hoeveel tijd u daaraan besteedt) of het werk van de databasegebruikers tot de laatste back-up. In mijn geval was het het werk van 2 programmeurs gedurende 3 uur versus het werk van ongeveer 100 gebruikers gedurende 1,5 dag, dus de keuze lag voor de hand.

ZY Zal ik je er nog eens aan herinneren? dat deze herstelfunctie een ongedocumenteerde manier is om de database te herstellen door 1C-schapen (in het specifieke geval van het instorten van de database die plaatsvond tijdens het opslaan van de conf) en dat alles wat je doet op eigen risico en risico gebeurt, maar specifiek in mijn geval daar zijn andere manieren om de database nieuw leven in te blazen met minimale Er was geen verlies van bestaande informatie (het logbestand ging verloren en de meest recente back-up vertegenwoordigde het verlies van 1,5 dag werk voor ongeveer 100 gebruikers), dus, zoals ze zeggen, de bruggen waren verbrand)

Z.Y.Y. Dit is mijn eerste publicatie hier omdat... Ik ben een lafaard op andere 1C-forums, maar ik vind deze bron een van de nuttigste in termen van geposte ontwikkelingen en publicaties, dus oordeel niet strikt over de vele IF's in deze publicatie). Ik zou heel blij zijn als ik iemand echt zou helpen met het herstel van een vernietigde basis, want het enige dat erger is dan dat is een kernoorlog)

Z.Y.Y.Y. 3 weken later herhaalde het probleem zich) Deze keer duurde de oplossing slechts een paar seconden (als je geen rekening houdt met de tijd die nodig was om een ​​back-up te maken), en hoefden zelfs de gebruikers niet eruit te worden gezet .

_____________________________________________________________________________________________________________

Vandaag kwam een ​​collega aanrennen. Hetzelfde probleem. Alleen de database is een testexemplaar en geen werkende, en de database zelf is precies dat - maar de configurator is belangrijk voor hem. Hij heeft er een week aan gewerkt zonder het bestand één keer naar de cf te uploaden en zonder de wijzigingen in de werkdatabase door te voeren. Nou, waarom zou je niet dieper graven met de tafel?! Deze keer is het nog eenvoudiger. Ik open SQL Management Studio. Ik vorm een ​​query in de tabel voor velden met de huidige wijzigingsdatum en het tijdstip waarop de database crashte - het resultaat levert 2 records op. De eerste is Field FileName = "commit" Nou, crash deze invoer - en alles is gelukt voor mij! De configurator is tot leven gekomen en de database werkt weer. Wat moet er gebeuren?!

Dus in het geopende SQL Management Studio-venster zoeken we naar onze database - open Tabellen, zoek naar de tabel met de conf aan het einde van de lijst dbo.config op tafel - rechterknop - Open tafel. Vervolgens gaan we in het rechtervenster alfabetisch naar beneden in de tabel zelf naar het veld waar FileName = "commit". We gaan naar dit item - rechtermuisknop - Verwijderen. Over het algemeen verwijderen we de vermelding met het binaire bestand. Vervolgens proberen we de conf. Dezelfde fout verschijnt eerst. Het is waarschijnlijk niet gelukt? OK. En toen, voordat hij het tweede bericht uitbracht over de onmogelijkheid om te sparen, zoals voorheen, begon de computer na te denken. Na 30 seconden - O WONDER! De configurator is geopend. We proberen de configurator op te slaan (na het opslaan van het cf-bestand). De configurator is opgeslagen. Zo worden de wolven gevoed en zijn de schapen veilig. Ik ben niet zeker van de volledige functionaliteit van de database na dergelijk misbruik - dus ik raad je aan om de resultaten later op de avond te herstructureren en opnieuw te berekenen (na het maken van een archief uiteraard). Veel succes met je herstel en positieve emoties)

Wij zijn verhuisd naar een nieuwe server. Het draait SQL en 1C. Vergeleken met de oude was het veel koeler. En de test van Gilev bevestigde dit ook: tegen 10-15 op de oude servers gaf het 39. Daarom hebben we onmiddellijk na de aankoop de database overgedragen en zijn we aan de slag gegaan.

Maar op een gegeven moment ging er iets mis: gebruikers begonnen te klagen over langzaam werken. We hebben bepaalde instellingen voor de server en services gemaakt (welke zijn het onderwerp van een apart bericht) en besloten de server opnieuw op te starten, gelukkig was de herstartsnelheid 2 minuten (op andere servers was dit maximaal 10). Hierna ontvangen wij bij het inloggen op 1C de volgende melding:

"Aandacht!!! Er is een fout opgetreden bij het bijwerken van gegevens na de laatste herstructurering. Moet ik de update herhalen? "Niet echt"

Nadat u op "Ja" hebt geklikt, verschijnt het volgende:

“Er is een onvolledige opslagbewerking voor de configuratie gedetecteerd. U moet de bewerking voltooien om door te gaan."

Het eerste dat ik besloot te doen was CHECKDB in Management Studio - na 2 uur wachten (database van 500 GB) - was alles in orde.

Ik heb informatie op internet gevonden dat dezelfde fout optreedt tijdens dynamische updates.

De online voorgestelde oplossingen hielpen niet meteen, maar samen met andere acties gaven ze wel resultaat. Dus wat ik deed:

Oplossing:

1. Wat ontbrak voor oplossingen vanuit het netwerk:

sp_configure 'updates toestaan', 1
opnieuw configureren met overschrijven
gaan

2. Zet de database in de herstelmodus

wijzig databaseset EMERGENCY, SINGLE_USER

3. We voeren databasetests uit:

dbcc checkdb('db_naam', REPAIR_ALLOW_DATA_LOSS)

4. Verlaat de database uit de herstelmodus:

databaseset ONLINE wijzigen, MULTI_USER

5. Als je zeker weet dat alles in orde is met de basis zelf, hoef je in principe de punten 2-4 niet te doen. Vervolgens voeren we twee query's uit in de SQL-profiler:

verwijderen uit configuratie waarbij Bestandsnaam = 'commit'
verwijderen uit configuratie waarbij FileName = ‘dbStruFinal’

Deze records zijn verantwoordelijk voor het dynamisch bijwerken - u hoeft niet bang te zijn om ze te verwijderen.

In werkende versies van de databasequery's:

selecteer * uit Config WHERE Bestandsnaam = 'commit'

selecteer * uit Config WHERE Bestandsnaam = 'dbStruFinal'

zal leeg zijn.

6. zet de instellingen terug:

sp_configure 'updates toestaan', 0
gaan

7. Hierna slaagden we erin de configurator te starten en begon de database te werken.

Ook kan de basis gaan werken nadat de eerste vlag is verwijderd.

Het probleem waar dit artikel aan gewijd is, doet zich voor wanneer de configurator crasht op het moment dat de database wordt geherstructureerd, dat wil zeggen tijdens een van de laatste fasen van het bijwerken van de configuratie. De in het artikel beschreven oplossing is van toepassing op de client-serverversie van het 1C: Enterprise-platform, waarbij MS SQL Server als DBMS wordt gebruikt.

Symptomen kunnen de volgende systeemwaarschuwingen omvatten:

1) Wanneer u probeert de database te starten in de configuratiemodus:

2) Wanneer u probeert de database in de bedrijfsmodus te starten:

3)Bij het openen van de configurator biedt het systeem mogelijk ook de volgende oplossing:

Deze vraag kunnen wij bevestigend beantwoorden. En vaak wordt op deze manier het probleem opgelost. Maar niet altijd.

Het systeem reageert mogelijk op onze toestemming om door te gaan met de update met het volgende bericht:

Of vereisen exclusieve toegang, wat niet altijd handig is in systemen met een groot aantal gebruikers, en soms simpelweg onmogelijk is.

In dit geval zal MS SQL Server ons helpen. Om ons probleem op te lossen, volstaat het om de volgende scripts opeenvolgend uit te voeren (uiteraard in de context van de problematische database).

1) Laten we eerst kopieën maken van de Config- en ConfigSave-tabellen (later kunnen ze worden verwijderd).

SELECTEER *

INTO Config_copy

VAN [Config]

SELECTEER *

IN ConfigSave_copy

VAN

In deze tabellen wordt informatie over configuraties en updatevoortgang opgeslagen. In de eerste tabel wordt informatie opgeslagen over de databaseconfiguratie, inclusief de laatste updategegevens. De tweede tabel bevat gegevens uit de nieuwe, niet-opgeslagen configuratie. Door de inhoud van deze tabellen te analyseren, ontvangt het systeem gegevens over hoe succesvol (of niet succesvol) de laatste update was.

2) Verwijder alle vermeldingen uit de ConfigSave-tabel (slaat de rollende configuratie op)

VERWIJDEREN VAN

3) Verwijder drie vermeldingen uit de Config-tabel (ze slaan informatie op over het onvoltooide configuratie-updateproces)

VERWIJDEREN VAN

WAAR Bestandsnaam IN ("commit" , "dbStruFinal" , "dynamicCommit" )

Records over onze nieuwste update zouden in de Config-tabel moeten verschijnen, wat eenvoudig te controleren is met een gewone “select”.