There is an amazingly simpler yet highly informative post up on TECHNET portal, which proved very handy this morning.
My systems admin reported to me that our SharePoint server ran out of storage for some reason unknown to him, but he could identify that it was SQL Server program files folder which consumed 80% of storage.
I immediately knew what could be the reason. It’s those crazy log files problem. To truncate and clear these overeating log files, I had to use this command: DBCC SHRINKFILE.
Once I cleared out all unnecessary file space from these log files, I had to setup the File Growth and Maximum File Size (shown in the screenshot beside):
Never for a DB log file, we should setup the file growth as “In Percent”. This would prove disastrous over a period of time. Instead, always set it up to “In Megabytes” and enter a least sensible value; in my case I had set it up to 5MB.
For a DB Log file, 2GB should be reasonable amount of file space to hold the logs. To learn more about Log files, read this post on TECHNET: The Transaction Log (SQL Server).
We must understand one thing, that shrinking the DB log has got it’s own impact.
UPDATE: this was drafted long ago, but couldn’t really got to post it till now. You might find this post a bit old, BUT it’s quite relevant even now and extremely informative post.
I came across this gem of an article which lists out 7 things that affect T-SQL performance.
I do not want to take anything out from that article and post it here, as you would realize by reading the original post, you would learn some very important concepts.
Read it here: The Seven Sins Against T-SQL Performance.
Angela Ebensteiner (Technical Lead, Microsoft Dynamics) share a fix on Microsoft Dynamics GP Support blog for the performance issue with Received Not Invoiced report in Purchase Order Processing (POP).
To brief you here on why this performance issue occur, it’s because of huge pile of PO records staying on POP open tables, even after they are closed. When you run the report, it goes through each and every record on POP open table, due to which you got to wait for some time till query processing finishes.
Fix is to remove completed POs from open tables to history, which we have a standard utility available in GP.
Following are some real time SQL Server 2012 Performance Dashboards, taken from a real time SQL Server 2012 environment:
EXPENSIVE QUERIES – CPU
EXPENSIVE QUERIES – DURATION
and much more…
It’s a great set of reports for every SQL Server DBA to understand his/her SQL Server environment.
In March 2012 (precisely 6th March 2012), Microsoft made available SQL Server 2012 Performance Dashboard Reports which can be used to identify whether there is a current bottleneck on the system, and if so, capture additional diagnostic data that may be required to resolve it.
More information on this can be read from the download page: Microsoft SQL Server 2012 Performance Dashboard Reports.
One point worth to be highlighted is that this doesn’t require Reporting Services to be installed.
It’s a very crucial and important tool for any database administrator.
I am currently working on custom SSRS dashboards performance tuning and related exercises. One task among all is to automate the Fiscal Year Start Date and Fiscal Year End Date based on which Fiscal Year we are in.
If the fiscal year is the same as calendar year, we can hard code the values to 1-Jan-[current year] and 31-Dec-[current year]. Since it’s not in my case, I had to dynamically get the dates from somewhere.
The simplest way for me is to query this from GP Fiscal Periods Setup table, which is SY40101.
Following is the query, if anyone would like to know how the dates are retrieved:
SELECT FSTFSCDY Fiscal_Start_Date,
WHERE YEAR1 = CASE WHEN MONTH(GETDATE()) >= [first month of your company fiscal year] THEN YEAR(GETDATE()) ELSE YEAR(GETDATE()) – 1 END
With above, I can now be rest assured that by the time a new fiscal year is started, my dashboards would automatically get refreshed with new start & end dates.
This query would also work if the fiscal year is as good as the calendar year.