I have a stored procedure which deployed on different clients.
This stored procedure is working fine all the time.
Sometimes while using the web application, the
page which calls this stored procedure keeps loading and will return a time out exception FOR ALL USERS.
To fix this issue, right click on stored procedure, modify, then F5 to execute same procedure (with no change on procedure),
Back to web part and refresh, everything will work fine.
It seems that the not very optimal plan is stored to the cache. When you re-create procedure (F5), you clear the cache. When this situation happens again, try to get execution plan and check what params are stored in the cache. Additionally you can add WITH RECOMPILE option, that would probably slow down performance a bit, but you will not have such situations
Related
I have a daily schedule ADF pipeline that consist of couple of activities. The first activity basically invokes a stored procedure that takes less than 2 second to run on DB side but the activity is running continuously(In Progress state for longer period of time). Initially I thought it was due to the blocking on SQL server side. But the problem is there is NO SQL SERVER hit from ADF side. The strange thing is running on Dev environment but getting blocked in QA.
Here is the RunId for the same:
Thanks!
Sometimes you can invoke a stored procedure with a copy activity, changing the SqlReaderQuery property to something like "exec 'sp_name'". I explained this here: Execute storedProcedure from azure datafactory
Your problem looks like the integration runtime cannot reach the database, try opening the integration runtime, and connecting to the database from the diagnostic tab. Once you make it work there, make sure the linked service is configured with those credentials.
Hope this helped!
I have a problem after upgrading from grails 2.3.11 to version 3.2.9.
We have changed what was needed and almost everything works great. But we still have only one problem.
Some action in app have this pattern:
On click in UI there is ajax request which which updates/inserts data into DB.
After success there is callback with another ajax which retrieves updated/new data.
Sometimes (very rarely), second ajax gets old data(of course after another request, data is updated). Database did not have enough time to save the data ? ;)
In grails 2 this never happened.
We use postgres 8.4, but after update to 9.6, problem still occurs. Changing jdbc driver didn't help too.
To reproduce this, I have created a simple app. I added some records to the DB and created 2 actions. One action adds a domain and returns a new id, the second gets data after the insert (there is only one assert which checks if a domain with the right id was created in the DB).
When I have postgres DB on a local, fast machine, the problem occurred very, very rarely, but on the local network, a slow machine causes the problem to appear more frequently.
The problem did not occurr with the default H2 database.
https://github.com/kuchar90/grails3.2Test
Is this normal behavior? Do you have an idea where to look for the reason for this issue?
I am creating an application with sqlite. I am performing all kind of task on the database Insert, Update, Delete, Select.
For that I open the database every time, Then execute my query using sqlite3_step() and after the result I use sqlite3_finalize() and sqlite3_close() methods. It is working well in most cases. I am not getting when its happening but some times my database gets locked with the same process I follow and some time it works.
I need to unlock database so even in any case my database get locked then I can unlock it or Plz guide me if I can check by code that my database is locked so I can replace my database with the resource database.
I am using webservice too so I don't have issue about data loss.
Is it make sense if I replace my database if it get locked or if there is any way to unlock the database.
Open database once in the beginning. And close it in the end in AppWillterminate function. You are only consuming time by opening and closing it in every database function.
As far as database lock is concerned, it gets locked when some application is still using it and other application is trying to get its access.
This could be your app, or possibly the sqlite manager add-on of your firefox.
I faced same problem once and what i did was
Disabled the option in sqlite add-on where it remembers the previously opened database.
Restart xcode, simulator.
Make a copy of the sqlite file (desktop), delete it from the project and then add in project again from desktop.
The last solution sounds weird, but i was mad that time.
I hope this could help you.
I have an app with a very large Core Data database. I have versioned it many times over the past year.
The last time I versioned the database I made one simple change to an entity: I added a new optional attribute. For some reason it would not migrate using Light-weight Migration. I found out much later that this was due to a bug in Apple's Light-weight Migration code resulting from the 'renaming identifiers' that I had needed back in another versioning.
Anyway, I digress...
Because of the bug that kept me from using Light-weight migration, I created a mapping file to help with the migration, not understanding that this would was a much heavier process and would force my users to wait while the app loaded the entire database into memory while doing the migration. It turns out that this is not really an option at all with very large databases and many of my users were unable to migrate the database at all due to memory problems, etc.
So now I want to re-release my app and clear up this problem. The trouble is, some of my users have a database that is somehow marked as being 'in the middle of migrating'. Even with my new code, which gets rid of the mapping file and supports Light-weight migration, users that are in this state, 'in the middle of a migration', don't seem to get reset.
What are my options for backing out a migration?
- I can detect that I am in this state because there is a '.myDB.sqlite.migrationdestination_41b5a6b5c6e848c462a8480cd24caef3' file in the Documents directory. Deleting this file does not clear up the migration. My guess is that the database is somehow flagged as being in this state, or is already partially migrated.
- I can detect this state and then delete the database altogether. But this forces my users to re-download their data.
Any Thoughts?
Thanks for you help.
The only thing that occurs to me would be crack open the SQL store of an affected file and look for flags or something else that might signal the db being in a transitory state. You might be able to write directly to the file and alter something.
That's really ugly problem.
i know this is an often asked question on these boards. And usually the question has been about how to manage the changes being made to the database before you even get around to deploy them.Mostly the answer has been to script the database and save it under sourcecontrol and then any additional updates are saved as scripts under version control too.(ex. Tool to upgrade SQL Express database after deployment)
my question is when is it best to apply the database updates , in the installer or when the new version first runs and connects to the database? note this is a WinApp that is deployed to customers each have their own databases.
One thing to add to the script: Back up the database (or at least the tables you're changing!) before applying the changes.
As a user I think I'd prefer it happens during the install, and going a little further that the installer can roll itself back in the event of a failure. My thinking here is that if I am installing an update, I'd like to know when the update is done that it actually is done and has succeeded. I don't want a message coming up the next time I run it informing me that something failed and I've potentially lost all my data. I would assume that a system admin would probably also appreciate install time feedback (of course, that doesn't matter if your web app isn't something that will be installed on a network). Also, as ראובן said, backing up the database would be a nice convenience.
You haven't said much about the architecture of the application, but since an installer is involved I assume it's a client/server application.
If you have a server installer, that's where you want to put it, since the database structure is only going to change once. Since the client installers are going to need to know about the change, it would be nice to have a way to detect the database version change, and for the old client to be able to download the client update from the server automatically and apply it.
If you only have a client installer, I still think it's better to put it there (maybe as a custom action that fires off the executable for updating the database). But it really isn't going to matter, because conceptually one installer or first-time user of the new version is going to have to fire off the changes to the database anyway. The database changes are going to put structural locks on the database so, in practical terms, everyone is going to have to be kicked off the system at that time for the database update to be applied.
Of course, this is all BS if it's not client-server.