1c elosztott ib konfigurációs módosítások. A hibát okozó problémák elkerülése érdekében javasoljuk, hogy ne végezzen dinamikus frissítést (legalább többször egymás után - mielőtt áttöltené a változásokat az ágakba), és lehetőleg a csere utáni beállításokban is.

Az elosztott információs bázist (RIB) gyakran használják a fióktelepek és részlegek munkájának megszervezésére, lehetővé téve a gyors információcserét, miközben megtartják a szükséges mértékű autonómiát. Bár ezt a technológiát elég megbízható, időnként meghibásodik. Ma megvizsgáljuk az egyik meglehetősen gyakori hibát: Beszéljünk az előfordulásának okairól és a kezelés módszereiről.

Kezdjük, mint mindig, az elejétől. A RIB létrehozása után a konfiguráció minden módosítása információs bázis csak a fő csomópontban adható meg. Ezt követően, a következő csere során minden változtatás átkerül az alárendelt csomópontokra, és automatikusan ott kerül alkalmazásra. De papíron sima volt ...

A gyakorlatban néha előfordul, hogy a kommunikációs munkamenetek között, különösen, ha probléma van a periférián lévő csatornával, a főcsomópont konfigurációjának kétszer van ideje változtatni. Például változtatásokat hajtottak végre, lepakolták őket, a perifériás adatbázis megkapta a módosításokat, de még nem alkalmazta őket, ami eltarthat egy ideig, és még nem küldött megerősítést. Ha ebben az időszakban változtatásokat hajt végre, és újra kirakja a cserét, akkor kiderül, hogy a központ elvárja, hogy lássa az 1. konfigurációt a perifériás csomópontban, és megpróbálja frissíteni a 3. konfigurációra, és valójában ott fog szembesülni a 2. konfigurációval . Néha hasonló helyzet fordul elő a központi adatbázis dinamikus frissítésekor. Ennek eredményeképpen a csere lehetetlenné válik, és kap egy üzenetet, amely ezt jelzi Az elosztott IS csomópont konfigurációja nem felel meg a vártnak!

Általánosságban elmondható, hogy ennek a történetnek az erkölcse egyszerű - ne finomítsa aktívan a munkabázist, és ha igen, akkor fejezze be az összes cserét, mielőtt végrehajtaná a következő módosításokat. De mi van, ha ilyen kellemetlenség történne?

A megoldás az, hogy új rabszolga-képet hoz létre, de a gyakorlatban ez általában nem alkalmazható. Általános szabály, hogy az adatcsere során bekövetkező súlyos hiba előfordulását nem azonnal, hanem egy idő után rögzítik, miután a perifériás adatbázisok működési adatai leálltak. A csereütemezéstől függően a probléma bekövetkezése és annak észlelése között egy vagy több munkanap is eltelhet.

Itt érdemes követ dobni a fejlesztők kertjébe, akik hibaként adják ki, és ugyanúgy pirossal emelik ki a helyzetet Az üzenet száma kisebb vagy egyenlő az előzőleg fogadott üzenet számával, ami általában teljesen normális. Ennek eredményeképpen a felhasználók hibaérzékelése tompul, és egyszerűen abbahagyják a megjelenített üzenetek olvasását, azt gondolva, hogy minden rendben van, és a másik fél még nem folytatott cserét otthon.

De vissza a hibánkhoz. A megoldás meglehetősen egyszerű, és a felszínen rejlik: hozza a perifériás bázis konfigurációját az elvárthoz, azaz hozza összhangba a központi telephely konfigurációjával. De a gyakorlatban ezt nem olyan könnyű megtenni. Ha megnyitjuk a perifériás bázist a konfigurátorban, látni fogjuk, hogy a változtatásokat a RIB vezérlők blokkolják.

A slave csomópont konfigurációjának megváltoztatásához ideiglenesen le kell választania a központi bázist. E célokra használhatja a hálózaton kellően képviselt feldolgozások egyikét, vagy leválaszthatja az információbiztonságot a központi csomópontról a Configurator indítási paraméterével/ ResetMasterNode.

Nyisson meg egy parancssort, és írja be (a platform verziója és a valós telepítési útvonal alapján):

"C: \ Program Files (x86) \ 1cv8 \ 8.3.6.2100 \ bin \ 1cv8.exe" config / ResetMasterNode

A parancs végrehajtása után megjelenik a szokásos indítóablak, válassza ki a kívánt bázist, és nyomja meg a gombot Konfigurátor.

Az információbiztonság elindítása egyidejűleg nem fog megtörténni, azaz úgy tűnhet, hogy semmi sem történt, de ha újra megnyitja a bázist a Configurator programban, megbizonyosodhat arról, hogy az levált a fő csomópontról, és elérhető -e a módosítások végrehajtásához.

Figyelem! A 8.3.7 - 8.3.9 platformokon ez a parancs összeomlik. A hibát kijavították a 8.3.10 platformon.

Ha nem akarsz vacakolni parancs sor, akkor használhatja az egyik kezelést, az alábbiakban az általunk használtat találtuk a hálózat kiterjedtségén, és csak kozmetikai módosításokat hajtottunk végre rajta. Kérjük, vegye figyelembe, hogy a feldolgozás csak normál alkalmazáshoz alkalmas; a felügyelt alkalmazás konfigurációihoz használja a Configurator indítókulcsát.

Rendkívül egyszerű vele dolgozni, 1C: Enterprise módban indítjuk el Fájl - Megnyitás, akkor csak nyomja meg a kívánt gombot, a mi esetünkben A főcsomópont letiltása.

Most szükségünk van a tényleges konfigurációra a központi webhelyről. Ehhez nyissa meg központi információbiztonság a konfigurátorban, és hajtsa végre Konfiguráció - Konfiguráció mentése fájlba... A kapott fájl kiterjesztéssel vöát kell vinni a perifériás csomópontba.

Ezután a perifériás csomópontban elindítjuk az IB -t (miután leválasztottuk a fő csomópontról) a Configurator programban, és eltávolítjuk a támogatásból. Ehhez válassza ki: Konfiguráció - Támogatás - Támogatási konfiguráció.

A megnyíló ablakban először engedélyezze a módosítási lehetőségeket.

Ezután eltávolítjuk a konfigurációt a támogatásból.

Most letöltheti a konfigurációt egy fájlból, ehhez válassza ki Konfiguráció - Konfiguráció betöltése fájlbólés adja meg, hogy nincs áthelyezve a központi telephelyről vö-fájl. Ekkor figyelmeztetést kap, hogy a jelenlegi konfiguráció nem üres. Kérjük, vegye figyelembe, hogy az általunk végzett manipulációk potenciálisan veszélyesek, és visszafordíthatatlan károkat okozhatnak az információbiztonságban, ezért mielőtt folytatná, győződjön meg arról, hogy rendelkezik frissített biztonsági mentéssel.

Ez a hiba tipikus. A hiba "Az elosztott IS csomópont konfigurációja nem felel meg a vártnak" szisztémás hiba. Ez főként a munka rendellenes befejezése miatt következik be az URIB -n történő adatcsere során.

Ezt eléggé meg tudod oldani egyszerű módon... Gondoljuk meg.

Utasítás

1. Készítsen másolatot azokról az adatbázisokról, amelyeken dolgozni fog (a Configurator "Adminisztráció - Infobase eltávolítása" részében).

2. Indítsa el a RIB csomópont fő bázisának konfigurátorát.

3. Mentse el a központi csomópont konfigurációját egy adatbázis fájlba ("Konfiguráció - Konfiguráció mentése fájlba ...")

4. Nyissa meg a slave csomópont alapkonfigurátorát.

Ingyenes 267 1C videó oktatóanyag:

5. Távolítsa el a slave csomópont konfigurációját a támogatásból (Configuration - Support - Support Settings - Remove from support):

6. Töltse be az adatbázis -konfigurációt ("Konfiguráció - Konfiguráció betöltése fájlból ...").

8. Az átszervezés után vállalati módba kell lépnie, és telepítenie kell a fő konfigurációs csomópontot. Ezt speciális feldolgozással -. A feldolgozás felügyelt alkalmazásmódban és normál alkalmazásmódban is működik.

9. A feldolgozás során ki kell választani a fő csomópontot, és kattintson a "Végrehajtás" gombra:

10. Kész! Próbálja meg elindítani a cserét, a rendszernek helyesen kell végrehajtania a cserét.

Először is itt van az általam használt rövidítések listája:

• RIB - elosztott információs bázis
• Központi Bank - központi bázis, RIB gyökércsomópont
• UB - távoli bázis, a távoli RIB csomópont adatbázisa

Által saját tapasztalat Mondhatom, hogy a hiba két okával találkoztam:

1. az üzenetfájl UB-n történő fogadása során a bázis "leesett", amellyel kapcsolatban nyilvánvalóan hibás szinkronizálás történt a konf. Központi Bank és UB;
2. az MSSQL alatt az ügyfél feltöltötte a működő adatbázis egy példányát, és nem kapcsolta ki a regl. automatikus cserefeladatok, ennek következtében a beérkező üzenetek egy része távoli csomópontok egy működő adatbázisból, néhány pedig egy másolatból alakult ki, ami a konfigurációk szinkronizálásához vezetett

Van olyan vélemény is, hogy ezt a hibát a dinamikus adatbázis -frissítési mechanizmus használata okozza. Itt vannak kétségek, mert egyrészt dinamikus frissítés soha nem befolyásolja az adatbázis szerkezetét, és a RIB mechanizmusok továbbra is az adatbázis szerkezetével működnek, és nem az alkalmazott részével, ennek ellenére a RIB a mechanizmust használja a konfigurációs verzió digitális aláírásának előállítására (a jövőben ezt fogom hívni) hash rövidítésre), és az alkalmazott rész cseréjekor a hash -t természetesen újra kell számítani. Nem tagadom, és nem is állítom, mert ha találkoztam ezzel a helyzettel, nem találtam erre egyértelmű bizonyítékot.

A korrekcióhoz 2 technikát alkalmazok, a helyzettől függően.

ELSŐ MÓDSZER

Az első (leggyakoribb) többször említésre kerül a partnerkonferencián és az 1C -hez kapcsolódó egyéb internetes forrásokban is. A legtöbb esetben akkor használják, ha a konfigurációs eltérésekről szóló üzenet ellenére a kézi összehasonlítás azt mutatja, hogy azok azonosak.

Szekvenálás:

1. kirakjuk a cf-fájlt a jegybankból;
2. leválasztjuk az UB -t a RIB -ről (a SetMainNode módszer, a kész feldolgozás megtalálható a mellékletben vagy más kiadványokban);
3. cserélje ki a konf. UB az első lépésben kirakott cf-fájlhoz, ehhez a "Konfiguráció betöltése fájlból" menüt használjuk (és nem összehasonlítás-egyesítéssel !!!);
4. visszaállítjuk az UB RIB jelét.

A legtöbb esetben ezek a műveletek több mint elegendők a csere helyreállításához, de nem mindig ...

MÁSODIK MÓDSZER

Akkor használják, ha az első technika nem működött, és nem lehetséges a csomópont újbóli kirakása.

Háttér: az ügyfélnek kaszkád RIB -je volt, és hiba történt a kaszkád első szintjén (a második szint mindvégig hibátlanul működött). A konfigurációt az ügyfél informatikai szolgáltatásával együtt fejlesztették ki, és mivel a hiba bekövetkezett, a jegybank konfigurációja többször megváltozott. A visszavágó változtatások lehetőségét még csak elvben sem vették figyelembe, hiszen az adatok egy részének elvesztése és több osztály leállítása teljesen elfogadhatatlan volt. A hiba kijavításának első lehetősége nem hozott kézzelfogható eredményt. Ezzel kapcsolatban más megoldásokat kellett keresnem.

Az ötlet az volt, hogy megpróbáljuk kicserélni a konfigurációs fájlok kivonatait közvetlenül az XML Exchange fájlokban. A cserefájl szerkezetének leírása a "Szakmai fejlődés az 1C: Enterprise 8 rendszerben" című könyvből rossz képet adott a megalakulásról digitális aláírások konfigurációk és változások, de meghatározták a keresés irányát: a Digest1 és a Digest2 értékei. A többit pusztán empirikusan (vagyis próbálgatással) találtam ki, de sikerült mintát kialakítanom.

A kísérleti kísérletek sikeresek voltak. A munkabázisokon is minden rendben ment.

Tehát a műveletsor:

1. az első technika 1–4. lépését hajtjuk végre;
2. a cserefájlt kirakjuk az UB -ből, de nem töltjük fel a központi bankba;
3. kicseréljük a cserefájlt a Központi Banktól, de nem töltjük be az UB -be;
4. a Központi Banktól származó cserefájlban cserélje ki a konfigurációs változásokról és a kivonatokról (Digest1 és Digest2) szóló információkat tartalmazó blokkot az UB -fájlból származó kivonatok blokkjával (lásd az alábbi példát)
5. letöltjük a fájlt a 4. pontról az UB -re;
6. feltétlenül írja felül a cserefájlt az UB -ről (2. pont)! ezt a fájlt nem szabad feltölteni a jegybanki csere során!
7. ellenőrzéséhez több egymást követő cserét hajtunk végre.

Ha az adatcsomagolás során adattömörítést használnak, akkor tiltsa le a tömörítést, vagy először csomagolja ki a fájlt, módosítsa, majd csomagolja vissza és küldje el.

Exchange fájlblokk a Központi Banktól

106.0
... vannak blokkok, amelyek leírják a konfiguráció módosításait ...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

le kell cserélnie az UB -ből származó cserefájl blokkjával (megjegyzés: A fájl Digest1 -je az UB -ből mindig "000000000000000000000000000000000000" !!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

A felsorolt ​​műveleteket rendkívül óvatosan kell végrehajtani, a helytelen sorrend tele van a RIB teljes működésképtelenségével. Ezért e cselekvések előtt a teremtés biztonsági mentések SZÜKSÉGSZERŰEN!

Különben csak sok sikert kívánhatok!

Először is itt van az általam használt rövidítések listája:

• RIB - elosztott információs bázis
• Központi Bank - központi bázis, RIB gyökércsomópont
• UB - távoli bázis, a távoli RIB csomópont adatbázisa

Saját tapasztalatom alapján azt mondhatom, hogy két okból találtam a hibát:

1. az üzenetfájl UB-n történő fogadása során a bázis "leesett", amellyel kapcsolatban nyilvánvalóan hibás szinkronizálás történt a konf. Központi Bank és UB;
2. az MSSQL alatt az ügyfél feltöltötte a működő adatbázis egy példányát, és nem kapcsolta ki a regl. automatikus cserefeladatok, ennek eredményeként néhány üzenetet a távoli csomópontokhoz a működő adatbázisból, néhányat pedig egy másolatból generáltak, ami a konfigurációk szinkronizálásához vezetett

Van olyan vélemény is, hogy ezt a hibát a dinamikus adatbázis -frissítési mechanizmus használata okozza. Itt kétségek merülnek fel, mert egyrészt a dinamikus frissítés soha nem érinti az adatbázis szerkezetét, és a RIB mechanizmusai továbbra is az adatbázis szerkezetével működnek, és nem az alkalmazott részével, ennek ellenére a RIB egy mechanizmust használ a digitális aláírás létrehozására. a konfigurációs verzió (a továbbiakban rövidebb kivonatnak nevezem), és az alkalmazott rész megváltoztatásakor a hash -t természetesen újra kell számítani. Nem tagadom, és nem is állítom, mert ha találkoztam ezzel a helyzettel, nem találtam erre egyértelmű bizonyítékot.

A korrekcióhoz 2 technikát alkalmazok, a helyzettől függően.

ELSŐ MÓDSZER

Az első (leggyakoribb) többször említésre kerül a partnerkonferencián és az 1C -hez kapcsolódó egyéb internetes forrásokban is. A legtöbb esetben akkor használják, ha a konfigurációs eltérésekről szóló üzenet ellenére a kézi összehasonlítás azt mutatja, hogy azok azonosak.

Szekvenálás:

1. kirakjuk a cf-fájlt a jegybankból;
2. leválasztjuk az UB -t a RIB -ről (a SetMainNode módszer, a kész feldolgozás megtalálható a mellékletben vagy más kiadványokban);
3. cserélje ki a konf. UB az első lépésben kirakott cf-fájlhoz, ehhez a "Konfiguráció betöltése fájlból" menüt használjuk (és nem összehasonlítás-egyesítéssel !!!);
4. visszaállítjuk az UB RIB jelét.

A legtöbb esetben ezek a műveletek több mint elegendők a csere helyreállításához, de nem mindig ...

MÁSODIK MÓDSZER

Akkor használják, ha az első technika nem működött, és nem lehetséges a csomópont újbóli kirakása.

Háttér: az ügyfélnek kaszkád RIB -je volt, és hiba történt a kaszkád első szintjén (a második szint mindvégig hibátlanul működött). A konfigurációt az ügyfél informatikai szolgáltatásával együtt fejlesztették ki, és mivel a hiba bekövetkezett, a jegybank konfigurációja többször megváltozott. A visszavágó változtatások lehetőségét még csak elvben sem vették figyelembe, hiszen az adatok egy részének elvesztése és több osztály leállítása teljesen elfogadhatatlan volt. A hiba kijavításának első lehetősége nem hozott kézzelfogható eredményt. Ezzel kapcsolatban más megoldásokat kellett keresnem.

Az ötlet az volt, hogy megpróbáljuk kicserélni a konfigurációs fájlok kivonatait közvetlenül az XML Exchange fájlokban. A cserefájl szerkezetének leírása a "Szakmai fejlődés az 1C: Enterprise 8 rendszerben" című könyvből rossz képet adott a konfigurációk digitális aláírásának kialakulásáról és azok megváltoztatásáról, de meghatározta a keresés irányát: a Digest1 és Digest2 értékei. A többit pusztán empirikusan (vagyis próbálgatással) találtam ki, de sikerült mintát kialakítanom.

A kísérleti kísérletek sikeresek voltak. A munkabázisokon is minden rendben ment.

Tehát a műveletsor:

1. az első technika 1–4. lépését hajtjuk végre;
2. a cserefájlt kirakjuk az UB -ből, de nem töltjük fel a központi bankba;
3. kicseréljük a cserefájlt a Központi Banktól, de nem töltjük be az UB -be;
4. a Központi Banktól származó cserefájlban cserélje ki a konfigurációs változásokról és a kivonatokról (Digest1 és Digest2) szóló információkat tartalmazó blokkot az UB -fájlból származó kivonatok blokkjával (lásd az alábbi példát)
5. letöltjük a fájlt a 4. pontról az UB -re;
6. feltétlenül írja felül a cserefájlt az UB -ről (2. pont)! ezt a fájlt nem szabad feltölteni a jegybanki csere során!
7. ellenőrzéséhez több egymást követő cserét hajtunk végre.

Ha az adatcsomagolás során adattömörítést használnak, akkor tiltsa le a tömörítést, vagy először csomagolja ki a fájlt, módosítsa, majd csomagolja vissza és küldje el.

Exchange fájlblokk a Központi Banktól

106.0... vannak blokkok, amelyek leírják a konfiguráció módosításait ... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

le kell cserélnie az UB -ből származó cserefájl blokkjára (megjegyzés: A fájl Digest1 -je az UB -ből mindig "000000000000000000000000000000000000" !!!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

A felsorolt ​​műveleteket rendkívül óvatosan kell végrehajtani, a helytelen sorrend tele van a RIB teljes működésképtelenségével. Ezért ezen lépések előtt KÖTELEZŐ a biztonsági mentések létrehozása!

Különben csak sok sikert kívánhatok!

• Az üzenetet tartalmazó fájl már betöltődött a fogadó bázisba. Újra ki kell tölteni a forrásbázisból.

Hiba "Hiba történt a fájl másolásakor az FTP -erőforrásból ... Internet hiba: Elérte az időtúllépést"

• A webhelyről, amelyen a csere történik, lehetetlen másolni kívánt fájlt... Ennek oka lehet lassú munka az interneten, vagy maga a webhely problémáival.
• Meg kell próbálnia megismételni a cserét 15-30 perc múlva.

Hiba „Az időszakra vonatkozó adatok szerkesztése tilos. A változtatásokat nem lehet leírni ... "

• A letöltési adatok zárt időszakból származó dokumentumokat tartalmaznak.
• Cserét kell végezni azon felhasználók alatt, akik ebben az időszakban jogosultak dokumentumok megváltoztatására.

Hiba "El kell végezni az adatbázis konfiguráció frissítését. A frissítés elvégezhető a konfigurátor módban "

Ok: A programozók megváltoztatták a központ konfigurációját. Megoldás: Frissítse a perifériás bázis módosított konfigurációját. Ezért:

• Menj a konfigurátorhoz.
• Végezze el a "Configurator / Update database configuration" menüpontot.
• Ha olyan kérdést kap, amely csak "Újra", "Mégse", "Dinamikus frissítés" válaszokat tartalmaz, kattintson a "Dinamikus frissítés" gombra.
• Ha olyan kérdést kap, amely csak "Újra" és "Mégse" válaszokat tartalmaz.
  • hogy minden felhasználó kilépjen az 1C -ből.
  • nyomja meg az "Ismétlés" gombot.
• Válaszoljon a többi kérdésre igenlően: "Igen", "Elfogadom", "OK".
• Zárja be a konfigurátort.
• Próbálja újra letölteni a központból.

Hiba "A konfiguráció nem felel meg a vártnak", "Kísérlet az ismeretlen konfiguráció módosításainak fogadására"

• Adatbázis hiba.
• Szükséges kapcsolatba lépni egy szakemberrel.

A csere nagyon sokáig tart, lefagy

Lehetséges okok:

• Sok adat érkezik.
  • Kérdezze meg a feladótól, hogy végzett -e csoportos dokumentumcserét (feladás, adatok cseréje stb.).
  • Ha igen, hagyja a számítógépet egy éjszakán át a központban.
• Nagyméretű fájl nem tölthető le az internetről.
  • Ha a fájl nagy (80-100 MB és több), akkor az 1C egyszerűen nem tudja letölteni.
  • Le kell töltenie a fájlt, és manuálisan (esetleg szakemberek segítségével) fel kell töltenie az 1C -be.
    • menüpont "Műveletek" / Exchange tervek / Teljes / Gomb az "Üzenet olvasása" panelen.
• Az alap sérült:
  • Próbáld ki
• Ha ezek a lépések nem segítettek, akkor fel kell vennie a kapcsolatot a szakemberekkel.

• Ha a hibát nem lehet kijavítani, hívja a segélyhívó telefonszámot: +7 (8512) 64-55-05.
• Szakértőnk segít Önnek, bármilyen városban van.