Background configuration update. Browser update. Ending sessions and trying to update

To call the background database configuration update operation, select the menu item Configuration - Database configuration - Background database configuration update.

Rice. 24. Database configuration background update dialog

Clicking the Start button starts the processing phase. The following text is displayed in the service message window:

The start of the background update of the database configuration was successful. The configuration is not available for editing. A background update of the database configuration is in progress.

After starting a background update, the configuration is blocked from being changed. During the execution of any phase, the operation of the background update can be suspended using the Suspend button. To continue the background update, use the Continue button.

After the end of the processing phase, the update phase begins, during which you can switch the system to the phase of accepting changes using the Finish button or cancel the update using the Cancel button.

ADVICE. It is recommended to cancel a running background database configuration update process in cases where the background database configuration update is not scheduled to complete (for example, the process is put on an infinite "pause"). The implementation of this recommendation will positively affect the characteristics of the system, since there will be no registration of changes for the actualization phase.

Checkbox Allow dynamic update is used to determine whether, when you click the Start button, you want to try to perform a dynamic update instead of starting a background database configuration update process. If this checkbox is checked, then immediately after clicking the Run button, a check will be made to see if it is possible to perform a dynamic configuration update. In the case where the configuration allows this possibility, a dynamic update of the database configuration will be performed instead of a background update of the database configuration.

The Run on server checkbox is used to determine where the start, end, and cancel will be performed. If this checkbox is cleared, then these actions will be performed on the side of the client application, and if checked, then on the side of the 1C:Enterprise server. In addition, if this check box is selected, then you can only update the configuration if you have the UpdateDatabaseConfiguration right, without the Administer right set.



Saving the database configuration to a file

To save the database configuration to a file on disk, select Configuration - Database configuration - Save database configuration to file. A standard file selection dialog is displayed on the screen. You must select a directory and specify the name of the file in which the database configuration will be written.

The saved database configuration file is required for the compare and merge configurations operation (see here).

Comparison of configuration and database configuration

If in the process of making changes to the configuration you want to receive a report on differences from the database configuration, then you should select the item Configuration - Database configuration - Compare, merge with the database configuration.

If necessary, you can restore changed objects.

Opting Out of Configuration Changes

To discard changes in the configuration, just select the item Configuration - Database configuration - Revert to database configuration.

NOTE. The menu items Save database configuration to file... and Revert to database configuration are available even if the configuration being edited is closed. The Revert to DB Configuration command is still unavailable when information base connected to the configuration store.

Launch of 1C:Enterprise

The configurator provides for launching the 1C:Enterprise mode. To do this, select the item Service - 1C: Enterprise. It is often necessary to start 1C:Enterprise in debug mode. To do this, there is a commandDebug - Start debugging (for more details about the debugger, see here).

If the configuration has been modified (changes have been made), then the configurator displays the question: The configuration being edited differs from the database configuration. Do you want to update the database configuration? To save the changes, select the Yes button.



If the No button is selected, then the 1C:Enterprise mode starts without saving the configuration.

In case of failure, the following question is displayed on the screen: The database configuration does not match the saved configuration. Proceed? If the OK button is selected, the 1C:Enterprise mode starts with the previous database configuration. If the Cancel button is selected, then 1C:Enterprise mode is not launched.

The question we raised in the title of the article is relevant for many system administrators working with this product. As far as possible, we try to talk about the parameters that affect the performance of 1C and debunk popular myths. Today, using the example of one recent case, we want to tell you about another aspect that can seriously affect performance - scheduled tasks.

Let's start with a real case. Not so long ago, one of our clients contacted us with a complaint about the "brakes" 1C from one of his employees. The symptoms were expressed in the fact that after a certain period of time, the Trade Management 10 configuration began to slow down a lot, or, in other words, it hung for a while.

With more detailed analysis situation, it turned out that this happens only for one employee, and at any workplace, it happens for a long time, but if earlier the "brakes" lasted about a second, now, after the update, they can last up to 15-20 seconds, which makes the work extremely uncomfortable .

In principle, the initial data is already enough to draw the first conclusions. Let's take them again:

  • "Brakes" occur constantly, with a certain frequency
  • "Slows down" only for one user
  • "Slows down" at any workplace

To confirm our guesses, let's look at Accounting Settings:

Indeed, the "problem" user is listed as a user to perform routine tasks. As it turned out, once upon a time on behalf of this user, the RIB auto-exchange task worked. It remains to be seen what exactly was the cause of the episodic "braking". This is also easy to do:

And here is the "hero of the occasion" - the task of updating the full-text search index, which was launched once every 2.5 minutes. In this case, the problem was completely solved by disabling the execution of scheduled tasks under this user, but this is not always possible or advisable, so below we will consider how to manage routine tasks and how to ensure that they do not have a negative impact on performance.

General Application

In configurations based on a regular application, there is no single toolkit for managing scheduled tasks. This is largely due to the fact that at the time of their initial development, the very concept of procedural tasks was developed rather poorly.

Many scheduled tasks are managed through the configuration of subsystems associated with them. For example, settings for routine tasks related to data exchange should be looked for in the exchange settings related to the Unified State Automated Information System in the alcohol trade settings, etc.

At first glance, everything is quite logical, but the lack of a single tool makes it difficult to control the configured scheduled tasks and the optimality of their settings. Well, if there are one or two tasks, and if there are more of them or, as in our case, there is a suspicion of any of the scheduled tasks, but you have no idea who and what set up in this database.

In this case, you should use external processing ConsoleQuests (JobsConsole), which is included in the set of standard processing on the ITS disk. Processing provides a single interface for all jobs and allows you to centrally configure them, as well as control those running in current time tasks.

This list should be carefully studied, all unnecessary tasks should be turned off, and the necessary ones should be scheduled in accordance with urgent needs and common sense. For example, in our case, there is no need to process EGAIS responses once every 30 seconds (this setting is made for testing) and in operating mode it will be enough to do this, say, once every half an hour.

Managed application

In configurations based managed application scheduled tasks are assigned a more significant role, with their help various tasks can be performed to maintain the information base and keep it up to date, but at the same time, it is the scheduled tasks that most often cause "brakes".

To manage routine tasks, there is a hotel item in the menu Administration - Support and Maintenance.

It can be immediately noted that tasks have increased significantly (for example, we took the same configuration - Retail) and their competent configuration can significantly improve the performance of the infobase. The default settings are made by 1C based on the needs of an average spherical firm in a vacuum and are not even close to optimal.

First of all, we disable what is clearly unnecessary, with which you do not work. Then we optimize the schedule of rarely used functions, for example, updating the bank classifier in Retail, as well as checking counterparties, can be done once a week during non-working hours or at the end (beginning) of the working day.

Special attention should be paid to everything related to the search index. Full-text search is certainly a convenient thing, but working with its index is a very, very resource-intensive task. Therefore, you should not go to extremes and abandon it, but you should seriously review and adjust its parameters.

Let's start with text extraction, this operation allows you to search the contents of the attached files, so if you do not use them, do not search for them, or you have only images there, then this operation can be disabled, in any case, to perform it once every 85 seconds - an obvious enumeration.

PPA index update- one of the most resource-intensive operations, by default it is performed once a minute.

Now let's think about how often information is added or updated in the database that you most often search for? Obviously not every minute, so it will be enough to update the index much less often: once an hour, once a day, or even once a week.

The same applies to merger of the PPD index, if you update the index once a day, then you should set the merge to run once a week, while choosing the least disruptive time as the start of the job.

These simple operations will allow you, without much damage to the functionality of the configuration, to increase the comfort of working with it on new level by refusing to frequently perform rather resource-intensive operations. Just do not go to extremes, correctly judge how much you need certain features and how often you should complete the tasks associated with them.

  • Tags:

Please enable JavaScript to view the

The bpm’online mobile application has a mechanism for synchronizing the application structure, which can work in the automatic background mode. To manage this process, use the [Update check frequency] system setting (Fig. 1).

Rice. 1. - System setting [Frequency of checking for updates]

This setting specifies after what time (in hours) mobile app can request configuration changes from bpm’online. If the setting is set to 0, then the application will always download configuration updates.

Working conditions

The application starts structure synchronization in the background only if the following conditions are met:

  • on the mobile device iOS or Android platform is used;
  • synchronization has not been started before;
  • More time has elapsed since the structure was last synchronized than indicated in system setting[Frequency of checking for updates];
  • the application is being launched, or the application is being activated (i.e. if it was previously minimized or accessed from another application).

If changes were received during the structure update, then the application will automatically restart to apply the received changes when the user minimizes it or switches to another application.

Features of work on different platforms

    On the Android platform, the background mode is implemented through a parallel running service. This approach ensures that the running synchronization is guaranteed to complete, even if you manually unload the application from the device's memory.

    On the iOS platform, the second one is used to start synchronization in the background. webView, while the app itself is running mostly webView. This ensures that the user is able to work normally in the application while structure synchronization is running at the same time.

    Unlike the implementation on the Android platform, this does not guarantee 100% completion of the synchronization, since the synchronization can be interrupted when the application is unloaded manually or if the iOS platform does.

    On the Windows 10 platform, the application at startup checks (not in the background) for updates on the server.

    If updates are available, a page with relevant information will be displayed.

The upgrade process consists of a series of steps that must be performed sequentially. As a result of a clear step-by-step execution of each of them, your configuration will be updated to the one you selected.

To receive the 1Cv8.cfu update file(s), send a request with a listing required list release files to e-mail or leave a request in . The update files will be placed in the directory of user profile service files:

If you are upgrading in a release-to-release sequence, make sure that this option is possible. Otherwise, download all required update files.

The configuration update must be done database administrator.

  1. Warn users about maintenance work on the database and the need to save their data and exit the database before completing the upgrade procedure.
  2. Make a backup copy of your infobase.
    backup can be created using the infobase upload mode. For this:
  • run the 1C:Enterprise system in the "Configurator" mode;
  • in the "Administration" menu, select the "Unload infobase" item;
  • in the dialog that opens, specify the name of the file to which the data will be written.

  1. During the configuration update, scheduled and background tasks should not run:
  • If there are scheduled tasks, they must be disabled during the configuration update.
  • If modifications have been made to the configuration that cause background jobs to run, they should be disabled while the configuration is being updated.
  • After updating the configuration, jobs can be allowed again.
  • Start the 1C:Enterprise system in the "Configurator" mode.
  • Open the configuration, to do this, in the "Configuration" menu, select the "Open Configuration" item.
    1. Call the "Update configurations" mode, to do this, in the "Configuration" menu, the "Support" submenu, select the "Update configuration" item.

    1. In the update selection dialog, select "Select update file" as the update source, and then select desired file updates (default 1cv8.cfu).

    1. In the "Updating configurations" window, click the "Finish" button to continue updating the configuration and "OK" to start updating the configuration:

    1. When completed, the "Configuration" window will open, containing the configuration with the changes made. Perform a configuration update:

    1. Check in 1C:Enterprise mode the correctness of the update procedure. If errors are found, if necessary, the database can be restored from a backup.

    Storing backups increases the amount of occupied disk space, in case of exceeding the available volume over the volume according to your current tariff plan You will be billed.

    Print (Ctrl+P)

    Database Configuration Object Tree

    You can open the database configuration window to view the database configuration structure, properties, forms, layouts, and other information about objects. To do this, select the item Configuration - Database configuration - Open database configuration window. In appearance, it does not differ from the Configuration window.

    Techniques for working with objects and database configuration are the same as for working in the Configuration window, with the only difference being that all objects are read-only (viewable).

    Updating the database configuration

    During configuration editing, new objects can be created, existing ones modified, or existing objects deleted.
    The current database structure may be different from the configuration structure. Differences between configurations are shown in the title of the Configuration window with symbols.
    NOTE. Mark of distinctionconfigurations appears only after saving the changes in the main configuration. However, after saving the main configuration, you can continue making changes, and in this case, in the title of the Configuration window
    there will be signs of change for both configurations.
    In order to reconcile configuration and database configuration, you must upgrade the database configuration. To do this, select the item Configuration - Update database configuration. If the main configuration has not yet been saved, the configurator will first save it, and then update the database configuration.
    If a message box was opened when updating the database configuration, it is cleared.
    ATTENTION! Upgrading the database configuration may require all users to stop working.
    Before upgrading, you can compare configurations, as well as merge them.
    If debugging was in progress when the database configuration was updated, then after saving the current configuration, the following question is displayed on the screen: To update the database configuration, you must stop debugging. Proceed? If you answer Yes, debugging stops and the database configuration is updated. If the answer is No, no update is performed and debugging does not stop.
    Updating the database configuration requires the configurator to have exclusive access to the infobase. Depending on the presence of users working with the database, and their modes of operation, there are several options for the system behavior:
    1. The configurator issues an exclusive lock error message if:
    ● the file version of the database is used;
    ● there are sessions connected to the infobase without using a web server;
    ● no sessions running through the web server;
    ● Configuration update requires database restructuring.
    2. The configurator offers to end all sessions and repeat the update if:
    ● configuration update requires database restructuring;
    ● the file version of the infobase is used by web clients or thin clients connected via a web server;
    3. in other cases, the configurator offers to perform a dynamic update.

    Note 1: Diagnostic messages indicate the characteristics of the sessions that prevent the action from being performed. If the number of sessions is less than or equal to 5, then a detailed list of sessions is displayed (including the computer name, such as
    applications, etc.), otherwise the total number of sessions is displayed.
    Note 2. Operating an infobase in exclusive mode does not transfer the infobase Microsoft data SQL Server into single user mode.
    Note 3. To speed up the infobase restructuring process, when using Microsoft SQL Server DBMS, it is recommended to set the recovery mode for the database to Simple or Bulk-logged. shift
    mode can be performed either before performing a restructuring or on an ongoing basis if it is not necessary to restore the database to an arbitrary point in time. Before changing the database recovery mode, you must
    execute backup Database!

    Exclusive access error

    If the system cannot obtain exclusive access, then it is only possible to wait until users are disconnected from the infobase and repeat the update operation.

    Ending sessions and trying to update

    If all sessions must be ended to update the database configuration, a message is displayed to the user.
    If a command is selected End sessions and repeat, then the user is asked to confirm the selected action (Ending sessions will crash users! Do you want to end sessions?), and if
    If the answer is yes, an attempt is made to terminate all sessions of the infobase. Then an attempt is made re-save database configuration.
    Terminating all sessions will cause all client applications to crash.
    There may be situations where it is not possible to terminate a session. For example, the file version of the infobase is published
    on a web server that requires a client certificate to access, or on a web server that is configured for authentication and requires a username and password for access. At the same time, connections to the infobase are made only using
    web server. The configurator does not support authenticated access to the web server and therefore cannot attempt to end sessions. In the event that the Configurator was unable to terminate sessions of access to the infobase, an attempt to update the database configuration can either be made later or the sessions can be terminated in other ways.
    Dynamic update
    If it is possible to perform a dynamic update, a special message is displayed to the user (see Figure 28).

    Dynamic update

    If the Update Dynamic command is selected, the update is performed without shutting down users. It is assumed that the changes made will be recorded dynamically as a version of the configuration changes (the database configuration is not changed). It is allowed to make repeated changes to the main configuration. If, during the next attempt to update the database configuration, the exclusive mode of operation can be set, the configurator updates the database configuration taking into account all changes (both current and previous ones).
    If a dynamic update was performed, then the users working at that moment continue to work with the old configuration. To start working with the updated configuration, the user needs to restart the 1C:Enterprise system. To control and notify users about dynamic changes made, use the Database ConfigurationChangedDynamically() global context method.
    NOTE. After the database configuration update is performed, all versions created by dynamic update will be deleted.
    If changes have been detected that require restructuring of the database, then a dialog with a list of such changes is displayed to confirm the update.
    To confirm the saving, click the Accept button, to refuse, click the Cancel button.

    Background database configuration update

    general description
    NOTE. Only available for CORP license
    Updating the database configuration, which is associated with database restructuring, performed for large infobases, can take a long time. During the update, it is impossible to work with the infobase.
    In order to reduce the loss of time for this operation to a minimum, there is a special mode that updates the database configuration in the background. A background database configuration update is characterized by the following
    features:
    ● Available only in the client-server version of the infobase;
    ● Can be executed with the configurator closed.
    ● Most of the background database configuration update is performed without exclusive access to the database (including performing a database restructuring operation).
    ● The following operations are not available during background refresh:
    ● Configuration editing.
    ● Debug application solution.
    ● Performing a database configuration update operation.
    ● Not allowed to use methods SetAggregateMode(), U setUseAggregates(),RebuildUsingAggregates().
    ● Change the content of the chart of accounts or the chart of settlement types if the accounting ledger or settlement register associated with it
    participates in a background update operation. Attempting to change the contents of such charts of accounts or charts of a calculation type generates an error.
    ● The background configuration update can be paused for up to 48 hours. If the "pause" lasts more than 48 hours, the background update will be canceled.
    ● Background update is not supported for configurations in 8.1 compatibility mode
    ● Background database configuration updates are not supported when running on IBM DB2 9.1 DBMS.
    The background configuration update process consists of several steps:
    ● Processing phase:
    ● Runs for a long time.
    ● This phase can be started in any of the following ways:
    ● Interactively, from the configurator;
    ● From the built-in language (using appropriate methods);
    ● Using the mode batch run configurator.

    ● The core data volume is restructured for the following configuration objects:
    ● Handbooks,
    ● Documents,
    ● Document journals,
    Information registers,
    ● Savings registers,
    ● Accounting registers,
    ● Calculation registers,
    ● Sequences,
    ● Charts of accounts,
    ● Business processes,
    ● Tasks.

    ● During the execution of the processing phase, the system captures all changed data for the above objects, similar to data exchange mechanisms.
    ● Update phase:
    ● Runs automatically after the end of the processing phase, with an interval of 1 minute.
    ● During the execution of the phase, users can work with the infobase.
    ● A phase consists of automatically repeating iterations. Each iteration analyzes the changes accumulated since the execution of the previous iteration (or the completion of the processing phase) and performs a restructuring of the accumulated changes.
    ● Iterations are completed at the moment of transition to the next phase.
    ● Change acceptance phase:
    ● Requires exclusive access to the infobase.
    ● During the execution of the phase, users cannot work with the infobase.
    ● The first step of this phase is to update the data accumulated since the last one before the current one.
    phase, iteration of the actualization phase.
    ● The data that is not involved in the processing and update phases is then restructured. These data do not
    a large amount of changes are expected, and their restructuring is carried out quickly.
    ● The next step is to commit all changes made to the database.
    ● This completes the database configuration update.
    If the background update is started in such a way that no database restructuring is required, then the entire update is performed in the commit phase, the transition to which is possible immediately after the start of the background update.
    During a background update, it is possible to stop the server or put the background update process on pause.
    After stopping the server or after abort worker process serving a system background job that performs an update, the creation of the first session will take a little longer than usual. This is due to background refresh recovery. However, the background update process itself is in a suspended state. Background refresh must be resumed to continue. This behavior is implemented to prevent the system from getting into a loop if a background update worker process crashes due to the background update itself.
    After the server is restored, the background database configuration update continues as follows:
    way:
    ● If the work was interrupted in the processing phase, the process continues from the last configuration object that was processed
    has not been completed.
    ● If the work was interrupted in the update phase, the unfinished iteration starts again.
    ADVICE. It is recommended to cancel a running background database configuration update process in cases where the background database configuration update is not scheduled to complete (for example, the process is put on an infinite "pause"). The implementation of this recommendation will positively affect the characteristics of the system, since there will be no registration of changes for the actualization phase.
    When performing a background restructuring operation, some features of the system operation should be taken into account:
    ● If an accounting or accumulation ledger is added to the separator, this ledger is processed during the
    accepting changes.
    ● If the type of the independent separator is changed (see here), then all objects included in this separator are processed during the commit phase.
    ● If you change the type of a dimension that is included in the main selection of an independent information ledger, then that register is processed during the commit phase.

    Database Configuration Background Update Dialog

    To call the background database configuration update operation, select the menu item Configuration - Database Configuration - Background update of the database configuration. Clicking the Start button starts the processing phase. The following text is displayed in the service message window:
    The start of the background database configuration update was successful
    The configuration is not editable. A background update of the database configuration is in progress.
    After starting a background update, the configuration is blocked from being changed. During the execution of any phase, the operation of the background update can be suspended using the Suspend button. To continue performing a background update
    is the Continue button.
    After the end of the processing phase, the update phase begins, during which you can switch the system to the phase of accepting changes using the Finish button or cancel the update using the Cancel button.
    ADVICE. It is recommended to cancel a running background database configuration update process in cases where the background database configuration update is not planned to be completed (for example, the process is set to infinite
    "pause"). The implementation of this recommendation will positively affect the characteristics of the system, since there will be no registration of changes for the actualization phase.
    The Allow dynamic update checkbox is used to determine whether, when you click the Run button, you want to try to perform a dynamic update instead of starting the background database configuration update process. If this checkbox is checked, then immediately after clicking the Run button, a check will be made to see if it is possible to perform a dynamic configuration update. In the case where the configuration allows this possibility, a dynamic update of the database configuration will be performed instead of a background update of the database configuration.
    The Run on server checkbox is used to determine where the start, end, and cancel will be performed. If this checkbox is cleared, then these actions will be performed on the side of the client application, and if checked, then on the side of the 1C:Enterprise server. In addition, if this check box is selected, then you can only update the configuration if you have the UpdateDatabaseConfiguration right, without the Administer right set.

    Saving the database configuration to a file

    To save the database configuration to a file on disk, select Configuration - Database Configuration -
    Save the database configuration to a file. A standard file selection dialog is displayed on the screen. You must select a directory and specify
    the name of the file to which the database configuration will be written.
    The saved database configuration file is required for the compare and merge configurations operation

    Comparison of configuration and database configuration

    If in the process of making changes to the configuration you want to receive a report on the differences from the database configuration, then you should
    select the item Configuration - Database configuration - Compare, merge with the database configuration.
    If necessary, you can restore changed objects.

    Opting Out of Configuration Changes

    To discard changes in the configuration, just select the item Configuration - Database configuration - Revert to database configuration.
    Note. The menu items Save database configuration to file… and Revert to database configuration are available even if the editable configuration is closed. The Revert to DB configuration command is still unavailable when the infobase is connected to the configuration repository.

    
    Top