I have an older machine, running Windows Server 2003 and SQLServer 2005. It is nearing its end of life, but until all the users have migrated to the new server, we need to keep an SSAS cube on that machine up to date.
The problem is the network connection is sometimes flaky. The cube on this server points to a SQL database on another server, and if the connection experiences a problem while the cube is being rebuilt, the process stops with an error message.
Since 99 out of a 100 times when there is a processing error it is caused by the network, I'm looking for a way to repeat the processing of the cube if it fails. The perfect solution should stop after x tries (just in case this is the 100th time and it's not a network issue).
I've looked at SQL Server Agent Jobs, and SSIS, and don't see a way to loop until it succeeds or reaches the x number of tries. Isn't there a command line option to run the cube processing, so that I can include it in a Powershell loop or something? Or is there an option is SQL or SSIS that I have missed?
We ran into a similar situation with our processes and were able to have the Agent jobs retry 3 times after a 10 minute wait period. Only if all 3 tries failed did our process alert us that "this is a real failure and not a transient issue."
In any SQL Agent job step type, the Advanced tab ought to look like this.
As you can see, you can specify your Retry attempts and an interval in minutes for it to retry.
You could use some sort of loop where you have three objects in your package :
SSAS Processing Task
Script component that increments a counter
Package execution task that calls back the current package if the counter is less than the number of tries for your processing task.
Related
I've got an SSIS job that pulls GL transactions from a Jade database via ODBC. If I have a large date range of transactions, I get a read timeout from Jade. Is there a way to structure an SSIS job so that it would pull a few days at a time in separate reads from the source, so that it avoids this timeout. I'm using a for loop and only asking for a few days at a time but it fails, so I've obviously not avoided the issue.
To be clear we're going to up the timeout on the server from 3 to 10 minutes. We won't use a 0 timeout for obvious reasons but there is always a chance that if we need to pull a large range of data for a new project we'd hit whatever reasonable timeout we set.
I'm looking for a way to structure the job to incrementally pull smaller ranges until it's complete.
I found the timeout setting, it's on the Jade Dataflow Component, not on the ODBC connection object where I thought it would be. I probably put a value in there when I created the package about 18 months ago, and forgot about it.
I'm trying to make some tests to verify a DQS SSIS task execution. When I run the task, a simple OLEDB source, a DQS Transform, and a OLEDB destination, the package freezes at this point. It is supossed to load up to 30000 rows, but the task on OLEDB is marked as completed and keeps running at the DQS Transform box.
I've checked on the client to see if maybe the process is created, but the Quality project isn't created and the DQS task is just frozen. Besides, previously when I made tests, the DQS transform used to take as few as 800 or up to 1000 rows, and now seems to be trying to take almost 10000 rows. I don't believe it's a matter of memory as the machine has 32 GB and it isn't a million records, just around 30000 rows.
I've tried to check logs and verify what might be going on, but I'm really stuck on here for almost two days without any idea on where else check.
Seems to be that the issue came with an update for Microsoft Windows Sever. Reinstalled DQS Server, Uploaded the backup DQS file and it was running back again. Keep backups after every knowledge discovery, these are the only way to restore them after this issue.
I have a asp.net mvc application which is used to validate the data that is in the database using a SQL Server stored procedure. If the data is over a million records, it takes more than 40 minutes to process them and gives the validation results back to the .net mvc application. I have programmed such a way to sustain the .net mvc application browser session for one hour. But after 20 minutes a time out exception is being raised, as there won't be any response from the sql server until it finishes the SP processing. Is there any way to hold the session of sql server response call in .net mvc? or can I send any acknowledgements from sql in the middle of Stored Procedure call process?
Well, you can raise all timeouts that are involved here. Identify what component caused a timeout (ADO.NET or ASP.NET) and adjust the value.
The problem with that is that 40min long HTTP requests are quite unreliable. Any temporary problem such as a small network disruption or a router terminating idle connections can kill the connection. Also, you will sometimes need to restart the server (deployments, reboots, crashes).
This is not a good architecture.
Maybe you can split the work into smaller parts of, say, 10 seconds?
My ssis package is running very slowly. The package is like this, using FTP task we will collect files from server and then loads that data into sql server table. It is scheduled to run every night as a job. When I run it in IDE it is very fast. And when run it on SQL server Aegnt as a job, for some days it fast. But as days progress the package is taking much time to execute. What I have to do for upcoming this issue? Please give me in detail.
Logging implementation makes sense. Than you can find out certain part(-s) of your ETL, which slows down entire package.
As for some variants:
What about other tasks on SQL or FTP servers the same time as
package execution? Looks like other scheduled tasks (backups,
defrags etc.) take server resources from time to time. Is there any
repeated sequence of performance decreasing?
Amount of processed data. Let's say files
represent sales, which have drastically other amount on weekend.
Based on code. For example, manual execution let
server to truncate some temporary tables, but automatic version uses
the same tables w/o truncation, which slows down every next day.
But first of all: logging may help as a start point of fixing.
I'm running PHP commandline scripts as rabbitmq consumers which need to connect to a MySQL database. Those scripts run as Symfony2 commands using Doctrine2 ORM, meaning opening and closing the database connection is handled behind the scenes.
The connection is normally closed automatically when the cli command exits - which is by definition not happening for a long time in a background consumer.
This is a problem when the consumer is idle (no incoming messages) longer then the wait_timeout setting in the MySQL server configuration. If no message is consumed longer than that period, the database server will close the connection and the next message will fail with a MySQL server has gone away exception.
I've thought about 2 solutions for the problem:
Open the connection before each message and close the connection manually after handling the message.
Implementing a ping message which runs a dummy SQL query like SELECT 1 FROM table each n minutes and call it using a cronjob.
The problem with the first approach is: If the traffic on that queue is high, there might be a significant overhead for the consumer in opening/closing connections. The second approach just sounds like an ugly hack to deal with the issue, but at least i can use a single connection during high load times.
Are there any better solutions for handling doctrine connections in background scripts?
Here is another Solution. Try to avoid long running Symfony 2 Workers. They will always cause problems due to their long execution time. The kernel isn't made for that.
The solution here is to build a proxy in front of the real Symfony command. So every message will trigger a fresh Symfony kernel. Sound's like a good solution for me.
http://blog.vandenbrand.org/2015/01/09/symfony2-and-rabbitmq-lessons-learned/
My approach is a little bit different. My workers only process one message, then die. I have supervisor configured to create a new worker every time. So, a worker will:
Ask for a new message.
If there are no messages, sleep for 20 seconds. If not, supervisor will think there's something wrong and stop creating the worker.
If there is a message, process it.
Maybe, if processing a message is super fast, sleep for the same reason than 2.
After processing the message, just finish.
This has worked very well using AWS SQS.
Comments are welcomed.
This is a big problem when running PHP-Scripts for too long. For me, the best solution is to restart the script some times. You can see how to do this in this Topic: How to restart PHP script every 1 hour?
You should also run multiple instances of your consumer. Add a counter to any one and terminate them after some runs. Now you need a tool to ensure a consistent amount of worker processes. Something like this: http://kamisama.me/2012/10/12/background-jobs-with-php-and-resque-part-4-managing-worker/