You’re offline. This is a read only version of the page.
1,000
We have very big trouble regarding Database Size, the database size increasing very fast even unexpectedly. In last three working days, the database size was grow up to 2 GB.
We have all default module of Dynamics GP including third-party module such as Manufacturing, Human Resource and Fixed Assets etc with 20 concurrent users.
It’s true we having very hedge inventory Transaction on daily basis, the most of items are also sterilized.
But still growing DB size is not understandable; I am sharing table size information for ease to understand.
|
Table Name |
Table Size (KB) | Index Size (KB) | Table Size (MB) | Index Size (MB) | Table Size (GB) | Index Size (GB) |
| SEE30303 | 3638304.000 | 2899320.000 | 3553.031 | 2831.367 | 3.470 | 2.765 |
| AAG20001 | 76944.000 | 4784.000 | 75.141 | 4.672 | 0.073 | 0.005 |
| IV30400 | 57160.000 | 82360.000 | 55.820 | 80.430 | 0.055 | 0.079 |
| PJOURNAL | 49064.000 | 26896.000 | 47.914 | 26.266 | 0.047 | 0.026 |
| IV00102 | 47432.000 | 20768.000 | 46.320 | 20.281 | 0.045 | 0.020 |
| GL20000 | 38584.000 | 25408.000 | 37.680 | 24.813 | 0.037 | 0.024 |
| IV00200 | 35584.000 | 33880.000 | 34.750 | 33.086 | 0.034 | 0.032 |
| SOP10201 | 31632.000 | 47440.000 | 30.891 | 46.328 | 0.030 | 0.045 |
| AAG20002 | 25016.000 | 168.000 | 24.430 | 0.164 | 0.024 | 0.000 |
| IV10201 | 23976.000 | 42472.000 | 23.414 | 41.477 | 0.023 | 0.041 |
Now, I want to stop database size growing, I have some solutions but I will share with all of you during discussion but now I need some suggestion by your side.
Thanks
Rashid Farooq.
*This post is locked for comments
Any final comment / suggestion on this issue will be highly appreciated.
Setting up the maintenance plan is more flexible than you would think. Obviously, a main driving factor is the availability of the server for such tasks. That is why these are scheduled when users are off, such as late in the evening or in the weekends. Usually I would set up a recurring backup every weeknight because I need the full Monday to Friday set. For the housekeeping tasks (your list should be ok), I often find that they don't need to be run daily, I usually set them to occur at the beginning of the weekend. But some setups can be fine on a once a month basis. Ultimately, you have to strike a balance between controlling database growth and server availability. Start with a weekly schedule, monitor database growth, and adjust accordingly when necessary.
Rashid, I think it is more a question of whether they need the report.
As far as I know the SEE30303 table is only used in HITB and nowhere else so it's basically on or off.
You can use the documentation to find out more about HITB and how it can be disabled:
here: https://mbs.microsoft.com/customersource/downloads/servicepacks/mdgp10_hitb.htm?printpage=false
or here: https://mbs.microsoft.com/partnersource/downloads/releases/mdgp10_hitb.htm?printpage=false
Check the section on the white paper about "Enabling HITB functionality". Maybe you can reverse the process. I personally haven't done this yet so you may want to try this on a test environment.
Exactly I m also focusing on HITB Module which could be the cause of this issue, this module was installed from first day of implementation, the product information is following.
Version Information
Microsoft Dynamics GP Professional: 10.00.1061
Dexterity: 10.0.313.0
Smart List: 10.00.1061
Database: SQL Server
ODBC Driver Manager: 03.80.000
ODBC Driver: 06.01.7100
Human Resource: 10.00.1071
Manufacturing
Runtime Version : 10.0.313.0
Manufacturing for Microsoft Dynamics GP Version: 10.0.1061 SP2
If I remove this module manually what would be disadvantages of it?
Now that we've established that your log size is normal, and that abnormal growth is localized to SEE30303, it seems less likely a DBMS issue but more a fault in the HITB module. When did you start using the HITB module? When did you upgrade to SP2? What SP are you on right now? So the table growth has been constant since you started using HITB?
The backup is scheduled on daily basis. The table SEE30303 having data in following form.
Dear Mariano
Thanks for detail reply and providing such great information, this problem is actually occurred on one of our client and now I am having objective to resolve it.
Initially, they installed GP on default setting and did not make any configuration, but now question is that, how should I resolve this issue? I am not waiting for Ruel and Dencio ;).
In addition to this, let’s agree on your points that, database size increase just because of poor database maintenance or configuration but what should I do for table SEE30303 which hold huge amount of data?
I create a maintenance plan as following, is it OK? What is recommended schedule for this maintenance plan?1. Reorganize Index Task
2. Update Statistics Task
3. Shrink Database Task
4. Check Database Integrity TaskFinally, I need suggestions and recommendation to stop this growing and making consistent database.
Your transaction log size seems to be within normal range. When was the last time a backup was performed? I'm also intrigued by the size of SEE30303. Did you check to see how many records are in there now? Also, was there any other table that got bloated? Can you check an older backup of say, a month ago and do a comparison of table sizes? I would also go with Ron's suggestion to try to recall if there was any major change in the recent past.
Dear Richard
The recovery method is "Full", the size info is following.
DYNAMICS.MDF : 180 MB
DYNAMICS.LDF : 40
COMPANY.MDB: 11.6 GB
COMPANY.LDF: 890 MB
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,253
Super User 2024 Season 2
#2
Martin Dráb
230,188
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (