origin
Recently, the company plans to replace the c3p0 database connection pool in the previous project with druid. Before giving a replacement plan, it is necessary to give test data to prove that the performance of druid is better than that of c3p0, so I wrote a demo for comparative testing.
At the beginning, it is necessary to make sure that there is no problem with the configuration, at least to be able to operate the data, and then run the test method. Due to the delay of other things when running, it ran for 10 minutes, and then inserted 860,000 pieces of data into the sybase database.
Before the formal test, I planned to clear the original data in the table, and then encountered the situation that the database was stuck, using delete and drop.
When solving this stuck problem, I found the original problem, and the summary is as follows.
problem analysis
To carry out the comparison test of the two connection pool components, it is necessary to ensure that the preconditions of the database are the same, at least similar. I initially thought about clearing the data, and the operation of clearing the data is delete, but there are two problems with this idea
Question one
The delete operation deletes the data and does not clear the previously occupied space. If it does, then the preconditions of the test are actually different.
Solution
Therefore, in the scenario I tested this time, the operation of clearing data should be used truncate. This operation will not only clear the data, but also clear the space occupied by the data and the space occupied by the corresponding index.
Only in this way can better ensure that the database conditions are closer before the connection pool component is tested, so that the impact of the external environment can be reduced to a smaller extent.
Question two
However, even if the data of the data table is cleared, the space of the data table and the space occupied by the index are also cleared, there is still a problem, that is the problem of the database log.
Sybase will write logs during the insert operation, so if the log keeps increasing, it will inevitably reduce the performance of log writing, which will also reduce the performance of data storage operations as a whole, so you should also clear the data before each test. At the same time, the log is also cleared.
Then the problem of the log is also the main reason why the deletion of 860,000 data makes Sybase stuck.
Sybase will also write a log during the delete operation, and the size of this log has a default value and will not be automatically released.
Because I have performed a lot of operations on the database before, and the logs have not been cleared for several months, the log space is insufficient after inserting more than 800,000 data this time, and then Sybase freezes when I delete it.
Solution
For the problem of insufficient log space, there are two solutions, one is to expand the capacity, and the other is to clear the log. I chose the second one this time, so I will only record the second one.
First, you need to determine whether the log space is really insufficient. The query command is as follows:
sp_spaceused syslogs
If it is determined that the log space is indeed insufficient, then you can use the following command to clear the history log:
dump transaction dbname with truncate_only
The operation of clearing the log is not unique. The above command to clear the log is relatively safe, and some things will be checked, so the performance is not as good as the operation below, and the performance of the following operation will be faster, but relatively speaking, it is not so safe. , which is equivalent to forced deletion.
dump transaction dbname with no_log