January 14, 2016 at 11:11Adding and configuring 1C database to the server
- Tutorial
Good day, dear.
This note is a hint to me and the rest.
This information is useful for beginners to create and optimize a 1C database on a SQL server.
When you do not have experience working with the 1C server side, then when you want and / or need, there are quite a few nuances and obviousities.
It is sad that even such a simple quest as choosing a server under 1C does not guarantee success, and you may encounter its extremely slow performance.
Here at the stage of finding out what is wrong, and you may need an understanding of in what order and what to do.
Getting started. Do not forget to backup data.
My server is the blade in the “437507-B21 - HP BLc3000 Configure-to-order Enclosure” blade server, which is based on Windows Server 2012 R2 standard, and SQL 2012.
The blade itself is connected to the file storage (SHD) and the network via the HP WS device -CBS3020-HPQ which reads 4 GB SAN Switch.
Storage is based on HP StorageWorks HSV300. Call it EVA. It has 8 segments of 6 disks of 600 GB each (total 48 pcs. Dual Port 15K Fiber Channel spare: 495808-001), connected via Fiber Channel.
The blade itself has a configuration of 2a physical processors with 4 cores on an AMD Quad-Core Opteron (tm) Processor 2354, with 16 GB (667 MHz) RAM installed and 2 SAS 6G DP 10K 300 GB hard drives (spare 507284-001 ) in the mirror.
You may have other inboxes, it doesn't matter (now).
We took a comprehensive supply of USP (it includes 10 client licenses, a server (only 32 bits), and configurations of ZUP, UT, Accounting, and UTP itself. It is noteworthy that franchisees wanted to include separate deliveries in everything, and it is better to use CORP at once. Analysis showed that it’s superfluous, and it’s cheaper to take an integrated configuration.
When choosing hardware, it is important for you to remember that in the client-server version of 1C you need the maximum frequency of the processor, as well as the frequency of the memory (remember this, choosing the hardware). (i.e. Hyper trading and all sorts of C1-2-3 state is better from key in the BIOS.)
It is also necessary to “physically” distribute the database file (MDF) and log (LDF) to separate hard, not logical drives.
And if for the file version it is optimal to recommend SSD, then here, not everything is so obvious.
Go to the Gilev forum to familiarize yourself with the "riddles" that arise in an attempt to improve 1C performance. A lot of interesting.
In my case, fellow administrators gave me a blade on a blade server, with 2 physical processors AMD Quad-Core Opteron (tm) Processor 2354, with 16 GB (667 MHz). System on 2 disks in the mirror. Disks for the base were allocated by Fiber chanel, on HP EVA.
Now I’m looking for a different configuration, but for now I need to live on this.
And so at the implementation stage, while analyzing how to transfer data from another ERP system, 1C programmer drew my attention to the slow work, and the long holding of documents. That is, the system has not yet been exploited, but it is already slowing down and dying, and re-conducting is 3 times slower than a person on a laptop, and people will also have to work with this (3-4 main, and 25-40 timers).
Not an order.
He recommended using the Gilev test (his site is easily google), which has full support services and information. Which I took advantage of.
The test showed that everything is bad, and the recommended number of users is missing.
Having looked more closely, I realized that the base and the log are at least on different disks - but logical.
And to fix this, I took screenshots and this memo for myself and others for the future:
The result of the test. Everything is still bad, but the recommended number of users is more than required, which is good.
I also tested using the logical partition on the mirror of the main disk in the blade and the partition on the EVA storage.
Bottom line:
Sorting an SQL Database into different drives is very important!
In the most minimal version, the Base can be based on the logical drive of the main physical disk with the system, and the log can be moved to a separate drive (in the comments they gave information that it is better on the SSD) The
best option is to distribute the database and the log to separate physical disks.
Just as noted in the comments, it makes sense to take out the TEMP database of SQL itself, since 1C actively uses it during operation.
PS In the process of searching for truth, the system was completely cloned to one separate SSD (that is, the disks with the base and the log were logical).
Despite the i7-4790 with 32 GB DDR3, performance from a regular disk and server work does not get better.
Creating disks on a RAM disk also showed poor results, indistinguishable from working on simple disks.
Also, information to help - Effector Saver allows you to save 1s of the
backup database . Everything else makes little sense, since in my case the licenses are software and when they are transferred to another hardware, the licenses fly off.
From the extra.
If you want to give domain users with impunity to create any database using 1C, then a 1C server service account to create a domain account that has the right to create databases without any system administrators is enough,
and you do not need to write a login and password in the properties of the infobase ...
All the best!
This note is a hint to me and the rest.
This information is useful for beginners to create and optimize a 1C database on a SQL server.
When you do not have experience working with the 1C server side, then when you want and / or need, there are quite a few nuances and obviousities.
It is sad that even such a simple quest as choosing a server under 1C does not guarantee success, and you may encounter its extremely slow performance.
Here at the stage of finding out what is wrong, and you may need an understanding of in what order and what to do.
Getting started. Do not forget to backup data.
My server is the blade in the “437507-B21 - HP BLc3000 Configure-to-order Enclosure” blade server, which is based on Windows Server 2012 R2 standard, and SQL 2012.
The blade itself is connected to the file storage (SHD) and the network via the HP WS device -CBS3020-HPQ which reads 4 GB SAN Switch.
Storage is based on HP StorageWorks HSV300. Call it EVA. It has 8 segments of 6 disks of 600 GB each (total 48 pcs. Dual Port 15K Fiber Channel spare: 495808-001), connected via Fiber Channel.
The blade itself has a configuration of 2a physical processors with 4 cores on an AMD Quad-Core Opteron (tm) Processor 2354, with 16 GB (667 MHz) RAM installed and 2 SAS 6G DP 10K 300 GB hard drives (spare 507284-001 ) in the mirror.
Server rack hardware photos
You may have other inboxes, it doesn't matter (now).
We took a comprehensive supply of USP (it includes 10 client licenses, a server (only 32 bits), and configurations of ZUP, UT, Accounting, and UTP itself. It is noteworthy that franchisees wanted to include separate deliveries in everything, and it is better to use CORP at once. Analysis showed that it’s superfluous, and it’s cheaper to take an integrated configuration.
When choosing hardware, it is important for you to remember that in the client-server version of 1C you need the maximum frequency of the processor, as well as the frequency of the memory (remember this, choosing the hardware). (i.e. Hyper trading and all sorts of C1-2-3 state is better from key in the BIOS.)
It is also necessary to “physically” distribute the database file (MDF) and log (LDF) to separate hard, not logical drives.
And if for the file version it is optimal to recommend SSD, then here, not everything is so obvious.
Go to the Gilev forum to familiarize yourself with the "riddles" that arise in an attempt to improve 1C performance. A lot of interesting.
In my case, fellow administrators gave me a blade on a blade server, with 2 physical processors AMD Quad-Core Opteron (tm) Processor 2354, with 16 GB (667 MHz). System on 2 disks in the mirror. Disks for the base were allocated by Fiber chanel, on HP EVA.
Now I’m looking for a different configuration, but for now I need to live on this.
And so at the implementation stage, while analyzing how to transfer data from another ERP system, 1C programmer drew my attention to the slow work, and the long holding of documents. That is, the system has not yet been exploited, but it is already slowing down and dying, and re-conducting is 3 times slower than a person on a laptop, and people will also have to work with this (3-4 main, and 25-40 timers).
Not an order.
He recommended using the Gilev test (his site is easily google), which has full support services and information. Which I took advantage of.
The test showed that everything is bad, and the recommended number of users is missing.
Having looked more closely, I realized that the base and the log are at least on different disks - but logical.
And to fix this, I took screenshots and this memo for myself and others for the future:
Memo
Creating a database in SQL server management studio. We distribute the base and the log to different physical disks.
We select Simple as the recovery method.
Create a new database through the 1C client on the computer.
Choose to add an infobase. In our case, no configuration.
Set the name. Any here. Better as a server.
Fill in the data. When pointing to the server, the server name indicated 127.0.0.1 - otherwise it did not work.
we don’t change anything here.
We do the loading of our infobase (previously available or new, for example, test).
Actually the choice of the base. I’m downloading the Gilev test for the 8.3 platform. We
confirm. We
confirm.
Keep in mind:
When launching the Gilev test in a test base located in the same storage locations as any battlefield, keep in mind that at least the Log file should strive to take up all the free space, which is fraught with stopping the combat base and not passing the test !!!
Creating a database in SQL server management studio. We distribute the base and the log to different physical disks.
We select Simple as the recovery method.
Create a new database through the 1C client on the computer.
Choose to add an infobase. In our case, no configuration.
Set the name. Any here. Better as a server.
Fill in the data. When pointing to the server, the server name indicated 127.0.0.1 - otherwise it did not work.
we don’t change anything here.
We do the loading of our infobase (previously available or new, for example, test).
Actually the choice of the base. I’m downloading the Gilev test for the 8.3 platform. We
confirm. We
confirm.
Keep in mind:
When launching the Gilev test in a test base located in the same storage locations as any battlefield, keep in mind that at least the Log file should strive to take up all the free space, which is fraught with stopping the combat base and not passing the test !!!
The result of the test. Everything is still bad, but the recommended number of users is more than required, which is good.
I also tested using the logical partition on the mirror of the main disk in the blade and the partition on the EVA storage.
Test results
Here is the Log on the logical drive in the mirror on SAS 10K, and the base on the EVA storage with SAS disks 15K
And here Base on the logical drive in the mirror on the SAS 10K, and the log on EVA storage with SAS disks 15K
Here is the Log on the logical drive in the mirror on SAS 10K, and the base on the EVA storage with SAS disks 15K
And here Base on the logical drive in the mirror on the SAS 10K, and the log on EVA storage with SAS disks 15K
Bottom line:
Sorting an SQL Database into different drives is very important!
In the most minimal version, the Base can be based on the logical drive of the main physical disk with the system, and the log can be moved to a separate drive (in the comments they gave information that it is better on the SSD) The
best option is to distribute the database and the log to separate physical disks.
Just as noted in the comments, it makes sense to take out the TEMP database of SQL itself, since 1C actively uses it during operation.
PS In the process of searching for truth, the system was completely cloned to one separate SSD (that is, the disks with the base and the log were logical).
Despite the i7-4790 with 32 GB DDR3, performance from a regular disk and server work does not get better.
Creating disks on a RAM disk also showed poor results, indistinguishable from working on simple disks.
Also, information to help - Effector Saver allows you to save 1s of the
backup database . Everything else makes little sense, since in my case the licenses are software and when they are transferred to another hardware, the licenses fly off.
From the extra.
If you want to give domain users with impunity to create any database using 1C, then a 1C server service account to create a domain account that has the right to create databases without any system administrators is enough,
and you do not need to write a login and password in the properties of the infobase ...
All the best!