I have a Release Management 2013 release that is stuck on a deployment step. I believe I know what happened, I just don't know how to get it moving forward.
There are multiple release templates that use the Servers with Agents to run PowerShell scripts. The situation came up that one of the releases, call it release Alpha, seemed to be stuck and I couldn't determine why, so I re-started the Microsoft Deployment Agent. The reason Alpha was stuck is that the Agent was actively working on a deployment step for a different release template, call it Beta. When I restarted the Agent, it picked up the first deployment step for Alpha and finished successfully. However, Beta never finished and is sitting in the In Progress status.
I would like to know if there is anyway for me to push the deployment step for Beta into any other status so that the whole process continues. I am under the gun here for timing, so I would appreciate any suggestions.
EDIT
After about 6 hours of waiting the release Beta finally failed. In the mean time I also attempted to restart the Release Management Monitor service. This resulted in disabling my Release Management Client app with a "License Expired" message. That message finally went away after I rebooted the server where the Release Managagement Monitor service was running.
I know you're over the initial problem, but for future (which is likely with the thick RM client) there's a table in the database which contains the current step status. Steps "In progress" will return with the following query (status = 2 is in progress):
FROM [ReleaseManagement].[dbo].[ReleaseV2ActivityLog]
where status = '2'
If you cannot wait for an unspecified duration for the timeout and also don't want the server restarted for fear of impact, you can change this status column to the value '3' which will mark the step as 'succeeded' and should move you on:
update [ReleaseManagement].[dbo].[ReleaseV2ActivityLog]
set Status = '3'
where Status = '2'
Obviously amend the query to target the correct "in progress" step by specifying the workflowID or something similarly unique.
Related
PROBLEM!!
After setting up my Logical Replication and everything is running smoothly, i wanted to just dig into the logs just to confirm there was no error there. But when i tail -f postgresql.log, i found the following error keeps reoccurring ERROR: could not start WAL streaming: ERROR: replication slot "sub" is active for PID 124898
SOLUTION!!
This is the simple solution...i went into my postgresql.conf file and searched for wal_sender_timeout on the master and wal_receiver_timeout on the slave. The values i saw there 120s for both and i had to change both to 300s which is equivalent to 5mins. Then remember to reload both servers as you dont require a restart. Then wait for about 5 to 10 mins and the error is fixed.
We had an identical error message in our logs and tried this fix and unfortunately our case was much more diabolical. Putting the notes here just for the next poor soul but in our case, the publishing instance was an AWS managed RDS server and it managed (ha ha) to create such a WAL backlog that it was going into catchup state, processing the WAL and running out of memory (getting killed by the OS every time) before it caught up. The experience on the client side was exactly what you see here - timeouts and failed WAL streaming. The fix was kind of nasty - we had to drop the whole replication link and rebuild it (fortunately it was a test database so not harm done but it's a situation you want to avoid). It was obvious after looking on the publisher side and seeing the logs but from the subscription side more mysterious.
Background:
SQL Compliance Manager is collecting files on an Agent Server to audit and once the trace files collect on the Agent the Compliance Manager agent service account moves these files to the Collection Server folder, processes them and deletes them.
Problem:
Over 5 times in the last month, the trace files have started filling up the Agent drive to the point where the trace files have to be stopped by running a SQL query to change the status of the traces. This has also had a knock on effect with the Collection Server and the folder on there starts to fill up excessively and the Collection Server Agent is unable to process the audit trace files. 4/5 times the issue occurred closely after a SQL fail over, however, the last time this trace error occurred there had been no fail over. The only thing that was noticeable in the event logs was that 3 SQL jobs went off around the time the traces started acting up.
Behaviour:
A pattern has been identified which shows on Windows Event Viewer that there is an execution timeout close or at the time the trace files start becoming unwieldy.
Error: An error occurred starting traces for instance XXXXXXXXX. Error: Execution Timeout Expired.
The timeout period elapsed prior to completion of the operation or the server is not responding..
The trace start timeout value can be modified on the Trace Options tab of the Agent Properties dialog in the SQLcompliance Management Console.
Although, I do not believe by just adjusting the Timeout settings will cause for the traces to stop acting in that way, as these are recommended settings and other audited servers have these same settings but do not act in the same way. The issue only persists with one box.
Questions:
I want to find out if anyone else has experienced a similar issue and if so, was the environment the issue happened in dealing with a heavy load? By reducing the load did it help or were there other remediation steps to take? Or does anyone know of a database auditing tool which is lightweight and doesn't create these issues?!
Any help or advice appreciated!
About 11 hours ago I've started a SQL database creation operation on Azure and it is still being processed. Since my other databases almost took seconds to be installed, it is obvious that there is a technical problem with this one.
AFAIK there is no option for a user to cancel the current process and start a new one. I have also tried to create another but the system throws the following error:
Unable to edit or replace deployment 'Microsoft.SQL.NewDatabase':
previous deployment from '11/24/2015 9:01:59 PM' is still active
(expiration time is '12/1/2015 9:01:59 PM').
Since I haven't purchased any support package I also cannot request it from the Azure team.
I have an SSIS package, that worked just fine for months. It was planned in an SQL Agent Job, and launched every day, as the 8 step of the 23-steps job.
Then all out of nowhere (understand, with absolutely no changes), the said package/step, started returning a failure. But where it start becoming kind of weird, is that :
Launching the package in stand alone (from Visual Studuo or Execute Package Utility) is running as smooth as it can be.
Starting the SSA job from step 8, also return success.
Starting the SSA job from step 1, return a failure at step 8.
Thanks in advance for any idea you might have.
I solved (temporarily) the problem by editing the #retry_attempts propriety of the jobstep in SQL Server Agent. I've set it to 1 so it will repeat one time if there is a failure.
So after the test, there is still a failure on the first execution of the package, but the repeat works fine, which allow the job to continue "journey" without interrupting.
PS: It's definitely not a good, or even a satisfactory solution, mainly because I still don't know what the cause is. If you have any trails I can follow, please do not hesitate.
Tomcat 6.0 is getting stoped after certain time automatically.. My machine is never turned off. but still this process is stopped . I am using My tomcat server in production mode.. and I really don't feel good starting my server daily.
What could be the reason because in Production mode server should never get stopped.
Check in your task scheduler;
Go To start->type in search task schduler
go to task scheduler. Check whether any task is running to stop the serverr.
or you can increase permgen space.
Server might be stop because of out of memory exception.