Share and update! Save space, time and server resources 1C
Last time we told how our infrastructure and the principles of working with 1C databases, of which we have countless half a thousand, have changed, and about how we automate work with so much data. However, there are still difficulties and crutches, and as the number of clients grows, we have to invent new buttons and improve old ways of optimization. One of the main problems when working with a large number of databases 1C - rolling updates. Today we will talk about data separation technology, which allows you to reduce the number of bases and simplify their maintenance.
Finding documentation on the database separation mechanism is quite difficult: there is a small article on the underlying site , but it has brought us little benefit. There is a good old Google , but in order to understand the intricacies, you will have to surf the issue for hours in search of the necessary piece of information. We had no other choice, and you now have this article. We hope it is useful.
When working with 1C, there is a lot to be updated: configuration, KLADR, lists of banks (they are deprived of licenses, you know), exchange rates (oh, these economically unstable euros and dollars), lists of users, processing, version of the platform. On a good hardware update KLADR with all regions for one base takes about half an hour. Configuration update takes from 10 minutes to several hours (when rolling in a pack).
')
When the base is one, two, ten, all this can be done in the form of daily routine work. When a few dozen - it takes a very long time, but you can cope. When there are hundreds of bases, and theSiberian summer is the last day of reporting in the yard, it may happen that it is physically impossible to update all the databases - there is not enough time and server resources.
Do not forget that in each separate database lives her majesty Configuration, which does not differ from the base to the base or byte. He lives and eats a place, despite the fact that the configuration also needs to load changes, insert processing and extend the standard functionality.
So, if you have a few (except for organizations) that do not differ in bases, with the same configuration, the separation mechanism can make life much easier (not without tar, but more on that later). Otherwise, very soon you will have to hire an army of admins :)
To begin with, you need to determine the sign on which you will divide the base. The separator can be of any data type, we use a string 10 characters long: organization TIN. The main thing is that the name of the separator (common prop) should not coincide with already existing configuration objects, that is, it cannot be called, for example, “Organization”, since there is already such a reference book. We called the separator "Group of Companies".
After that, we take your typical configuration with an empty database, go to the configurator and open the section “General Details”. Add a common attribute and change the value of "Splitting data" to "Split":
The configurator will offer to create session parameters - silently agree and move on. After the creation of the “General Props” with the separation property enabled, the database becomes similar to a multi-storey building. The house has elements accessible to everyone and from each floor: an elevator, a flight of stairs, communications, and there issomething unique, accessible only within the floor: apartments, a corridor, windows. The metaphor is simple, and hopefully understandable :)
To enter a certain organization (or area of ​​the database), you must provide a separator in the connection string to the database or specify it in the v8i file (which we described last time ).
After / Z indicate the general details in order. Since in our typical accounting already have two common system properties, we specify for them the value -0 so that they are not used, and as the third (which we created) we transfer the TIN.
Now you need to determine how much of the data will be common to all areas. All this is configured through the configurator. In the properties of the general props, which we have just created, there is a “Composition” item that opens a small list of 800 parameters:
The selection of parameters is left to your prudence, discretion and environment. Here is our option (neater, there are 20,000 pixels).
The separator also allows you to set up a separate list of users for each database - this can be useful if you have hundreds of users - when entering a certain database you don’t have to scroll through this list to bloody blisters. We do not use it because we have configured transparent authorization.
To upload data from current databases, we use a universalXML-exchange . You can’t just take and unload the base, you need to set up the exchange rules, otherwise, during the download, errors (and conflicts) may arise (and there will be any), and the second base will simply not get through. Recall that we divide the base areas for each organization and in our case such exchange rules work. If you decide to use another separator, you will have to poke around with brains and checkboxes. The main thing is not to use the standard unloading - this will lead to the duplication of all predefined records.
Run 1C with the / Z parameter "-0, -0, +% your separator%", indicating the separator of the organization whose data we are going to load. We launch the universal exchange and feed the files we received during the upload: first reference books, then documents. Repeat this operation for eachbase-area .
To simplify the task, we perform bulk uploads, pre-running a slightly fixed standard processing via the command line (/ Execute c: \ upload.epf). Then manually load the resulting files into a split database.
The separation process is not a quick thing. Recall that we now have more than 500 organizations, but in a couple of weeks we managed to divide only 70. However, we know for sure that in six months we will thank our past for the work done and a lot of time and effort saved.
Accountants Buttons do not notice the transition of organizations from a normal base to a divided one; for them, the process is painless. Booty burns only admins :)
Side effects: saving space 1 to 20, an indirect increase in the speed of work - invaluable. In absolute figures: 50 organizations occupy 2 GB of space in SQL, while one separate database takes up 800 MB.
The first three spoons are not so bitter - they just make us more attentive. But we still do not know what to do with the fourth, but we are diligently investigating.
Finding documentation on the database separation mechanism is quite difficult: there is a small article on the underlying site , but it has brought us little benefit. There is a good old Google , but in order to understand the intricacies, you will have to surf the issue for hours in search of the necessary piece of information. We had no other choice, and you now have this article. We hope it is useful.
Enough tolerating this!
When working with 1C, there is a lot to be updated: configuration, KLADR, lists of banks (they are deprived of licenses, you know), exchange rates (oh, these economically unstable euros and dollars), lists of users, processing, version of the platform. On a good hardware update KLADR with all regions for one base takes about half an hour. Configuration update takes from 10 minutes to several hours (when rolling in a pack).
')
When the base is one, two, ten, all this can be done in the form of daily routine work. When a few dozen - it takes a very long time, but you can cope. When there are hundreds of bases, and the
Do not forget that in each separate database lives her majesty Configuration, which does not differ from the base to the base or byte. He lives and eats a place, despite the fact that the configuration also needs to load changes, insert processing and extend the standard functionality.
So, if you have a few (except for organizations) that do not differ in bases, with the same configuration, the separation mechanism can make life much easier (not without tar, but more on that later). Otherwise, very soon you will have to hire an army of admins :)
Base segregation
To begin with, you need to determine the sign on which you will divide the base. The separator can be of any data type, we use a string 10 characters long: organization TIN. The main thing is that the name of the separator (common prop) should not coincide with already existing configuration objects, that is, it cannot be called, for example, “Organization”, since there is already such a reference book. We called the separator "Group of Companies".
After that, we take your typical configuration with an empty database, go to the configurator and open the section “General Details”. Add a common attribute and change the value of "Splitting data" to "Split":
The configurator will offer to create session parameters - silently agree and move on. After the creation of the “General Props” with the separation property enabled, the database becomes similar to a multi-storey building. The house has elements accessible to everyone and from each floor: an elevator, a flight of stairs, communications, and there is
To enter a certain organization (or area of ​​the database), you must provide a separator in the connection string to the database or specify it in the v8i file (which we described last time ).
[ 7710967300 ] Connect=Srvr="%servername%";Ref="%base_name%"; AdditionalParameters=/Z "-0,-0,+7710967300"; After / Z indicate the general details in order. Since in our typical accounting already have two common system properties, we specify for them the value -0 so that they are not used, and as the third (which we created) we transfer the TIN.
1000 and 1 checkbox
Now you need to determine how much of the data will be common to all areas. All this is configured through the configurator. In the properties of the general props, which we have just created, there is a “Composition” item that opens a small list of 800 parameters:
The selection of parameters is left to your prudence, discretion and environment. Here is our option (neater, there are 20,000 pixels).
The separator also allows you to set up a separate list of users for each database - this can be useful if you have hundreds of users - when entering a certain database you don’t have to scroll through this list to bloody blisters. We do not use it because we have configured transparent authorization.
Unload data from current databases
To upload data from current databases, we use a universal
Housekeeping note: it is better to unload reference books and documents separately - this way you can avoid unnecessary mistakes at the time of loading.
We load data into the divided base
Run 1C with the / Z parameter "-0, -0, +% your separator%", indicating the separator of the organization whose data we are going to load. We launch the universal exchange and feed the files we received during the upload: first reference books, then documents. Repeat this operation for each
To simplify the task, we perform bulk uploads, pre-running a slightly fixed standard processing via the command line (/ Execute c: \ upload.epf). Then manually load the resulting files into a split database.
How to spend more time to spend less time
The separation process is not a quick thing. Recall that we now have more than 500 organizations, but in a couple of weeks we managed to divide only 70. However, we know for sure that in six months we will thank our past for the work done and a lot of time and effort saved.
Accountants Buttons do not notice the transition of organizations from a normal base to a divided one; for them, the process is painless. Booty burns only admins :)
Side effects: saving space 1 to 20, an indirect increase in the speed of work - invaluable. In absolute figures: 50 organizations occupy 2 GB of space in SQL, while one separate database takes up 800 MB.
The promised spoon of tar, even four:
- if
one of the users has ruined the data in one organization, you have to roll back the entire divided database - you can not just take and roll one data area - you have to test updates more carefully, especially those that add or change directories
- if you need to transfer the base to the client (or merge the tax :), you have to do the reverse procedure: unload the organization from the split base using universal exchange, then load it into an empty regular base and save from it into.
dt file - in a divided database, it is impossible to manage the scheduled tasks (for example, it will not be possible to automatically update currency rates)
The first three spoons are not so bitter - they just make us more attentive. But we still do not know what to do with the fourth, but we are diligently investigating.
Source: https://habr.com/ru/post/239697/
All Articles