I have a server with many databases, and I want to create a query to get the shrink details of every database.
For example if I right click on a database, and go to Task-> Shrink the following window is displayed:
The idea is to create a query to get the Allocated Space and the available space (including the percentage)
I have tried this query
SELECT SUM(size/128.0) AS DatabaseDataSpaceAllocatedInMB,
SUM (CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0) AS DatabaseDataSpaceUsedInMB
FROM sys.database_files
and the DatabaseDataSpaceAllocatedInMB shows the expected value.
But the DatabaseDataSpaceUsedInMB I think is not correct, because the operation DatabaseDataSpaceAllocatedInMB - DatabaseDataSpaceUsedInMB is not the same value as Available Free Space.
Any ideas?
Thanks!
Related
I created a linked server connection to our SAP B1 HANA server in my SSMS environment and have been using it for various queries for a while - never had any issues. This week I typed in this simple query into SSMS:
SELECT *
FROM OPENQUERY([LINKEDSERVERCONNECTION], 'SELECT T0."ItemCode", T0."UserText" FROM DATABASE.OITM T0;')
What I got was 99% blank cells with a seemingly random few cells with actual ItemCodes. I can see the corresponding number of rows as we have ItemCodes in our HANA database but where there should be the ItemCodes I see blanks. See following screenshot.
The column UserText IS showing properly though - when I scroll through I can recognize values but the corresponding ItemCode is blank when it should be the correct part number.
Now when I remove T0."UserText" from the query then all the ItemCodes show up fine. See screenshot.
So it seems that adding T0."UserText" to the query causes some strange problem returning data.
While few ItemCodes have something in UserText compared to all the other ItemCodes, those that do have data can sometimes have quite lengthy strings in UserText (sometimes 100+ characters). However, I do not believe there are enough instances of this to cause what I would believe to be a shortage of resources on the HANA server - but then I'm not a HANA systems expert.
If I query ItemCode and UserText in SAP B1's Query Wizard, I can get everything to display correctly. I need it to work in SSMS however.
Does anyone have any idea what could be causing SSMS' troubles displaying the query with UserText?
I have a database which is almost full and we have some options to deal with this:
we can increase the db file size
shrink the database
Before I choose the first option, I want to know how can I check the database size and how much data is really in there so that I may can shrink the database to get some free space.
So see where you have unused space , what file is how big use the following query....
Use DatabaseName
GO
Select name AS [FileName]
, size/128.0 AS [FileSize(MB)]
, fileproperty(name, 'SpaceUsed')/128.0 AS [Space_Used(MB)]
, (size - fileproperty(name, 'SpaceUsed')) /128.0 AS [FreeSpace(MB)]
From dbo.sysfiles
GO
Finally when you have decided to shrink a file with lots of free space you can use DBCC shrinkfile command to do so.
USE DatabaseName
GO
DBCC SHRINKFILE ('FileName', 10) --<-- will shrink it to 10 MB
GO
Note
If any of the unused space was occupied by the BLOB data type(text, ntext, xml etc) column, you may not be able to claim back that unused space unless you drop and recreate the table again.
You can get this information a couple of different ways. In SSMS you can right click on the database, choose properties and look at files. You data and log files will display an "Initial" value indicating size.
You can right click the DB, click on Tasks and Shrink, then Files and the data file should be the default displayed. This will show you your size and free space.
You can also run a script showing you all the size and location info for your databases. There are several out there you can find with a quick Google Search.
Additionally, there are some built in SPs that can get you that info as described here The fourth query in particular shows you the amount of free space.
I'm converting a client's SSIS packages from DTS to SSIS. In one of their packages they have an execute SQL task that has a query similar to this:
SELECT * FROM [SOME_TABLE] AS ReturnValues
ORDER BY IDNumber
FOR XML AUTO, ELEMENTS
This query seems to return in a decent amount of time on the old system but on the new box it takes up to 18 minutes to run the query in SSMS. Sometimes if I run it it will generate an XML link and if I click on it to view the XML its throwing a 'System.OutOfMemoryException' and suggests increasing the number of characters retrieved from the server for XML data. I increased the option to unlimited and still getting error.
The table itself contains 220,500 rows but the query rows returned is showing 129,810 before query stops. Is this simply a matter of not having enough memory available to the system? This box has 48 GB (Win 2008 R2 EE x64), instance capped to 18GB because its shared dev environment. Any help/insight would be greatly appreciated as I don't really know XML!
When you are using SSMS to do XML queries FOR XML, it will generate all the XML and then put it into the grid and allow you to click on it. There are limits to how much data it brings back and with 220,000 rows, depending on how wide the table is, is huge and produces a lot of text.
The out of memory is the fact that SQL Server is trying to parse all of it and that is a lot of memory consumption for SSMS.
You can try to execute to a file and see what you get for size. But the major reason for running out of memory, is because that is a lot of XML and returning it to the grid, you will not get all the results all the time with this type of result set (size wise).
DBADuck (Ben)
The out of memory exception you're hitting is due to the amount of text a .net grid control can handle. 220k lines is huge! the setting in SSMS to show unlimited data is only as good as the .net control memory cap.
You coul look at removing the ELEMENTS option and look at the data in attribute format. That will decreate the amount XML "string space" returned. Personally, I prefer attributes over elements for that reason alone. Context is king, so it depends on what you're trying to accomplish (look at the data or use the data). Could youp pipe the data into an XML variable? When all is said & done, DBADuck is 100% correct in his statement.
SqlNightOwl
I have a huge database (800MB) which consists of a field called 'Date Last Modified' at the moment this field is entered as a text data type but need to change it to a Date/Time field to carry out some queries.
I have another exact same database but with only 35MB of data inside it and when I change the data type it works fine, but when I try to change data type on big database it gives me an error:
Micorosoft Office Access can't change the data type.
There isn't enough disk space or memory
After doing some research some sites mentioned of changing the registry file (MaxLocksPerFile) tried that as well, but no luck :-(
Can anyone help please?
As John W. Vinson says here, the problem you're running into is that Access wants to hold a copy of the table while it makes the changes, and that causes it to exceed the maximum allowable size of an Access file. Compacting and repairing might help get the file under the size limit, but it didn't work for me.
If, like me, you have a lot of complex relationships and reports on the old table that you don't want to have to redo, try this variation on #user292452's solution instead:
Copy the table (i.e. 'YourTable') then paste Structure Only back
into your database with a different name (i.e. 'YourTable_new').
Copy YourTable again, and paste-append the data to YourTable_new.
(To paste-append, first paste, and select Append Data to Existing
Table.)
You may want to make a copy of your Access database at this point,
just in case something goes wrong with the next part.
Delete all data in YourTable using a delete query---select all
fields, using the asterisk, and then run with default settings.
Now you can change the fields in YourTable as needed and save
again.
Paste-append the data from YourTable_new to YourTable, and check
that there were no errors from type conversion, length, etc.
Delete YourTable_new.
One relatively tedious (but straightforward) solution would be to break the big database up into smaller databases, do the conversion on the smaller databases, and then recombine them.
This has an added benefit that if, by some chance, the text is an invalid date in one chunk, it will be easier to find (because of the smaller chunk sizes).
Assuming you have some kind of integer key on the table that ranges from 1 to (say) 10000000, you can just do queries like
SELECT *
INTO newTable1
FROM yourtable
WHERE yourkey >= 0 AND yourkey < 1000000
SELECT *
INTO newTable2
FROM yourtable
WHERE yourkey >= 1000000 AND yourkey < 2000000
etc.
Make sure to enter and run these queries seperately, since it seems that Access will give you a syntax error if you try to run more than one at a time.
If your keys are something else, you can do the same kind of thing, but you'll have to be a bit more tricky about your WHERE clauses.
Of course, a final thing to consider, if you can swing it, is to migrate to a different database that has a little more power. I'm guessing you have reasons that this isn't easy, but with the amount of data you're talking about, you'll probably be running into other problems as well as you continue to use Access.
EDIT
Since you are still having some troubles, here is some more detail in the hopes that you'll see something that I didn't describe well enough before:
Here, you can see that I've created a table "OutputIDrive" similar to what you're describing. I have an ID tag, though I only have three entries.
Here, I've created a query, gone into SQL mode, and entered the appropriate SQL statement. In my case, because my query only grabs value >= 0 and < 2, we'll just get one row...the one with ID = 1.
When I click the run button, I get a popup that tells/warns me what's going to happen...it's going to put a row into a new table. That's good...that's what we're looking for. I click "OK".
Now our new table has been created, and when I click on it, we can see that our one line of data with ID = 1 has been copied over to this new table.
Now you should be able to just modify the table name and the number values in your SQL query, and run it again.
Hopefully this will help you with whatever tripped you up.
EDIT 2:
Aha! This is the trick. You have to enter and run the SQL statements one at a time in Access. If you try to put multiple statements in and run them, you'll get that error. So run the first one, then erase it and run the second one, etc. and you should be fine. I think that will do it! I've edited the above to make it clearer.
Adapted from Karl Donaubauer's answer on an MSDN post:
Switch to immediate window (Ctl + G)
Execute the following statement:
DBEngine.SetOption dbMaxLocksPerFile, 200000
Microsoft has a KnowledgeBase article that addresses this problem directly and describes the cause:
The page locks required for the transaction exceed the MaxLocksPerFile value, which defaults to 9500 locks. The MaxLocksPerFile setting is stored in the Windows registry.
The KnowledgeBase article says it applies to Access 2002 and 2003, but it worked for me when changing a field in an .mdb from Access 2013.
It's entirely possible that in a database of that size, you've got text data that won't convert to a valid Date/Time.
I would suggest (and you may hate me for this) that you export all those prospective date values from "Big" and go through them (perhaps in Excel) to see which ones are not formatted the way you'd expect.
Assuming that the error message is accurate, you're running up against a disk or memory limitation. Assuming that you have more than a couple of gigabytes free on your disk drive, my best guess is that rebuilding the table would put the database (including work space) over the 2 gigabyte per file limit in Access.
If that's the case you'll need to:
Unload the data into some convenient format and load it back in to an empty database with an already existing table definition.
Move a subset of the data into a smaller table, change the data type in the smaller table, compact and repair the database, and repeat until all the data is converted.
If the error message is NOT correct (which is possible), the most likely cause is a bad or out-of-range date in your text-date column.
Copy the table (i.e. 'YourTable') then paste just its structure back into your database with a different name (i.e. 'YourTable_new').
Change the fields in the new table to what you want and save it.
Create an append query and copy all the data from your old table into the new one.
Hopefully Access will automatically convert the old text field directly to the correct value for the new Date/Time field. If not, you might have to clear out the old table and re-append all the data and use a string to date function to convert that one field when you do the append.
Also, if there is an autonumber field in the old table this might not work because there is no way to ensure that the old autonumber values will line up with the new autonumber values that get assigned.
You've been offered a bunch of different ways to get around the disk space error message.
Have you tried adding a new field to your existing table using Date data type and then updating the field with the value the existing string date field? If that works, you can then delete the old field and rename the new one to the old name. That would probably take up less temp space than doing a direct conversion from string to date on a single field.
If it still doesn't work, you may be able to do it with a sceond table with two columns, the first long integer (make it the primary key), the second, date. Then append the PK and string date field to this empty table. Then add a new date field to the existing table, and using a join, update the new field with the values from the two-column table.
This may run into the same problem. It depends on number of things internal to the Jet/ACE database engine over which we have no real control.
I would like to edit data directly from result grid in ssms. eg:
When I execute SELECT TOP 10 * FROM some_table, I want to edit data directly from result grid.
I don't want to open some_table and edit from there.
I know that result grid is read-only, but maybe someone written addin for it.
You can't edit the data from within the result grid. You'd have to go via the "open table" route if you want to edit the data manually instead of using UPDATE/INSERT SQL statements.
Is there a reason you specifically want to use the result grid instead?
You can specify a query when you go via open table to limit the results if that's your reason? There's a "Show SQL Pane" button in the top toolbar you need to select (square box with "SQL" written in it).
I have very large database (70+ GB) with so many tables.
I'm using Red Gate's SQL refactor for intellisense and few other things.
It's so boring to type in update sql statements every time I need to change single field.
It also takes some time to find that table in the Object explorer.
Intellisense doesn't work when I use "Show SQL Pane".
I'm new to SQL Server and have used the Oracle product 'PL/SQL developer' by All Round Automations at a previous job... It would allow you to do a SELECT in the query window and then simply add "FOR UPDATE" to the end of your refined SQL SELECT and 'ta-da' you can now edit the results in a nice grid. No need to Open Table View, click the SQL button, paste in the SQL you you have been working on and then hit execute ;)
EMS SQL Manager for SQL Server allows to update data directly inside a results grid.
This tool is boring for typing new requests (poor intellisense and error management) but fine for this. I always have the two tools opened.
If you right click on the table and choose edit top 200 records, it produces a result screen with an query.
Add to this your query and then you can edit the records in the result screen.
Also you can change the 200 to a number you want (2000).
The "results" pane is not just results.
Results in text
Assorted time and IO statistics
Estimated and actual execution plans
Row counts, Error messages, PRINT output
etc
This is why they are separate.
Feel free to write your own add-in :-) Or here
SQL Server ISN'T Access!
When you run a query and get the results - thats exactly what you are doing, reading the data, not opening the table for editing. Can you imagine the necessary transactional control around allowing the results window to be edited? The locking would probably grind SQL to a halt - I hope no-one ever writes that kind of add-in!