Our SQL Server has over 8000 databases.
To expand the database-node in my SSMS (2012 and 2014, both) takes around 2 minutes, sometimes longer (when there is a lot of traffic).
Is there any way to reduce this time?
I read somewhere, don't know where, that the problem is, that for every database the SSMS asks if you have rights to see them, open them, expand them (or something like this).
You would need to revoke the permission 'VIEW ANY DATABASE' from the role PUBLIC (SQL SERVER 2005 onwards) and give permission to the users only for the databases they need. This should make Object Explorer faster.
I had a similar issue with Sql Server 2014. It took me about 1 minute to expand the databases tree with only 10-15 databases listed.
The solution to me was to run the Sql Server 2014 setup and repair the installation. Even though nothing seems to be incorrectly installed this still fixed the issue for expanding the databases tree.
Rene,
Have you tried using the latest preview version of SSMS (available here)? I believe the issue might have also been addressed in the SSMS 2014 Service Pack 1 release (you can find that here)
Related
I have an issue setting up merge replication on a SQL 2012 instance.
The push of the snapshot to the subscriber is failing and the reason I discovered was because there is a SP that uses a Full Text Index that has not been generated on a table.
A lot of searching about revealed that there is a property that is false by default that defines if a full text index should be copied.
I thought I had found the solution, set this property to true and triggered a new snapshot, however, the same issue was still encountered and when I went back to check the property the copy full text index property was set to false again??
I have tried a few times in the hope it was just me forgetting to save or something, from what I can see, the property stays at true until the snapshot is rerun, after that the property is back at false again, I am wondering if I have come up against a bug in SQL server, however, a google does not appear to indicate this is true.
I have tried deleting and recreating the publication. I have also tried disabling the distributor and publisher in order to force a fresh distribution DB to be created, thinking that maybe there is a corruption somewhere.
Both servers are running SQL Server 2012 on Windows Server 2012R2
Does anyone have any fresh ideas?
I had similar problems with full text catalogs/search setup when using old SQL Server 2012 SSMS version. IDE has many full-text setup related issues(bugs were reported to MS). And only way to achieve proper functionality was to use t-sql commands only. After SSMS became separate from SQL Server product, these IDE bugs were fixed. No problems when working with full-text and SSMS IDE anymore. My SSMS version is 17.8.1, server version 2012 - 11.0.5343.0 (X64)(Build 7601: Service Pack 1).
Maybe your problems is related with IDE bugs too? Try to upgrade SSMS version (if you have older), ant then check situation again.
Update:
Here is related topic with full-text & merge replication problem. Hope this helps:
link1
OK, so I eventually ran out of ideas and logged a call with Microsoft. Turns out that this is a bug and it effects all SQL server versions from SQL 2012 right through to SQL server 2017 from what I am being told.
Microsoft have said they are working on a patch for this but in the meantime I am having to manually script Full Text resources until something comes through.
Hope this helps anyone that comes across this issue.
I am trying to backup my entire SQL Server database, so I can restore it in case I mess something up (about to revamp my entire Umbraco site). However, according to Microsoft's guide (and others' as well), there should be a task called Back Up. However, there is not.
That is for SSMS 17 (version 14). SSMS 2016 (version 13) shows the exact same thing.
To backup a SQL Azure database you need to select the "Export Data-tier Application..." option.
This will create a .bacpac file which you can then restore to either another SQL Azure database or an on-premises SQL Server.
See the Microsoft Documentation here for more details.
In Azure SQL DB, backups occur automatically. If you want to export a database, you can export to a BACPAC (make sure active transactions are not occurring during the export). See https://learn.microsoft.com/en-us/azure/sql-database/sql-database-automated-backups and https://learn.microsoft.com/en-us/azure/sql-database/sql-database-export.
For me the problem was the database name, of all things. I know it sounds weird, but while researching this issue I discovered a bug in SSMS that causes the context menu to change (including not having backup/restore options) based simply on the database name.
I'm using 18.4, but the bug likely exists in earlier versions as well.
I've reported the bug here, but I'll summarize the steps to reproduce the issue here for convenience:
In SSMS, Right-click the Databases node, choose New Database...
Name it 1.2.3.4, click OK
Right-click on the newly-created database. There is no option to Back up (or restore)
Click on the name (so that you can rename it)
Rename the 1.2.3.4 database 1234 (remove the periods)
Perform step 3 again - this time you'll see the expected Back up... and Restore options.
It appears that the context menu for SSMS is incorrectly assuming the database type because of some pattern in the name involving periods. As for the specific pattern, I don't know. I do know that periods in general aren't a problem, but names like 1.2.3.4 are problematic. Test_1.2.3.4 is fine. I'll leave it someone actually debugging the problem to figure it out.
Hopefully this will help someone else that comes along looking for answers.
I am trying to use Copy Database Wizard to copy from my live server (shared hosting) to my local machine. Both the live and local servers are SQL 2008 R2.
I have used CDW for several years with perfect success when copying from a live SQL 2000 server to my local 2008 R2. But now that I have migrated my live database to SQL 2008 R2 the CDW is giving me this error:
Could not read metadata, possibly due to insufficient access rights.
I've learned that this error can be predicted before you even complete the CDW setup: On the page where the CDW asks you for your desired destination database name, it is SUPPOSED to populate the .mdf and .ldf files with their name-to-be and size (e.g. MB, GB).
But in my case these file names and sizes are not being shown (area is simply blank in the wizard) and then of course when I attempt to execute the package it gives me the error.
After much research I believe that reason for this error is due to the CDW requirement of "You must be a member of the sysadmin fixed server role on both the source and destination servers."
On my local server, my Windows Authentication login is listed as a Role Member for the sysadmin Server Role. However on my live server (keep in mind it is a shared SQL server with 250+ databases) the only Role Member listed is [sa].
Am I right in thinking that the only way to satisfy this requirement would be to add my specific SQL user to the live/source Server > Security > Server Roles > sysadmin role? I'm guessing that would never be done on a shared server right? Or is there some other way to make it work by messing with the specific database properties/users/roles?
I can't explain why CDW is working from the live SQL 2000 server and not the 2008 R2. I HOPE it is simply that something isn't set up right on the live database, but maybe it is due to changes that were made to SQL security over the years.
In case it matters, I must use the SMO method instead of detach/attach because it is a live database that I don't want to take down. Historically the CDW from SQL 2000 only takes 3 minutes with SMO method so speed isn't an issue anyway.
Here's my preference for a solution:
Find a way to get CDW to work, most likely by changing something on the live server. Is this possible? What would it be?
If that fails, then...
What about an idea of using CDW to create the package, but then going into to BIDS and manipulating something in the package to circumvent the sysadmin role requirement. (Does it really need the metadata? I don't need anything beside the actual data tables.) Is this possible?
UPDATE 6/14/2016: Editing a CDW package in BIDS won't work as it appears to simply use the .mdf and .ldf files, which of course I don't have access to on the shared server. I think an alternative is to use Import/Export Wizard to create a package, then edit in BIDS. The annoying part is that without access to metadata the Import/Export Wizard doesn't seem to be aware of Foreign Keys, and thus doesn't know what order to process the tables in.
If that fails, then...
Is there any other way to easily automate a daily copy from my live server to local machine? The reason I like CDW is because it is super simple to use (when it works), it can be scheduled to run daily as a SQL agent job, and requires no manual work on my part. Is there a "next best thing" if CDW can't be made to work?
You'd think that a very common scenario for all websites out there would be "how do I get a copy of my live database onto my local SQL server, daily, automatically"? But maybe I'm the weird one!
Another simple solution would be the Import/Export Wizard.
In SSMS right-click the database you want transferred and select 'Tasks' and then 'Export Data...'. It will open a wizard that is very similar to that of CDW. The difference here is that I could not find a sysadmin requirement to use it.
At the end it will give the option to run immediately and/or save the SSIS package. If you save the SSIS package (I prefer to save it to disk) you can then create a schedule via a SQL Agent job.
I want to migrate a database completely or partially. Right now, I will do a complete database. Partial will be posted as a separate question.
Strategies I am considering:
copy database wizard
convert 2005 database to script. Run script on 2008
simple SQL query
My question - I want to use method 2. Is it even possible to do this? If yes, how to do it? Any limitations/risks ?
NOTE - The source server is a SQL Server 2005 database with one IP. Destination is a SQL Server 2008 instance with another IP.
I don't know if you need to be sysadmin to do this. I am not even sure if I am sysadmin. If yes, then how to check if I am a sysadmin ?
Just RESTORE it on the SQL2008 server and it will be automatically upgraded. And you can check if you're a sysadmin using IS_SRVROLEMEMBER.
My question - I want to use method (2). Is it even possible to do this ? (...) any limitations/risks ?
Option 2 could be a problem if database is too large. Worked for me with up to 2 GB databases.
any limitations/risks ?
You may need to increase SQL's buffer and/or run the script through command line, since a large script in SQL Manager eats up plenty of memory.
If yes, how to do it ?
To generate the script, simply right click and choose generate script. Select both data and model for whole database, and choose appropriate options for others.
As Pondlife said, Just backup the database at SQL 2005, restore as a new database at SQL 2008. You change the compatible mode to SQL 2005 which is version 9, or you can leave it to 2008 which is version 10 or 10.5. I think you want to keep the database as is, so you could set the compatible more to 9.0.xxxx and you all be done.
As usual grant access to users, create them as new if you have to, or migrate them from SQL 2005.
Generating script from 2005 and running on 2008 is a long route. There may be some possibilities for errors and TSQL compatibility.
Hope it helps !!
Most simple way to do this is to restore backup or copy MDF and LDF files to new server. If your servers are in the same network you can do this by creating shared folders on the second server and copying files there.
If that is not an option for any reason then you can zip the backup (make sure to add strong password) upload it to some online storage and then download it from second server.
Final option is to use third party comparison and synchronization tools from RedGage or ApexSQL (there are a lot of these on the market and they all have fully functional trials)
I have to move an entire database from a SQL Server 2008 machine to a SQL Server 2000 machine.
I created a backup using Management Studio 2008, copied it to the hard drive of the 2000 box, and from withing Management Studio 2008, I choose Restore Database to the 2000 box.
I get an error message stating, "The media family on device ... is incorrectly formed. SQL Server cannot restore this media family".
If I use Enterprise Manager 2000 I get the same error.
Is there a way to move a whole database from the newer SQL server to the older?
The only thing I can think of is to recreate the whole structure and then copy data from a live database. So, create scripts that will create the tables, views, and sp's, and then create scripts to copy the data from the existing database.
As others already said there is no default way to do this. It’s just not supported. Here are more extensive details on how to do this properly and avoid any migration issues.
You need to generate scripts for structure and data and then execute these on SQL 2000 (like others already said) but there are couple things to take into account.
Generate scripts in SSMS
Make sure to check option for scripting data for SQL 2000 to avoid issues when trying to create something like geography type column on SQL 2000.
Make sure to review execution order of scripts to avoid dependency based errors
This is a great option for small to medium size databases and requires some knowledge of SQL Server (dependencies, differences between versions and such)
Third party tools
Idea is to use third party database comparison tools such as ApexSQL Diff or Data Diff
Good side is that these will take care of script execution and differences between versions
Not so good is the fact that you’ll need to pay for these after trial ends
I’ve used these two tools successfully but you can’t go wrong with any other tool on the market. Here is a list of other tools in this category.
you can't move backups from a newer version to an older, in that case you can script your database, execute it in the 2000 box, then you can use the standard data transfer to transfer any data you want
Provided you have a network connection between the machines use SSIS. Much easier and a lot less messing around.
You can use Script Generator for your database and then select in the properties form : General-> Script for server version : SQL Server 2000.
The script generator will show you things which not compatible with your server version.
I've heard you can only do it by generating the SQL statement dump from the DB administrator tool and re-running those queries on the target older database.
You can generate a script that will recreate all the objects and transfer all the data...as long as everything in the db is valid in SQL 2000. So no ROW_NUMBER(), no PARTITION, no CTEs, no datetime2, hierarchy or several other field types, no EXECUTE AS, and lots of other goodness. Basically, there's a pretty good chance it's not possible unless your db is pretty basic.
We got a similar situation. A very low-tech but handy solution is:
backup and truncate the tables in SQL 2000.
create a LINKED server in SQL 2008, pointing to SQL 2000
run a select query at sysobjects to generate a query script for insert into LINKED SERVER.table select * from table
execute query script.