New answers tagged

3

Referring to MS documentation here. Also Creating a 60GB Index on SQLFool. What I believe is happening is that when the index is being built with SORT_IN_TEMDB=OFF, the entire index build processed is logged via the DB's transaction log (DB is set to full recovery). (In addition, I expect there to be a high number of page splits due to the scattergun-nature ...


1

So what you want is an insert, an update and a delete procedure for each table. Then you want a "wrapper" procedure that tracks the inserts/updates/deletes and responds accordingly to errors. A "transaction" would be the batch and "rollbacks" would be explicit. I put these in quotes because you don't want to encompass all of the transactions into a ...


1

Yes, take log backups more frequently. Is there a reason they are so infrequent? It seems like you have a lot of potential for losing data (not just in complete disaster). The log file will continue to grow until a backup is taken, because it will not re-use the space.


-3

Another solution would be to direct your transaction logs to a separate drive, and continue with the log backup or you could find the longest running transaction and kill it


2

A solution for a database set to recovery mode SIMPLE is having the FILESTREAM data in a read-only file group (which isn't your ideal option), and then backing up only the read/write file groups with DIFFERENTIAL like this: BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION; It will get any data that has changed in ...


1

I feel dirty providing this as an option, but if you choose to segregate the FILESTREAM data into its own database, you could maintain RI between the tables in the separate dbs by way of triggers: Triggers -> Remarks -> Limitations: A trigger is created only in the current database; however, a trigger can reference objects outside the current ...


2

The problem this caused was that the log file (which also gets backed up) is now unnecessarily large because it includes the FILESTREAM data. I'm not sure if you mean the log file itself is too large or that the log file backups become too large. If it's the former then how often were you backing the log up? Depending on the application design you may ...


0

The solution is quite simple. The issue is that the secondary node is set to 'Readable'. This locks the log file and any operation to shrink it will always fail with error 'The log for database [databasename] cannot be shrunk until all secondaries have moved past the point where the log was added. Change the configs for the AG and make the secondary ...



Top 50 recent answers are included