Would I run into any issue if I tried dropping a foreign key constraint on a live SQL database? I want to make sure there's no reason to take the database offline before doing this.
Dropping a foreign key on the live databases can be done online without impacting your users. You may run into data quality issues though, I guess the foreign key was in place for a reason.
Related
Many months ago we were running our website (ASP.NET C#) locally on premise and decided to migrate our website and database into azure (WebApp and Azure SQL). Everything was migrated successfully and we encountered minimal issues.
Now we just spotted that it seems that during our import of our SQL database into Azure SQL it disabled all constraints including PK constraints and unique constraints, etc.
I was wondering if anyone has encountered this before and what can be done to fix the issue?
The idea that I'm working with right now, and not sure if it would work, is to export the database from Azure SQL using SqlPackage.exe and VerifyExtraction=false and hopefully, that would work because otherwise the export doesn’t work because it’s trying to verify the schema, then import it to my local SQL server, try to run EXEC sp_msforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all" (I believe sp_msforeachtable is not available in Azure SQL). And if that works and the constraints are re-enabled properly, then try importing it back into Azure SQL again, assuming it won’t try to disable them again.
Any help or ideas are appreciated!
"Everything was migrated successfully and we encountered minimal issues."
I doubt that's actually true. It sounds like the import has failed to add primary keys and constraints during database restore, which is actually a pretty big deal.
If your database is small (think less than 10 million rows total across all tables) you could code a script to add primary keys and clustered indexes in-situ by using the ALTER TABLE statement.
If your database is any bigger than that, you'll need to either re-import it from scratch, paying attention to any error logs this time, or build new tables, select all your data into them, drop the existing tables and rename your new tables to what the old tables were named.
I guess it all depends on how many tables you have and how many rows they have as to which approach will be best for you.
SSMS has some great tools and shortcuts to do this sort of stuff. Right click table, click "Script as", click "create to", click "new query window" and voila, you have a create table statement ready to go. Add your constraints to it, rename it to [Tablename]2, run it, and voila! You've just created a new table with a Primary Key constraint. Select everything out of the existing table into your new table, delete the old table, rename your new table back to what the old table was named and bam, you're done.
If you need to do this 20 times, no big deal. If you need to do this 2000 times, you can script these operations into one long query.
I have two databases that I have connected using linked servers.I have DB1 and DB2 which I only have read access to. I'm using DB1 for my application and have linked DB2 so I can combine queries. Is it possible to have foreign keys in DB1 that are linked to DB2?
No, it is not possible to create foreign keys between objects in different databases (even if they are on the same server). The official documentation is pretty clear about that:
FOREIGN KEY constraints can reference only tables within the same database on the same server. Cross-database referential integrity must be implemented through triggers. For more information, see CREATE TRIGGER (Transact-SQL).
It even points you to the possible workaround, i.e. to try to implement some kind of referential integrity checks using triggers. You can add after insert/update triggers on both sides to validate the data changes, and after delete triggers on the primary table to check are there child records. If the validation fails, you will raise an error. You can also use instead of triggers.
But the solution with triggers will not guarantee the referential integrity anyway. You can lose connectivity between databases. You can restore one of the databases from older backup. All kind of things can go wrong. You better try to reconsider your database design. Is it possible to combine these two databases into one? Is it possible to maintain copies of both tables into each of the databases and try to replicate stuff?
Why does Azure web app performance suffer so much when trying to delete a record that violates a foreign key constraint? I know, "Don't do that." It just caught me by surprise that it could be such a huge factor.
I have an Azure website running about 125K requests/hour and it connects to Azure SQL S2 database with about 8GB throughput/day most of which is during normal business hours. In the Azure portal charts, the website is normally about 40% CPU and 50% memory during the day. The database averages about 15% CPU and 30 - 40% Data I/O and Log I/O.
I tried to delete a record using Mgt Studio that violated a foreign key constraint. The website suffered greatly - the number of requests being handled dropped very low, CPU peaked, http queue length went very high, Autoscale added another instance, many http server errors started occurring and many clients were reporting timeouts and 502 bad gateway errors.
It took me a couple minutes to recognize the issue and cancel the query, canceling the query took another three minutes and it took 10-15 minutes for the web app to catch up.
My questions are, is this a normal response to a foreign key violation? Do I have something structured wrong, either in the database or in the web service code that causes such an extended, disastrous effect from the foreign key violation error in Mgt. Studio? Would upgrading to Azure Sql V12 eliminate this kind of issue?
It was most likely a database performance issue.
The record I tried to delete is referenced by multiple foreign key constraints, most are delete cascade but one is not.
Most of the cascade delete references are for small numbers of records but one referenced 135,000 records in a table with a total of 600,000 records.
Another cascade delete may have referenced a small number of records in a table with few records but which may have a 10-15MB size blob in each them. I don't know how much, if any, were referenced by the record I tried to delete.
I'm guessing it was performing the cascade deletes until it encountered the one table that didn't cascade delete and had to roll everything back. In other words, the extended issues with the website were most likely because the database performance was suffering. This aspect of Azure is disappointing. When we were providing these services locally on a Windows Server 2003 virtual machine with Sql Server 2005 with several times more data, the database was much more responsive. Perhaps an upgrade to Azure Sql V12 will help somewhat.
I'v created a ER model in data modeler and one of the entity is automatically setting a primary key even though I dont want a primary key to that particular entity.. here is a screenshot As you can see on logical model there is no staff_type_id
but the relational model has staff_type_id
why is this happening? its creating a problem while i implement the database. Please help :(
I think there's no problem in that, if you notice you are linking the two tables with a relation of 1:N and you can't link entities that don't have primary key. it's the best to create a primary key for every linked entity. How you can link between entities without foreign key and primary key?!
generally, it's recommended to give every linked entity primary key.
I don't understand how this is a problem! can you explain more?
I want to disable all Foreign key constraints and re-enable them after, is there some way to do that?
I know that SQLServer allows that, but what about Firebird?
AFAICT foreign keys can't be disabled in Firebird up to 2.1.
You'd have to drop and recreate them.
There's a similar thread on Devshed.
I guess the only way is to drop and later re-create them. Since constraints are not data, you really do not lose any information from the database, so it is a harmless operation (provided that you keep the script to recreate them later).
Version of FlameRobin in SVN repository has an option to generate those DROP and CREATE scripts automatically for chosen table column dependencies. Last official release has the same option for entire tables, so that might help you. There is no option to do it for the whole database, though. Maybe some other admin. tool has that feature.