CONNECTION: FILE SIZE OVER LIMIT

1. Identify users complaining about errors in the application’s files. Else, run an overview of the files status in your server by a manual check or get help from a diagnostic tool.
2. If you don’t know where the application error files are located, you can start searching in Windows’s Event Viewer. Navigate to “Windows Logs” and choose the log you are interested in. It might be difficult to track since you should be aware of the correct event ID and time and choose the correct log from many. 
3. Otherwise you can use Powershell commands in order to find logs. However you should know the right script to be run.
4. If you know where the application’s error logs are located, try to search close to the complaint time if there are logs that might explain this issue. It might take time to find them, so you must be accurate about the right time and event details. 
5. Check if while errors are happening then in parallel the application files get bigger or have new files created, try searching for it via the files’ details or in activity logs.
6. In some cases, the errors might be related to SQL exceptions, and those might create many logs and consume the file’s volume. Search for it by profiling tools. Read more here https://www.aimbetter.com/sql-exceptions/
7. Implement file size limits and regularly monitor the size of critical application files. If you don’t have a monitoring tool, you will probably need to do it manually. 

Aimbetter provides alerts and detailed information about file oversize in a single pane. There is no need for further tracking and investigation.

1. Run an overview of the files’ status in your server by manual check or get help from a diagnostic tool. Check if the disk’s used volume got bigger, and if so, recognize its source. It might be hard to do without knowing your business properties properly.
2. If the source is an application, you should try to identify the source by:
   • Checking application logs
   • Talking to users of this application if there is a reason that files got bigger and if there might be a higher volume in work than the usual workflow
   • Checking if the higher accumulation rate is due to temporary files. Some applications generate temporary files during their operation, and these may not always be cleaned up efficiently
   • Checking If the issue is related to queries, you should check for it manually using profiling tools. It might be difficult since you will have only new data, and no historical data available. Therefore, identifying it depends on whether this issue will be repeated and when. You will have to be assisted by a DBA who knows how to utilize the results correctly.
3. If you have recognized that this is a backup program issue:
   • Track the backup process. You can search for it in the event viewer (if the accurate backup time is known) or in the logs of Database application services where the backup is done, looking for incomplete backups or timeouts. If recognized, check for missing steps in the backup process that are related to files getting overgrown. For example, if old backup files are not deleted, it will probably cause files to get bigger.
   • Check older backup files and compare whether the backup files grew for the last attempts. These checks might take time and require knowledge of the current backup and data components.
4. Once you recognize the right cause for the higher data accumulation rate, follow up to see if there is a change for the better when solutions are implemented.

Aimbetter provides all the details about the issue – you will be alerted about the right path where the file size has grown and can easily search for error logs and queries.

1. Check if updates were done recently to one of your business applications. Review it in the application’s version and release date or search for it in the Windows Event Viewer. It might be hard to track when not knowing how, where or when the update has happened, if so. You can start by checking for the last reboot date since many applications require it when it’s updated.
2. Try to understand the content of the last updates by searching for new files created or within the application logs, both might indicate new data inserted.
3. Ask application users whether they have noticed recent changes in the application’s performance or design or if they received a message about updates.

There is no need to think about recent updates when all data is provided in Aimbetter. Keep track of changes and update both with an alert or with a view providing all this data. Easily find error logs that might indicate updates and their content as well.

1. You should regularly monitor the database’s size, checking whether it has grown or not. For that, you can implement a script written by a DBA. You should also track disk usage using the Performance Monitor. Otherwise, track the database’s file volume over time.
2. Identify and analyze queries that are frequently executed and contribute to data or log growth. You can use SQL Server profiler for SQL Server or Oracle Enterprise Manager for Oracle. Oracle and SQL Server also provide system views that offer insights into query performance. Take into account that you should track this issue over time, and still, you don’t have history data to compare with.
3. Examine execution plans for inefficient queries. Track queries with major updates and data inserts into the overgrown databases.
4. Identify irregular I/O patterns to identify bulk operations or large queries with many joins operations, if exists.
5. Think about which appropriate improvement would optimize the queries. For example, You can use the Database Engine Tuning Advisor or other tools to help identify the missing indexes.
6. Track this issue over time and check if the database files have grown slower or less.

Aimbetter provides alerts about the exact issues and suggests improvements if needed. You will not be confused when using AimBetter.