Space Allocation

RobinC
Member Posts: 2
Hi All,
Can anybody shed any light in this……
We performed a complete Navision Backup, built an empty database and ran a Navision Restore.
The following 2 tables then looked like this....
Table
G/L Entry
No Of Recs 2,432,752
Record Size 590
Size 1,400,784
Optimization 97.1
Table
Cust Ledger
No Of Recs 2,214,314
Record Size 2,144
Size 4,635,608
Optimization 97.3
We then ran 4 main DD and Sales HP posting runs. (Our own routines).
This added a total of 59,234 records to G/L and 59,126 to Cust Ledger.
Tables then looked like this....
Table
G/L Entry
No Of Recs 2,491,986
Record Size 596
Size 1,450,296
Optimization 95.9
Table
Cust Ledger
No Of Recs 2,273,440
Record Size 2,714
Size 6,024,688
Optimization 76.9
G/L has increased by a respectable 49mb, Cust ledger by an astonishing 1,380mb.
Even allowing for the fact that Cust Ledger record size is five times larger this does not in any way explain why the increase in Cust Ledger table size is so dramatic.
After the first DD run G/L went up by just under 11mb, Cust Ledger 1,232mb. Subsequent runs saw G/L increase by a similar amount with Cust Ledger incrementing by 31, 14 and 15mb.
After first Sales HP run G/L went up by just under 2mb and Cust Ledger 84mb. Subsequent runs saw G/L increase by a similar amount with Cust Ledger incrementing by 5, 4 and 4mb.
Both have ‘Entry Number’ as primary key, so what design ‘feature’ is causing this to happen? It has to be down to the design as the decrease in optimisation percentage is huge (20.4%).
As we all know, during the first run, it is adding huge amounts of space after each record is inserted.
How is it calculating how much space to allocate?
As there is so much space, why on subsequent runs does the table size increase at all?
Thanks in Advance
Robin
Can anybody shed any light in this……
We performed a complete Navision Backup, built an empty database and ran a Navision Restore.
The following 2 tables then looked like this....
Table
G/L Entry
No Of Recs 2,432,752
Record Size 590
Size 1,400,784
Optimization 97.1
Table
Cust Ledger
No Of Recs 2,214,314
Record Size 2,144
Size 4,635,608
Optimization 97.3
We then ran 4 main DD and Sales HP posting runs. (Our own routines).
This added a total of 59,234 records to G/L and 59,126 to Cust Ledger.
Tables then looked like this....
Table
G/L Entry
No Of Recs 2,491,986
Record Size 596
Size 1,450,296
Optimization 95.9
Table
Cust Ledger
No Of Recs 2,273,440
Record Size 2,714
Size 6,024,688
Optimization 76.9
G/L has increased by a respectable 49mb, Cust ledger by an astonishing 1,380mb.
Even allowing for the fact that Cust Ledger record size is five times larger this does not in any way explain why the increase in Cust Ledger table size is so dramatic.
After the first DD run G/L went up by just under 11mb, Cust Ledger 1,232mb. Subsequent runs saw G/L increase by a similar amount with Cust Ledger incrementing by 31, 14 and 15mb.
After first Sales HP run G/L went up by just under 2mb and Cust Ledger 84mb. Subsequent runs saw G/L increase by a similar amount with Cust Ledger incrementing by 5, 4 and 4mb.
Both have ‘Entry Number’ as primary key, so what design ‘feature’ is causing this to happen? It has to be down to the design as the decrease in optimisation percentage is huge (20.4%).
As we all know, during the first run, it is adding huge amounts of space after each record is inserted.
How is it calculating how much space to allocate?
As there is so much space, why on subsequent runs does the table size increase at all?
Thanks in Advance
Robin
0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions