Úzká místa souborové databáze – jak se vyvarovat (z nedávných zkušeností). Souborová zpomalení – jak se vyhnout (z nedávných zkušeností) Souborová verze zpomaluje 1C 8.3 přes síť

2. Vlastnosti programu. Často i při optimálním nastavení pracuje 1C velmi pomalu. Výkon klesá zvláště prudce, když počet současně pracujících s databází přesáhne 4-5 uživatelů.

kdo jste ve společnosti?

Řešení problému pomalého provozu 1C závisí na tom, kdo jste ve společnosti. Pokud jste techie, čtěte dál. Pokud jste ředitel nebo účetní, klikněte na speciální odkaz ↓

Šířka pásma sítě

S jednou informační bází (IS) zpravidla nepracuje jeden, ale více uživatelů. Zároveň dochází k neustálé výměně dat mezi počítačem, na kterém je nainstalován klient 1C, a počítačem, na kterém je umístěno zabezpečení informací. Objem těchto dat je poměrně významný. Často nastává situace, kdy lokální síť pracující rychlostí 100 Mbit/s, což je nejběžnější rychlost, jednoduše nezvládne zátěž. A opět si uživatel stěžuje na pomalý program.

Každý z těchto faktorů samostatně již výrazně snižuje rychlost programu, ale nejnepříjemnější je, že se tyto věci obvykle sčítají.

Nyní se podívejme na několik řešení problému nízké rychlosti 1C a jejich nákladů na příkladu místní sítě 10 středně velkých počítačů.

Řešení jedna. Modernizace infrastruktury

Toto je možná nejzřejmější řešení. Spočítejme si jeho minimální náklady.

Minimálně pro každý počítač potřebujeme 2 GB RAM stick, který stojí v průměru 1 500 rublů, síťová karta podporující rychlost 1 Gbit/s stojí asi 700 rublů. Kromě toho budete potřebovat alespoň 1 router, který podporuje rychlost 1 Gbit/s, což bude stát přibližně 4 000 rublů. Celkové náklady - 26 000 rublů za vybavení, bez práce.

V zásadě se rychlost může výrazně zvýšit, ale nyní již není možné koupit levné počítače do kanceláře. Toto řešení navíc není použitelné pro ty, kteří používají Wi-Fi nebo chtějí pracovat přes internet – v jejich případě může být rychlost sítě i desítkykrát nižší. Nabízí se myšlenka: „Není možné implementovat celý program na jeden výkonný server, aby se počítač uživatele neúčastnil složitých výpočtů, ale pouze sloužil k přenosu obrazu? Pak můžete pracovat i na velmi slabých počítačích, dokonce i na sítích s nízkou šířkou pásma. Taková řešení samozřejmě existují.

Řešení dvě. Terminálový server

Získal velkou popularitu již v dobách 1C 7. Je implementován na serverové verzi Windows a dobře se vyrovná s naším úkolem. Má to však svá úskalí, a to náklady na licence.

Samotný operační systém bude stát asi 40 000 rublů. Kromě toho budeme potřebovat pro každého, kdo plánuje pracovat v 1C, licenci Windows Server CAL, která stojí asi 1 700 rublů, a licenci CAL na Windows Remote Desktop Services, která stojí asi 5 900 rublů.

Po výpočtu nákladů na síť 10 počítačů dostaneme 116 000 rublů. pouze na jednu licenci. Přidejte k tomu náklady na samotný server (nejméně 40 000 rublů) a náklady na implementační práce, ale i bez toho se cena za licence ukázala jako působivá.

Řešení tři. Služba 1C Enterprise

1C vyvinula vlastní řešení tohoto problému, které může výrazně zvýšit rychlost programu. Ale i zde je nuance.

Faktem je, že náklady na takové řešení se v závislosti na vydání pohybují od 50 000 do 80 000 rublů. Pro společnost do 15 uživatelů se to ukazuje jako poměrně drahé. Velké naděje byly vkládány do „podnikového miniserveru 1C“, který je podle společnosti 1C zaměřen na malé podniky a stojí kolem 10 000 - 15 000 rublů.

Když se však dostal do prodeje, byl tento produkt velkým zklamáním. Faktem je, že maximální počet uživatelů, se kterými bylo možné miniserver používat, byl pouze 5.

Jak napsal jeden programátor 1C na fóru: „Stále není jasné, proč si 1C vybral právě 5 spojení! Problémy začínají pouze u 4 uživatelů, ale u pěti vše končí. Pokud chcete připojit šestou osobu, připlaťte dalších 50 tisíc. Mohli bychom udělat alespoň 10 spojení...“

Svého konzumenta si samozřejmě našel i miniserver. Pro firmy, kde s 1C pracuje 5 a více lidí, se však jednoduché a levné řešení neobjevilo.

Kromě výše popsaných metod akcelerace programu existuje ještě jedna, která je ideální pro segment 5 - 15 uživatelů, a to webový přístup pro 1C v režimu souborů.

Řešení čtyři. Webový přístup pro 1C v režimu souborů

Princip fungování je následující: na počítači je nainstalována další role webového serveru, na kterém je zveřejněna bezpečnost informací.

Přirozeně by to měl být buď nejvýkonnější počítač v síti, nebo samostatný stroj určený pro tuto roli. Poté můžete pracovat s 1C v režimu webového serveru. Všechny náročné operace budou prováděny na straně serveru a provoz přenášený přes síť bude minimalizován, stejně jako zatížení klientského počítače.

Proto i velmi slabé stroje mohou být použity pro práci v 1C a šířka pásma sítě není kritická. Naše testy ukázaly, že na levném tabletu můžete pohodlně pracovat přes mobilní internet, aniž byste se cítili nepříjemně.

Tato možnost je z hlediska provozní rychlosti nižší než podnikový server 1C, ale tento rozdíl je prakticky neviditelný až pro 15–20 uživatelů. Mimochodem, k implementaci webového serveru můžete použít IIS (pro Windows) a Apache (pro Linux) a obě tato řešení jsou zdarma!

Navzdory zjevným výhodám si tento způsob optimalizace provozu 1C nezískal velkou popularitu.

Nemohu to s jistotou říci, ale pravděpodobně je to způsobeno dvěma důvody:

• Docela slabý popis v technické dokumentaci
• Nachází se na křižovatce odpovědnosti správce systému a programátora 1C

Obvykle, když je správce systému osloven s problémem nízké rychlosti, navrhne upgrade infrastruktury nebo terminálového serveru; pokud je kontaktován specialista 1C, je mu nabídnut podnikový server 1C. Pokud tedy ve vaší společnosti „ruku v ruce“ pracují specialista odpovědný za infrastrukturu a specialista odpovědný za 1C, můžete bezpečně používat řešení založené na webovém serveru.

Zrychlíme o 1C. Na dálku, rychle a bez vaší účasti

Víme, jak zrychlit 1Ski, aniž bychom rušili zákazníka. Ponoříme se do problému, uděláme svou práci a odejdeme. Pokud chcete, aby program fungoval normálně, kontaktujte nás. Přijdeme na to.

Zanechte žádost a získejte bezplatnou konzultaci o urychlení programu.

Optimalizace 1C a rychlost práce v mnoha ohledech závisí na práci se zámky, dotazy a indexy. Pokusíme se odpovědět na otázku „jak urychlit práci 1C“ (otázku, jak urychlit spuštění 1C, zvážíme v jiném článku) a vyhnout se stížnostem uživatelů na „dlouhé zpracování dokumentů“, které nevyhnutelně ovlivňuje obchodní procesy.

Část 3. Výkon 1C

Zámky v 1C 8.3: hledání a odstraňování v kódu, přenos do spravovaných zámků

Zámky jsou součástí mechanismu ACID. Podívejme se na jeho koncept, prezentovaný ve formě zjednodušeného diagramu, na příkladu SQL SERVER

V automatickém režimu jsou zámky spravovány samotným DBMS. Současně se na serveru MS SQL objevily vedlejší efekty, jako je zamykání prázdných tabulek a rozsahů hraničních dat (úroveň Serializable), což způsobilo další problémy při práci s více uživateli. K vyřešení těchto problémů vytvořil 1C řízené zámky.

1C ovládané zámky

Uzamykací mechanismus byl přesunut na server 1C a na úrovni DBMS byla izolace snížena na minimum. Na MS SQL byla úroveň izolace snížena na Read Committed se sdíleným zamykacím mechanismem na platformě 8.2 a mechanismem pro správu verzí na platformě 8.3 (tzv. Read Committed Snapshot Isolation). Přesněji se jedná o stejnojmennou vlastnost databáze a dva provozní režimy Read Committed, které závisí na tomto parametru.

Na poslední úrovni izolace (RCSI) mechanismus umožnil neprotínat transakce čtení a zápisu na stejných zdrojích na serveru DBMS. Veškerou hlavní práci převzala blokovací služba 1C, která na základě nativních metadat určuje, zda povolit či nepovolit transakce na server DBMS, aby nedocházelo k narušení obchodní logiky. Problémy se zamykáním prázdných tabulek a rozsahů hranic jsou minulostí.

DBMS	Typ zámku	Úroveň izolace transakcí	Čtení mimo transakci
Automatické zámky
Databáze souborů	Tabulky	Serializovatelné	Špinavé čtení
MS SQL Server	Příspěvky		Špinavé čtení
IBM DB2	Příspěvky	Opakovatelné čtení nebo serializovatelné	Špinavé čtení
PostgreSQL	Tabulky	Serializovatelné	Důsledné čtení
Databáze Oracle	Tabulky	Serializovatelné	Důsledné čtení
Řízené zámky
Databáze souborů	Tabulky	Serializovatelné	Špinavé čtení
MS SQL Server 2000	Příspěvky	Přečtěte si Odhodlání	Špinavé čtení
MS SQL Server 2005 a vyšší		Přečtěte si Committed Snapshot	Důsledné čtení
IBM DB2 před verzí 9.7	Příspěvky	Přečtěte si Odhodlání	Špinavé čtení
IBM DB2 verze 9.7 a vyšší	Příspěvky	Přečtěte si Odhodlání	Důsledné čtení
PostgreSQL	Příspěvky	Přečtěte si Odhodlání	Důsledné čtení
Databáze Oracle	Příspěvky	Přečtěte si Odhodlání	Důsledné čtení

Chcete-li zjistit, v jakém režimu zamykání je databáze programu 1C, musíte v kontextu požadované databáze spustit následující požadavek od SSMS:

1C zámky. Uživatel nebude čekat na zámky, 1C se zrychlí, pokud budete dodržovat určitá pravidla:

• Doba trvání transakcí by měla být co nejvíce zkrácena. Provádění zdlouhavých výpočtů v transakci ve 100 % případů povede k zablokování při práci na systému OLTP.
• Odpadají dlouhé externí operace v rámci transakce, například odesílání a přijímání potvrzení e-mailem, práce se souborovým systémem a další doplňkové akce. Všechny operace musí být umístěny v odložených krátkých úkolech.
• Dotazy jsou optimalizovány na maximum.
• Indexy by měly být vytvářeny pouze podle potřeby, aby byl zajištěn optimální výkon dotazů v rámci aplikace.
• Začlenění často aktualizovaných sloupců do seskupeného indexu bylo minimalizováno. Aktualizace sloupců klíče seskupeného indexu vyžadují zámek jak na seskupeném indexu, tak na všech indexech bez seskupení (protože jejich řádek lokátoru obsahuje klíč seskupeného indexu).
• Kde je to možné, je vytvořen krycí index a používán ke zkrácení doby načítání dat.
• Použití nejnižší úrovně izolace transakcí, která bude vyžadovat přepnutí do režimu řízeného zamykání.

Nástroje pro diagnostiku blokování:

• Technologický časopis;
• Centrum řízení výkonu od nástrojů 1C;
• cloudové služby Gilev;

Níže je uveden příklad monitorování systému pomocí služby Gilev. Celková doba blokování je ~15 hodin. Více než 400 aktivních uživatelů. Po provedení rozhodnutí a optimalizace jsou časové limity kratší než minuta a počet blokování byl ~670krát snížen.

bylo:

Stal se:

V situaci, kdy „všechno visí a trvá to dlouho“ a monitorovací služby nejsou nakonfigurovány nebo se vůbec nepoužívají, je třeba se s ohledem na Paretův princip zaměřit na kód.

V automatickém režimu lze přítomnost zámků na serveru detekovat pomocí systémové procedury v kontextu požadované databáze. Tato uložená procedura vám umožňuje určit, v jakém režimu zámky fungují, jejich stav, typ atd.:

Po dokončení postupu pro 1C můžete získat vizuální informace o tom, co se aktuálně děje na serveru, s přihlédnutím ke specifikům tabulek 1C:

Fragment 1

//Zamkne z hlediska 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) as t Kde TableName1C NENÍ NULL ORDER BY t.Resource

Použití tohoto mechanismu umožňuje získat kompletní informace o aktuálních zámcích. Pokud sestava obsahuje pouze S-zámky, může být problémem dlouhotrvající dotaz nebo dotazy. Chcete-li zjistit příčinu a místo jejich výskytu v kódu, můžete se vydat různými cestami: použít objekty DMO SQL serveru (ale mějte na paměti, že data z nich se po restartu serveru resetují) nebo nakonfigurovat Data Collector, ukládání monitorovacích dat do tabulek po určitou dobu. Hlavní je získat texty problematických požadavků.

Použití SQL Server DMO Objects

Abychom pochopili relevanci dat, zobrazujeme datum zahájení serveru. Balíček jsme rozdělili podle hodnocení čtení (fyzické, logické, zatížení procesoru). V tomto případě se použijí kmenová data ze sys.dm_exec_query_stats. Text požadavku přeložíme do termínů 1C. Pokud z textu požadavku pochopíte kontext hovoru, nezbývá než se podívat na plán požadavku, najít problematické operátory a pochopit, co se dá dělat.

Fragment 2

//čas spuštění SELECT sqlserver_start_time FROM sys.dm_os_sys_info; //Nejčastější požadavky na fyzické čtení SELECT TOP (50) (total_physical_reads) AS Total_physical_reading,

Identifikace problematických dotazů v důsledku sběru dat

Pomocí tohoto nástroje můžete seřadit data podle potřebných parametrů, jako je zatížení procesoru, trvání, logické I/O, fyzické operace čtení, což vám umožňuje uložit kompletní statistiku pro další analýzu, a to i přes restartování SQL serveru.

Poté, co server shromáždí problematické požadavky bez monitorování třetí stranou, můžete přijatá data seřadit podle potřebných parametrů.

Dále zapnutím technologického deníku a zadáním v nastavení „hledat podle řetězce“ a části požadavku, na kterou zaručeně narazíte, zjistíte, odkud byl problematický požadavek volán. Pokud má server několik databází nebo je známé uživatelské jméno, vyplatí se přidat další pole pro filtr, aby se snížilo zatížení serveru při shromažďování protokolu procesů.

Příklad problematického požadavku a příklad nastavení technologického deníku:

Optimalizace dotazu jako příležitost k urychlení 1C 8.3

Důsledky neoptimálních dotazů se mohou projevit v podobě zdlouhavého zpracování dokumentů, bolestně dlouhého generování reportů, zamrzání systému a dalších nepříjemných událostí.

Při práci s požadavky NEMŮŽETE:

• Spojování tabulek pomocí poddotazů;
• Propojte běžné stoly s virtuálními;
• Použijte logické "OR" v podmínkách;
• Použijte poddotazy v podmínkách spojení;
• Přijímejte data přes tečku z polí složeného typu bez klíčového slova „Express“.

Při práci s požadavky MŮŽETE:

• Vytvářejte indexy pro podmínky dotazu, pole spojení, agregace a řazení;
• Filtrování virtuálních tabulek musí být provedeno pomocí parametrů výběru.

Použití indexů a jejich vliv na kvalitu výkonu systému

O indexech, nutnosti jejich použití a vlivu na kvalitu chodu systému toho bylo napsáno hodně. Pokusme se pochopit složitosti „designu“ indexů, aplikačních možností a výhod oproti běžným tabulkám.

Indexování je důležitou součástí jádra DBMS. Chybějící indexy, nebo naopak jejich nadměrný počet, ovlivnit rychlost načítání, úpravy, přidávání a mazání dat. Podívejme se na indexování na příkladu nejběžnějšího Microsoft DBMS.

Pro obecné pochopení toho, jak to funguje, se podíváme na detaily mechanismu ukládání dat, který si obvykle představujeme ve formě tabulky (například Excel).

Jednotkou fyzického úložiště dat je stránka – 8 KB modul, který patří pouze jednomu objektu (například tabulce nebo indexu). Stránka je nejmenší jednotka pro čtení a zápis. Stránky se shromažďují do oblastí. Rozsah se skládá z 8 po sobě jdoucích stran. Stránky rozsahu mohou patřit jednomu nebo více objektům. Když stránky patří více objektům, rozsah se nazývá „smíšený“.

Jeho obsah si můžete prohlédnout níže:

Nyní, když máme představu o tom, jak disková jednotka funguje, pojďme si promluvit více o tabulkách a indexech.

Ve výchozím nastavení, pokud nepoužíváte speciální příkazy T-SQL, je prázdná tabulka vytvořena jako "hromada" - jednoduchá sada stránek a rozsahů. Data v haldě nemají žádné logické pořadí. Motor SQL Server sleduje vlastnictví stránky a rozsahu konkrétního objektu pomocí speciálních systémových stránek nazývaných Index Allocation Maps. Každá tabulka nebo index má alespoň jednu stránku IAM, která se nazývá „první stránka IAM“.

Po vytvoření běžné tabulky je tedy standardně výsledkem chaotické uspořádání dat. Stav tabulky můžete zobrazit pomocí následujícího postupu:

Hlavní indexy používané platformou 1C

Fragment 3

Mýty a realita:

Mýtus první: seskupené indexy a datová tabulka jsou dvě různé entity, uložené odděleně od sebe.

Mýtus druhý: v jedné tabulce může být mnoho seskupených indexů.

Stáhl jsem si program pro optimalizaci DBMS. Vytvořené doporučené indexy. Rychlost vzorkování zvýšena o 50 %. Změna a přidávání dat se zpomalilo 7krát.

Clustered (clustered) index

Seskupené indexy jsou sada stránek, které třídí a ukládají řádky dat v tabulkách nebo pohledech na základě jejich klíčových hodnot – sloupců zahrnutých v definici indexu. U tohoto typu indexu je omezení na 16 sloupců a 900 bajtů. Pro každý stůl existuje pouze jeden seskupený index, protože datové řádky lze řadit pouze v jednom pořadí. K vytvoření seskupeného indexu dochází reorganizací tabulky, nikoli kopírováním dat, což umožňuje, aby byla tabulka uložena jako vyvážený strom.

Fragment 4

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("Trace Data")

Neshlukovaný index

Neklastrované indexy mají strukturu oddělenou od datových řádků. Neklastrovaný index obsahuje hodnoty seskupeného indexového klíče a každý záznam obsahuje seskupený indexový klíč (nikoli RID, protože tabulky 1C až na vzácné výjimky nepoužívají haldy).

Můžete přidat neklíčové sloupce na úroveň listu neklastrovaného indexu a obejít stávající limit indexového klíče (900 bajtů a 16 klíčových sloupců) spuštěním plně indexovaných dotazů.

Po přidání indexu bez klastrů byla data zkopírována a objevil se další objekt:

Fragment 5

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("Trace Data")

Schéma seskupeného indexu po jeho načtení z haldy ve formě vyváženého stromu:

Schéma neseskupeného indexu odvozeného z seskupené tabulky (všimněte si, že sloupec lokátoru řádků má seskupený indexový klíč):

Vliv indexů na výkon dotazů

Pomocí indexu optimalizátor dotazů prohledává klíčové sloupce v indexu, najde, kde jsou uloženy řádky dotazu, a načte odtud odpovídající řádky. Prohledávání indexu je mnohem rychlejší než prohledávání tabulky, protože na rozdíl od tabulky index často obsahuje méně sloupců na řádek a řádky jsou seřazeny podle pořadí.

Vytvoření více indexů vede k tomu, že se zvýší vzorkovací rychlost a výrazně se sníží rychlost zápisu při úpravě. Chcete-li tento problém vyřešit, musíte nejprve odstranit nepotřebné indexy nebo je nejprve zamknout, aniž byste je smazali, což vám umožní jednoduše je povolit, pokud taková potřeba nastane.

Upozorňujeme, že seskupený index nelze za žádných okolností zablokovat, protože tím se zablokuje přístup k datům tabulky. To platí pouze pro indexy, které jste sami vytvořili prostřednictvím T-SQL. Důvod pro vytváření indexů pomocí T-SQL, obcházení 1C:Enterprise, je spojen především s omezenými možnostmi platformy 1C, pokud jde o manipulaci s indexy a zahrnutí dalších polí do vytvořeného indexu.

Příkaz T-SQL, který provádí akci uzamčení indexu:

//Zamknutí samostatného indexu v tabulce -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Zahrňte požadovaný index -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

Kromě výše uvedených kroků je důležité vytvořit skupinu souborů na fyzickém disku, který nebude obsahovat aktuální databázové soubory, a přesunout tam indexy bez clusterů. To urychlí úpravu dat paralelizací jejich záznamu.

Určení, které indexy jsou potřebné nebo nepotřebné pro urychlení dotazů

Ve výchozím nastavení 1C vytváří určitou základní sadu indexů. Často jich prostě není dost. SQL Server má mechanismy, které vám umožňují na základě vaší pracovní zátěže pochopit, jak potřebné jsou vaše stávající indexy.

Nástroj Database Engine Tuning Advisor analyzuje databáze a poskytuje doporučení pro optimalizaci výkonu dotazů. Lze jej použít k výběru a vytváření optimálních sad indexů, aniž byste měli odbornou úroveň znalostí návrhu databáze nebo interních procesů serveru SQL Server. Nástroj Database Engine Configuration Assistant vám umožňuje provádět následující úlohy:

• Odstraňování problémů s výkonem konkrétního problematického dotazu;
• Nakonfigurujte velkou sadu dotazů v jedné nebo více databázích.

DMO (dynamic management objects), které zahrnují pohledy dynamické správy a funkce dynamické správy. Například příkaz T-SQL může načíst všechny indexy, které nebyly použity od posledního spuštění serveru.

Fragment 6

WITH vl as (SELECT OBJECT_NAME(I.object_id) AS objectname, I.name AS indexname, I.index_id AS indexid FROM sys.indexes AS I INNER JOIN sys.objects AS O ON O.object_id = I.object_id WHERE I.object_id > 100 AND I.type_desc = "NEZAHRNUTÉ" A I.index_id NENÍ VLOŽENO (VYBERTE S.index_id Z sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id AND I.index_id=S.index_id AND database_id = DB_ID("database_name '))) SELECT objectname,T1.NameTable1C, indexid, indexname FROM vl OUTER APPLY dbo.ReturnTableName1C(objectname) as T1 ORDER BY objectname, indexname;

Pokyny, které lze použít k vytvoření potřebných indexů doporučených jádrem DBMS:

Fragment 7

SELECT T1.NameTable1C jako Table_Name_1C, "CREATE INDEX" + "ON"
Optimalizátor dotazů při generování plánu provádění dotazů identifikuje potřebu vytvořit chybějící index. Tyto informace ukládá do XML ShowPlan. Protože plány dotazů jsou hashovány a instrukce jsou uloženy (až do příštího restartu serveru), poté je lze načíst, zpracovat a připravit instrukce pro vytvoření nezbytných indexů pro jakýkoli plán provádění v mezipaměti. Stojí za to věnovat pozornost frekvenci provádění dotazu: čím vyšší je, tím relevantnější jsou výsledky dotazu, a tedy i shromážděné ukazatele. Pokud byl dotaz proveden jednou, jeho výsledky nejsou tak orientační.

Fragment 8

CROSS APPLY query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/Missinglndexes") = 1) VYBERTE TOP 30 Název databáze jako název_databáze, název_tabulky jako název_tabulky, kvalita_T1C1 název_tabulkyC ns jako Comparison_columns, include_columns jako Columns_to_include,

Fragment 9

POUŽÍVEJTE [Database_name] VYTVOŘTE NEZAHRNUTÝ INDEX NA .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) INCLUDE ([_Date_Time],[_Fld12771_RRRef],[72RRFld]GO17 Některé funkce indexování podle agregačních polí a třídicích polí.

Vytvoření indexu na sloupcích zadaných v klauzuli ORDER BY pomáhá optimalizátoru dotazů rychle uspořádat sadu výsledků, protože hodnoty sloupců jsou v indexu seřazeny předem. Interní implementace mechanismu GROUP BY také nejprve třídí hodnoty sloupců, aby rychle seskupila požadovaná data.

Při použití standardních doporučení se vyplatí zkontrolovat výsledek před a po optimalizaci. Uveďme příklad použití logického spojení „OR“ a jeho alternativu (pro vyřešení problému pomocí standardních doporučení) - techniku ​​změny dotazu pomocí syntaxe „UNITE ALL“.

Samotný požadavek 1C s „NEBO“:

SELECT Code, Name, Link FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "000000004" NEBO Counterparties.Code = "0074853" OR Counterparties.Code = "000000024" OR Counterparties.Code = "000024" OR Counterparties.Code = "000024"OR Counterparties.Code = "000004" 0074742" NEBO Protistrany.Kód = "000000104";

Úprava dotazu pomocí „UNITE ALL“:

SELECT kód, jméno, odkaz z adresáře. Protistrany JAKO protistrany WHERE Protistrany. Kód = "000000004" KOMBINOVAT VŠECHNY SELECT kód, název, odkaz z adresáře. Protistrany JAKO protistrany WHERE Protistrany. Kód = "0074853" KOMBINOVAT, VŠECHNY SELECT kód, název FROM Directory.Protistrany JAKO Protistrany WHERE Counterparties.Code = "000000024" KOMBINOVAT VŠECHNY SELECT Kód, Název, Odkaz Z Directory.Protistrany JAKO Protistrany WHERE

Aktuální plán dotazů (pro snadné zobrazení a porovnání výkonu, dotazy zachycené a provedené v SSMS):

V tomto případě po optimalizaci klesl výkon na polovinu kvůli opakovanému použití operátoru Key Lookup, který je vždy doprovázen operátorem Nested Loops. Proto byste při použití schématu optimalizace dotazů měli měřit cílový čas před a po použití vylepšení. Tento příklad je uveden pro účely „důvěřuj, ale prověřuj“, protože mezi typickými doporučeními a praktickými problémy může být nesoulad.

Jak zrychlit práci v 1C: Účetnictví 8.3 (edice 3.0) nebo deaktivovat rutinní úlohy a úlohy na pozadí

2019-01-15T13:28:19+00:00

Ti z vás, kteří již přešli na nové vydání 1C: Accounting 8.3 (edice 3.0), si všimli, že je pomalejší než 2. Nějaká podivná zpomalení, nekonečné úkoly na pozadí několikrát denně, o které ji nikdo nežádal bez našeho vědomí.

Moji účetní mi hned po přechodu řekli, že nové vydání 1C: Accounting 3.0 je ve srovnání s předchozími vyloženě pomalé! A to se prostě nedá fungovat.

Začal jsem se tím zabývat a velmi brzy jsem zjistil, že hlavní příčinou zamrzání a následné nespokojenosti uživatelů jsou rutinní úkony a úkony na pozadí, z nichž mnohé jsou standardně povoleny, ačkoli pro drtivou většinu účetních nejsou potřeba.

Proč například potřebujeme spouštět úlohu „Extrakce textu“ stokrát denně, když neprovádíme fulltextové (účetní, nelekejte se) prohledávání všech objektů v naší databázi.

Nebo proč neustále stahovat kurzy měn, když nemáme měnové transakce nebo je děláme příležitostně (a předtím můžeme sami kliknout na tlačítko stahování kurzů).

Totéž platí pro neustálý pokus 1C připojit se k webu a kontrolovat a aktualizovat klasifikátory bank. Proč? Já sám stisknu tlačítko pro aktualizaci klasifikátorů, pokud nenajdu správnou banku podle jejího BIC.

Jak to udělat krok za krokem níže.

1. Přejděte do sekce „Správa“ a na panelu akcí vyberte „Údržba“ ():

2. V okně, které se otevře, najděte a vyberte „Rutinní úlohy a úlohy na pozadí“:

3. Otevřete každý úkol, který má ve sloupci „Zapnuto“ hodnotu „Zapnuto“. tam je úprk.

4. Zrušte zaškrtnutí políčka „Povoleno“ a klikněte na tlačítko „Uložit a zavřít“.

5. Udělejte to s každým ze zahrnutých úkolů a užijte si nové vydání. Celkově je to podle mě mnohem lepší než dvojka.

Zároveň bude platforma stále povolovat některé naplánované úlohy, které jste zakázali.

Systém 1C je dnes jedním z hlavních nástrojů pro řízení malých a středních podniků. Přístup k programu mají zpravidla všichni zaměstnanci organizace. Pokud tedy 1C začne zpomalovat nebo pracovat pomalu, výrazně to ovlivní podnikání. Pojďme se podívat na to, jak si můžete zrychlit a optimalizovat práci v 1C sami.

Optimalizace pomocí aktualizace 1C

Nové verze 1C vždy fungují úspěšněji a rychleji, takže je nutné sledovat aktualizace. Doporučujeme aktualizovat své účetní záznamy co nejčastěji. Zvláště když jsou vydány verze regulovaného výkaznictví.

Mnoho lidí již dlouhou dobu využívá možnost automatické aktualizace programu. Ačkoli lze tento problém pro 1C Enterprise 8.3 snadno vyřešit ručně, aktualizace nezpůsobí žádné potíže.

Prvním krokem je stažení nejnovější verze platformy, kterou aktuálně používáte. To se provádí buď pomocí disku ITS, nebo prostřednictvím webového rozhraní, kde poskytují průběžnou podporu uživatelům programu, jako je 1c Enterprise 8.3, jehož aktualizace konfigurace je také oficiálně poskytována.

V druhém případě se archiv s aktualizačními daty stahuje samostatně. Rozbalí se do libovolné složky, která je pro uživatele považována za nejvhodnější. Poté musíte spustit soubor .exe. V dalším okně jednoduše klikněte na tlačítko „Další“.

Objeví se další stránka. Na něm uživatel vybere cestu, ve které je instalace dokončena. Tento krok se však doporučuje pouze pokročilým majitelům osobních počítačů. Výchozí funkce obvykle postačují k vyřešení většiny problémů. Ve výchozím nastavení je v tomto případě určena jedna složka, kam se nainstalují všechny aktualizace najednou. To je mnohem pohodlnější, než když jsou konečné cesty jiné. Jednoduše několikrát klikneme na tlačítka „Další“ v programu 1c Enterprise 8.3, jehož konfigurace by se měla rychle aktualizovat.

Zbývá pouze poslední tlačítko, které nabízí „Instalovat“.

Jak zrychlit 1C, pokud je platforma pomalá

Problémy nejčastěji vyplývají ze skutečnosti, že v jedné z fází klesá koncentrace pozornosti interpreta. Zde je důležité zvolit správné schéma aktualizace, pouze v tomto případě nenarazíme na problém, kdy při aktualizaci 1c zamrzne.

Aktualizace verze 7.7

Existuje několik typů konfigurace. Podle toho se volí průběh dalších úkonů.

• Standardní – v tomto případě se předpokládá, že aktualizace se provádí i pro regulované výkaznictví.
• Typické průmyslové konfigurace do značné míry připomínají předchozí možnosti. Je důležité si předem přečíst pokyny poskytnuté vývojářem. V opačném případě nebudete schopni zjistit, proč se 1C 8.3 během aktualizace zhroutí.
• Upravený standard - uživatel má vždy možnost si aplikaci sám upravit tak, aby odpovídala aktuálním potřebám. Další možností rozšíření funkčnosti je přechod na nové platformy. Například verze 8.

O verzi 8.0 a 8.1

V současné době je již platforma 8.0 stažena z podpory. Nový standardní vývoj bude fungovat pouze při použití nejnovějších verzí. Jen si musíte pamatovat, že všechna přechodná vydání jsou dokončena bez problémů. V opačném případě existuje vysoká pravděpodobnost pouhé ztráty informací. Nebo narazíte na situaci, kdy 1c zamrzne při aktualizaci konfigurace.

Možnost je možná, když je implementována nová standardní konfigurace a poté jsou do ní přeneseny zbytky ze starých informačních databází.

Pokud jde o verzi 8.1, můžete ji aktualizovat několika způsoby:

1. ručně;
2. v automatickém režimu;
3. kontaktování specialistů z firem poskytujících služby v této oblasti.

Práce s nestandardními nebo upravenými verzemi

Zpočátku se jakákoli konfigurace týká standardního vývoje. Přestává jím být, pokud jsou v podniku provedeny určité změny. Například při instalaci. Mezi nestandardními konfiguracemi vynikají dvě třídy:

1. změněno;
2. vytvořené od nuly s přihlédnutím k potřebám konkrétního podniku.

Někdy je konfigurace druhé třídy aktivně distribuována mezi uživatele. Pak se to považuje za typické. Je to tak, že výrobce není považován za samotný 1C, ale za společnost, která vytvořila novou verzi.

Konfigurace lze udržovat v aktuálním stavu pomocí následujících akcí:

• Oprava chyb.
• Rozšíření funkčnosti.
• Zlepšení.
• Změna v 1C 8.3, konfigurace se neaktualizuje v případě chyb údržby.

Instalační proces může trvat různou dobu v závislosti na rychlosti internetu, se kterou jej aktuálně používáte. V samostatném okně si uživatel vybere, zda provést aktualizaci po dokončení práce, nebo ihned. U druhé možnosti se musíte ujistit, že s aplikací nepracuje nikdo jiný. Samotný proces zahrnuje použití exkluzivního režimu v rámci aplikace 1c Enterprise 8.3, poslední aktualizace není výjimkou.

• Musíme si pamatovat, že ne všechny vydané verze mohou být vhodné pro aktuální konfiguraci.
• Pokud aktualizace nebyly prováděny po dlouhou dobu, možná budete muset stáhnout několik souborů nebo archivů najednou.
• V seznamu je snadné pochopit, která verze 1C Enterprise 8.3 je potřebná, aktualizaci vybírá uživatel.

Po dokončení procesu lze samotný konfigurátor zavřít. Tento režim se nejčastěji používá, pokud je nutná aktualizace. Je to pohodlné a automatizuje téměř celý proces. Při prvním spuštění se může zobrazit zpráva, že platforma je zastaralá. A že se to v aktuální chvíli nedoporučuje používat.

Další důvody pro brzdění

Pokud je program aktualizován správně a bez chyb, 1C se však stále zpomaluje, může být důvod následující:

• Antivirus - pokud je správně nakonfigurován, žádný antivirus nebude zasahovat do systému, ale pokud použijete tovární nastavení, výkon 1C se může snížit o 5–10%. Svůj antivirus můžete optimalizovat pomocí dalších nastavení odstraněním režimu na pozadí (je-li to nezbytně nutné).
• Parametry počítače – často nedostatečně výkonné počítače vedou k výraznému poklesu výkonu 1C. Zvláštní pozornost je třeba věnovat grafické kartě, operačnímu systému a procesoru.

Takové metody výrazně optimalizují a urychlí práci v 1C pro jakoukoli společnost nebo podnik, poté se výkon programu výrazně zvýší.

Jak zvýšit rychlost a snadnost použití v 1C

Příznaky a anamnéza pacienta:

Práce několika uživatelů v síti se stejným souborem (databází) zahrnuje mechanismus blokování sítě. To nutí systém ztrácet drahocenný čas identifikací otevřených relací nahrávání a odpovídajícím řešením konfliktů.

Hlavní příznaky blokování:

• rychlá uživatelská práce s databází po síti v exkluzivním režimu a extrémně pomalá, když několik uživatelů pracuje současně
• rychlá uživatelská zkušenost s lokální databází na serveru a pomalá práce po síti
• přístupy k systému souborů jsou těsně pod 10 MB/s

Dostal jsem tedy za úkol zajistit, aby v 1C mohli pracovat až tři uživatelé současně! Legrační, že?

Zapomněl jsem na všechny vtipy, když jsem viděl, s čím jsem se musel vypořádat: „server“ v podobě obyčejného kancelářského počítače a dvou notebooků.

Štěstí by bylo neúplné, nebýt úžasných operačních systémů – Windows 7 na počítači a na jednom notebooku, Windows 8 na druhém.

Při pokusu o současné odesílání dokumentů na notebooky se jeden zasekl asi na minutu a druhý se zhroutil z 1C s chybovým textem „nelze zamknout stůl...“.

Spuštění 1C na notebooku je samostatná show, která trvala asi 3 minuty!

Na mnoha zdrojích jsem narazil na radu, jak přejít na práci v terminálovém přístupu. Windows 7 bohužel neumožňují proměnit se v terminálový server pomocí standardních nástrojů - aktivní je maximálně jedno připojení. V tomto případě se zbývající relace neukončí; můžete se znovu připojit pod jiným uživatelem - „vyhodit“ předchozího uživatele, ale bez ukončení jeho relace. Proto byste měli přenést 1C na serverový OS, kde žádná taková omezení neexistují. Klient na vlastní nebezpečí vyřešil problém pomocí nástroje třetí strany Windows7_SP1_RDPhack.

Tím ale dobrodružství neskončila. I v koncovém spoji docházelo ke značným zpožděním. Opět mi pomohly všemocné vyhledávače. Níže jsou uvedeny tipy pro urychlení souboru 1C, podle kterých jsem se řídil:

1. Zakázat použití síťového protokolu IPv6, nakonfigurujte adresování na „staré“ IPv4.

2. Přidejte procesy 1C do výjimek firewallu Windows, stejně jako do výjimek antiviru, nebo je úplně zakažte (rizikovější, ale jednoduchý test ukázal zvýšení rychlosti opětovný přenos dokumentů, když je antivirus Avast vypnutý faktorem!)

3. Spusťte indexování fulltextového vyhledávání v 1C nebo jej úplně vypněte

4. Spusťte Testování a opravu databáze, kontrolu pomocí nástroje ChDbfl

5. V konfiguraci spusťte položku Check Configuration (pokud konfigurace není standardní, může být užitečná). Na základě výsledků kontroly konfigurace se magicky zmenšil téměř o třetinu. Opravdu jsem se neponořil do toho, co přesně příchozí programátoři přede mnou aktualizovali, ale skutečnost je zřejmá.

6. Vypněte nepotřebné funkční možnosti.

7. Nastavte uživatelská práva. (Tato i předchozí rada mi připadala hloupá, dokud jsem nepozoroval vykreslování spravovaných formulářů při otevírání seznamu dokumentů. Čím méně zbytečné ve spravovaném rozhraní, tím zpravidla rychleji funguje)

8. Začněte přepočítávat součty a obnovovat sekvenci (výrazný nárůst může nastat pouze v případě, že součty nebyly obnoveny delší dobu)

9. V nastavení seznamu databáze zadejte "Rychlost připojení - nízká" (to nepřineslo mnoho výsledků, kromě toho, že byly vypnuty obrazy subsystémů :))

Po dokončení všech těchto kroků začala databáze souborů 1C pracovat mnohem rychleji. Spouštět se začal maximálně za 10 sekund a rychlost přenosu dokumentů se zvýšila v průměru 12x.

Možná vám tento krátký článek bude užitečný, pokud náhle potřebujete zrychlit databázi souborů 1C.

P.S: Ale spustit soubor 1C pomocí síťového přístupu ke sdílené složce je stále nereálné, protože... I ten nejrychlejší SSD, RAM a procesor se zablokují v síti a práce více než jednoho uživatele bude prakticky nemožná. Mluvíme konkrétně o konfiguraci UT 11.1. Samostatně psané malé konfigurace mohou fungovat poměrně rychle i ve verzi souboru.

Dodatky z komentářů pro zveřejnění:

Defragmentace disku se základnou souboru

Konvoluce databáze (může být užitečné, pokud je databáze velká, například několik let). Databáze klienta byla poměrně mladá, takže redukce byla nepraktická.

Upgrade hardwaru - rychlejší pevný disk, nový přepínač, procesor atd.

Nainstalujte na webový server, přístup pomocí tenkého klienta. Zde jsou názory rozděleny. Někteří říkají, že je mnohonásobně rychlejší, jiní říkají, že není zaznamenáno žádné zrychlení.