I have been using Azure SQL database for the past six month, and it works very well. But today, I cannot connect to it from Microsoft SQL Server Management Studio.
I got this error:
I checked my Azure account, the database is still alive:
Sometimes I get this problem and after 5-10 minutes it is automatically resolved.
I think the problem is at Azure Server.
Any idea to fix this problem for good?
Apologies for the less than optimal experience. The error message does indicate a service issue. Could you please contact me at mihaelab at Microsoft dot com? I would like to understand why your perceived unavailability in 5-10 min long as per our telemetry none of the databases in the server have such long outages.
Thanks,
Mihaela
Related
We have a windows service that provisions Azure SQL databases for our clients. We are using Microsoft.WindowsAzure.Management.Sql API for this. Our service creates the SQL Server instance and deploys the schema using a DACPAC.
When running recently we received the following warning during the DACPAC deployment step:
Warning - Database 'AG61_xxxxx' on server 'xxxxxx.database.windows.net' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '{xxxxxxxx-C7D7-4504-AF25-4C3AC020BE90}'. (73144)
The problem we have is that this database is now left in an inconsistent state:
It isn't listed in the Azure Portal under databases.
The Azure API doesn't return it in list of databases on the server.
Attempting to recreate the same database on the same server, either via code OR via the Azure Portal, returns
Database 'AG61_xxxxx' already exists. Choose a different database name.
However, I can log into SSMS as the admin user and see the database listed. If I try to delete it I receive the following error:
Failed to connect to server. (Microsoft.SqlServer.Smo)
Additional information:
Database 'AG61_xxxxx' on server 'xxxxxxxxxx' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of 'FBE26206-C3B6-4771-B0EF-4BCA9C154F28'. (Microsoft SQL Server, Error: 40613)
According to Microsoft, error 40613 is transiant and should only last a few seconds. We've been unable to do anything with this database for 3 days.
Has anyone else experienced this? I'd like to know if there is something we can do to recover the database on this server such that we don't have to have the client change their connection strings etc.
I'd also like to know if there is anything I could do in future to mitigate this happening again.
We've been using Azure blob storage for storing all of our SQL backups for over 8 months now.
Over the weekend our production server has suddenly stopped being able to reach the Azure Blob Storage Endpoint where the backups are stored too. The SQL Jobs are now failing.
The back up worked as normal on the A.M job and then failed on the same given day on the P.M run and it hasn't worked since.
We've tried using the Azure blob storage viewer for this specific endpoint from our local machines and also another of our development servers and they can all connect without any issue.
It appears that the issue lies with the server itself, but I'm unsure as to where the problem lies.
Ideally, we need to be able to fix the issue without rebooting the server as its our production server.
I'm a developer, and Azure SQL backup mgmt is not my strong point, would appreciate some guidance on this issue.
I am trying to find a solution to three issues I have encountered recently relating to SQL Server 2014. I am not an expert with this stuff by any means, but I've sort of fallen into needing to learn it in my current role. I went from never using SSMS a few months ago to (Trying) to teach myself how to use SSIS and SSRS. I've made a ton of progress, but now I'm stuck actually getting everything automated the way I want it.
The biggest challenge, and root of all my problems, stems from the fact that I am not a local admin on my machine. It was great to finally get IT to install the programs, but they do not want to give me, or anyone not in IT in my company, local admin access. Apart from asking my director to try to convince them to do so, I'm hoping for some solutions that would mean I don't have to call them every day to run these programs.
My integration server is running, I've got my SSIS packages built, but I can't connect to the Integration Server through SSMS, as I am not a local admin on my machine. I've read about going through dcomcnfg settings for REMOTE access issues, but I'm worried that won't help here since I'm trying to do this from the local machine and it still doesn't work. Any ideas as to how I can change the settings so that it runs for non-admin accounts or just make it work?
SSRS: I've built a report, and want to deploy it, but I don't have access to the reporting services configuration manager either. For whatever reason my reporting server is stopped in the server configuration manager. When I click on it, it says to use reporting services config mgr to tweak settings, so a bit stuck. Appears to be the same issue - not a local admin. Again, are there any settings I can change (getting IT to log in as an admin and walking them through what to change is my only choice, essentially).
SQL Server agent appears to be the same issue...
I could probably run my reports now, but it would be so much nicer to use these programs to the full extent. Any help would be appreciated here. I tried to research as much as possible, but most solutions seem to relate to logging on myself as an admin, running things as admin, etc, and I just can't do that.
Thanks!
You do not need to be local admin on your machine, SSIS and SSAS require Windows Authentication to log on remotely to the server via SSMS and publishing anything to the server from BIDS / SSDT Visual Studio Shell also requires WinAuth, though you can work locally and then swap the package to the server via Ctrl-C, and also instead of deploying SSRS you can login directly to the report manager and upload an RDL file (report). To start and stop SQL Agent services you need Windows Authentication via SSMS (in your setup), but to view the SQL Agent you must be in the SQL Server SysAdmin role (or at a grain level SQL Agent Reader via the MSDB rights.
I recommend you attempt to not get local administrator rights and instead ask 'merely' for rights to read and write to the server drives, and to manage only the aspects of SQL Server and it's services with a domain login on the server. You will require this anyway to check ingress and egress file locations and debug production issues (unless you have FTP to the box).
You do not have access to stop or start SQL Agent from your client SSMS also because I believe you are accessing it via SQL Authentication, which is not ideal or secure. But if you do not see the agent on the bottom left of SSMS it is because you do not have rights. If you see the Agent and it is red then the service is disabled and must be started.
You will need to get direct access to the SQL box (and you do not need local admin to manage SQL Server, just a domain account with some service rights and drive rights). If your system administrators are running SQL Server under Local Admin, then they should not be managing SQL Server in the first place (see my write up hyperlinked below).
The SSRS Team at Microsoft has merged into the SharePoint team, and SharePoint 2013 wraps up all of the BI tools right into it, so that is something you should also consider if you plan on building out a BI shop at your firm, i.e. you may not have to if you already have SharePoint installed.
Good luck, don't get discouraged.
What user account would you recommend running the SQL Server Express 2008 services in a development environment?
I am installing Srs Data Connector for MS Dynamics CRM, but on the systems checking were encountering an error "There is no such object on the server". I've tried googling it but to no avail.
UPDATE: Added some details
I'm running on 2 VM one for CRM app and the other for MSSQL
I'm installing the srs data connector to the MSSQL Server
Both Server is running on Windows 2008 r2
SQL Server is MSSQL 2008
Could be the permissions issue. Make sure NTAUTORITY\NETWORK SERVICE have permissions to access MSCRM_CONFIG. You might also need to reset IIS on CRM Machine after sorting out the access issue.
Is this on-prem?
If that's the case you may want to program in SQL as opposed to fetchxml - It's a lot more flexable.
That being said, if you want to continue to use fetchxml - make sure to point the ssrs data connector to your crm server and not the database server.
Just want to share the resolution and the cause of the problem (Well not the detailed cause).
The problem was caused by an issue on the AD configuration and the installation of the CRM and MSSQL.
After 2 weeks of trying to resolve various errors on the CRM installation including the above post the problem seems to be with the AD config.
We have many Domain controllers and changes on each DC were scheduled to be copied on the other controllers each afternoon. That's why some setup done by the CRM were not copied immediately.
We have tried re-installing the CRM and MSSQL but it also failed. The trick is to set up the CRM and MSSQL in the same DC then disable the CRM and MSSQL servers to connect to the other domain controller OR to replicate the configurations in the DC in real time.
After that all errors and warnings will be gone...
Thanks,
I'm working with a fresh installation of Server 2008 R2. I'm new to all things administration, so this could be a simple issue.
I'm installing SQL Server 2008 R2, and I've reached a point where it's asking me to create Service Accounts. I'm really just trying to do bare minimum here to get started with SharePoint.
I'm getting an error "The credentials you provided for the SQL Server Agent service are invalid. To continue, provide a valid account and password."
I get this error for the Analysis Services service as well.
Can someone explain to me what this means and how I can proceed with the installation?
After some searching I saw that the issue might lie in the fact that I was signed in as a local Administrator, so I created another user in Users via Computer Management and the same issue is occurring.
The SQL installation is not asking to create service accounts. It is asking which service accounts it should use to execute SQL Server. If you need to create accounts for this, you will need to do that through the usual user management tools, whether Active Directory or Local Users.
Depending on the purposes of this machine, you may be fine using one of the built in accounts, such as Network Service. Not a best practice, but maybe adequate for a short lived demo/dev machine.
More details on MSDN.