Perfect Methods for the Database Authentication
Firstly, the 1C license agreement prohibits working with DBMS in this way, as these features are not documented. Starting to use filegroups, you should be aware of the risks of violating this agreement. Minimum consequences are a refusal to provide technical support for solutions on the 1C platform. You would get the best option for 먹튀디비 here.
- You must clearly understand the pros and cons of this step. Everything that you do will be on your conscience!
- Secondly, this is a complication of maintenance, as when updating the database, it is necessary to take into account the fact that some tables are in other file groups or disk media.
Why take this into account?
For example, in your database there is a register of information “Attached files”, which stores binary data of different types of documents. To save space in the main data warehouse, these documents were transferred to a separate file group. The data file for it is on a separate disk.
Everything worked perfectly, we freed up 1 TB of data in the main storage. BUT! One fine day, 1C developers made changes to the system by adding a new resource to the “Attached files” information register. Everything is checked in the test databases, because no one there holds a full copy of the working database. The change was released, but the following problems occurred during deployment:
What a twist
The storage where the main database file is located did not have enough space during the restructuring. Indeed, in the process, the platform creates the table again in the main filegroup of the database, that is, in “PRIMARY”. It turns out that the platform created the table and “distilled” data from the file group “FILEGROUP_3” into it until it filled the disk.
Due to the restructuring that was interrupted with an error, the database (in the “PRIMARY” file group) will remain the table “_InfoRg2133 NG “, into which the platform “poured” the data. To correct the situation and free up space it will need to be removed manually. We will not dwell on the description of the restructuring process, we only note that the platform adds the “NG” postfix to the tables being recreated. So you can find in the database the tables that appeared during the “beaten” database restructuring.
It may not be easy to fix the consequences of a restructuring attempt, because for this you need to perform a shrink of the main data file, and this can be a very lengthy and resource-intensive operation. Yes, in the last paragraph we deleted the table, but the data file from this did not decrease in size. We just freed up space in the data file itself.
As a result, if such a situation occurs and good administrators cannot allocate additional space and disks, then the system may stop working. But this is not exactly and completely dependent on your infrastructure!
But is there a way to get rid of such a problem? Yes there is. Here are some suggestions:
- Check the list of tables for restructuring before each release.
If the changes affected heavy tables for which non-standard file groups were applied, then one of the options:
Discard changes to this table. Use external tables instead. For example, instead of adding the requisite to the directory, you can add it as ext. property or in an additional register of information. Turn on the imagination!
