4 deleted 441 characters in body
source | link

To resolve this issue permanently, I simply shrunk the ldf file on the production serversupport at Microsoft has offered two choices.

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.Install SQL Server 2014 SP1 + CU4

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete. or

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have. Install SQL Server 2014 CU7

FIX: You cannot restore a SQL Server 2012 or 2014 database in the Microsoft Azure binary large object storage service

When a SQL Server 2012 or SQL Server 2014 database contains a large transaction log file, you cannot restore the database in the Microsoft Azure binary large objects (BLOB) storage service. For example, if the transaction log file is so large that it takes longer than 3 minutes to restore it, you cannot restore the database.

The alternative was to shrink the ldf(s) thus reducing the number of VLF's to recover during database startup.

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have.

FIX: You cannot restore a SQL Server 2012 or 2014 database in the Microsoft Azure binary large object storage service

When a SQL Server 2012 or SQL Server 2014 database contains a large transaction log file, you cannot restore the database in the Microsoft Azure binary large objects (BLOB) storage service. For example, if the transaction log file is so large that it takes longer than 3 minutes to restore it, you cannot restore the database.

To resolve this issue permanently, the support at Microsoft has offered two choices.

Install SQL Server 2014 SP1 + CU4

or

Install SQL Server 2014 CU7

FIX: You cannot restore a SQL Server 2012 or 2014 database in the Microsoft Azure binary large object storage service

When a SQL Server 2012 or SQL Server 2014 database contains a large transaction log file, you cannot restore the database in the Microsoft Azure binary large objects (BLOB) storage service. For example, if the transaction log file is so large that it takes longer than 3 minutes to restore it, you cannot restore the database.

The alternative was to shrink the ldf(s) thus reducing the number of VLF's to recover during database startup.

3 added 527 characters in body
source | link

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have.

FIX: You cannot restore a SQL Server 2012 or 2014 database in the Microsoft Azure binary large object storage service

When a SQL Server 2012 or SQL Server 2014 database contains a large transaction log file, you cannot restore the database in the Microsoft Azure binary large objects (BLOB) storage service. For example, if the transaction log file is so large that it takes longer than 3 minutes to restore it, you cannot restore the database.

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have.

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have.

FIX: You cannot restore a SQL Server 2012 or 2014 database in the Microsoft Azure binary large object storage service

When a SQL Server 2012 or SQL Server 2014 database contains a large transaction log file, you cannot restore the database in the Microsoft Azure binary large objects (BLOB) storage service. For example, if the transaction log file is so large that it takes longer than 3 minutes to restore it, you cannot restore the database.

2 added 135 characters in body
source | link

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have.

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

To resolve this issue, I simply shrunk the ldf file on the production server

USE [MY_DATABASE]
GO
DBCC SHRINKFILE (N'MY_DATABASE_log' , 1024)
GO

backed up the database and ran the restore on the destination staging server.

The size I shrunk to here is just an example because in reality the production server has several large ldfs. The overall size had to be reduced by a factor of 3 before I could get the restore from URL to complete.

I know that having many ldfs is not recommended but I have no control over the number of ldfs that a production database may have.

1
source | link