In an SQL database where all data input is keystroked by no more than six people simulatneously, does it make sense that the DB would grow by 1.6GB in the space of three hours?
It’s possible. The database grows every time you add or delete something. So if you were to add, delete, and add something, that would be three entries, not one. But you can clean it up by doing a compact/compress/whatever your program calls it.
The data kept in a database is always more than someone keys in, often by quite a bit. It may be keeping date/time stamps and other information about each transaction. If there’s an audit trail of some sort, lots of data overhead can go to tracking who did what and how the old data looked.
That does seem to have grown awfully quickly… but I don’t think anyone can say more than “It’s possible” without knowing more.
What type of database is it? Unusual database size issues are fairly common even on enterprise level systems. Databases sometimes allocate space for themselves and then leave most of it empty which takes up a lot of disk space for just a little data. Transaction logs and backups for the database can also make the size spiral out of control. All modern database platforms have tools for dealing with this. The procedures you need to look for are called something like truncating logs, compacting, or shrinking the database files.
Some databases also allocate space in chunks. For example, the one I work on lets you specify an initial and an autogrowth setting. Suppose my initial setting is (say) 500 meg and the autogrowth is also 500 meg. Initially it will be 500 meg but when enough data is entered to push it over that the disk space will suddenly jump to 1000 meg. If you check properties you will see that the database has just over 50% utilization with 499 meg free but the entire 1000 meg is still allocated on disk.
1.6G seems a bit excessive for that amount of data input and timeframe. Is this a new database? What was the initial size?
BUT it depends on the application and what it’s doing behind the scenes. Are you sure that there wasn’t any sort of bulk data input? Is there a lot of auditing/logging set? Some of the audit settings can create a LOT of data.
Assuming you’re talking MS SQL, check the database properties and see what your autogrowth settings are. It’s possible that you hit an auto-grow point and it’s set to auto-grow by some ridiculous amount.
In the database properties, also compare the Size of the database with the Space Available. That will tell you if the growth is caused by actual data or just by the db taking up some extra space.
DO NOT start mucking around with log truncation unless you know what you’re doing. You can screw things up that way.
DO NOT shrink the database until you figure out the problem. For one thing, it won’t help - even if the db shrinks, it will just turn around and grow again as soon as it hits the same condition. And it causes file and index fragmentation, which will hurt your performance.
ETA: dammit, beat again! I just type too slow.
Possible depending on the database, but I’d bet there is a problem.
Based on 400 characters per minute, 6 people in will create 432,000 characters in 3 hours. I’m making an assumption by what “data input is keystroked” really means, but I don’t see this amount of data growing beyond 2 Megabytes, even liberally including extra space for table indexes, and data page fill space percentage.
I also considered the possibility that the space was taken up by the log file, but even a fully logged and clumsily-coded app shouldn’t be creating that much log space for data entry.
Unless your database is set to autogrow at 1.5 GB increments, the amount of data describes should not take up that space. The application tier must be creating more information than you are aware of.
In addition to the other points mentioned, if your database is set up for “high availability” data may be duplicated.
Been doing any joins lately?
Oooh, good point. Are you sure it’s your database that’s increased in size? If you’re doing some mongo queries in MSSQL, it could be your tempdb.