Databases with simple recovery is NOT excluded when backing up logs

SQL 2005 SP2:
I have several Sharepoint databases, all in full recovery mode except the
large search database which I want to run in simple mode because of the
large amount of transactions and because data recovery is not needed.
The back up log task in SQL Server Managment Studio is said to automatically
exclude databases in simple recovery mode, but it doesen't - anyone having a
workaround?
Other users reported that this problem was introduced in SP2, see
http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1336939&SiteID=17
Here's how I reproduce the error:
When I edit a maintenance plan which backs up transaction logs, I can select
"Database(s)":
At the top of the window it says after the yellow exclamation mark:
"Databases with simple recovery will be excluded". Here I select "All user
databases". (I want to use "All user databases" so that any Sharepoint
databases created in the future are automatically included in this task.)
Back at the "Back up Database Task", when using the button "View T-SQL" i
see that the database in simple mode is not included - as expected.
But when the task is run, it fails. That is, it does what it is expected
to - it backs up all logs except from the database in simple mode, but it
returns an error; where I expected it to run with out error.
When looking in the job log in MSSQL\LOG, it shows that the reason of the
error is that it tried to backup the log from the database in simple
recovery mode - which the GUI said was excluded from the task.
"Failed:(0) Database 'SharedServices1_Search_DB' will not be backed up
because it does not have its recovery model set to Full or BulkLogged."
Regards,
Peter
www.skov.comHi Peter, I have confirmed that this issue happens and have filed a Connect
item. Please vote and add any other pertinent information.
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=320914
"Peter" <pafpaf@.hotmail.com> wrote in message
news:urIlQygTIHA.536@.TK2MSFTNGP06.phx.gbl...
> SQL 2005 SP2:
> I have several Sharepoint databases, all in full recovery mode except the
> large search database which I want to run in simple mode because of the
> large amount of transactions and because data recovery is not needed.
> The back up log task in SQL Server Managment Studio is said to
> automatically exclude databases in simple recovery mode, but it doesen't -
> anyone having a workaround?
> Other users reported that this problem was introduced in SP2, see
> http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1336939&SiteID=17
> Here's how I reproduce the error:
> When I edit a maintenance plan which backs up transaction logs, I can
> select "Database(s)":
> At the top of the window it says after the yellow exclamation mark:
> "Databases with simple recovery will be excluded". Here I select "All user
> databases". (I want to use "All user databases" so that any Sharepoint
> databases created in the future are automatically included in this task.)
> Back at the "Back up Database Task", when using the button "View T-SQL" i
> see that the database in simple mode is not included - as expected.
> But when the task is run, it fails. That is, it does what it is expected
> to - it backs up all logs except from the database in simple mode, but it
> returns an error; where I expected it to run with out error.
> When looking in the job log in MSSQL\LOG, it shows that the reason of the
> error is that it tried to backup the log from the database in simple
> recovery mode - which the GUI said was excluded from the task.
> "Failed:(0) Database 'SharedServices1_Search_DB' will not be backed up
> because it does not have its recovery model set to Full or BulkLogged."
> Regards,
> Peter
> www.skov.com
>
>
>|||I also posted a related item:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=320918|||Good idea, I was actually thinking exactly the same today when I had the
problem. :-)
Peter
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23CaJ7%23hTIHA.4880@.TK2MSFTNGP03.phx.gbl...
>I also posted a related item:
> https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=320918
>
...it would be beneficial to be able to examine the T-SQL and possibly amend
or comment out the line(s) that are causing problems

Databases with simple recovery is NOT excluded when backing up logs

SQL 2005 SP2:
I have several Sharepoint databases, all in full recovery mode except the
large search database which I want to run in simple mode because of the
large amount of transactions and because data recovery is not needed.
The back up log task in SQL Server Managment Studio is said to automatically
exclude databases in simple recovery mode, but it doesen't - anyone having a
workaround?
Other users reported that this problem was introduced in SP2, see
http://forums.microsoft.com/TechNet...36939&SiteID=17
Here's how I reproduce the error:
When I edit a maintenance plan which backs up transaction logs, I can select
"Database(s)":
At the top of the window it says after the yellow exclamation mark:
"Databases with simple recovery will be excluded". Here I select "All user
databases". (I want to use "All user databases" so that any Sharepoint
databases created in the future are automatically included in this task.)
Back at the "Back up Database Task", when using the button "View T-SQL" i
see that the database in simple mode is not included - as expected.
But when the task is run, it fails. That is, it does what it is expected
to - it backs up all logs except from the database in simple mode, but it
returns an error; where I expected it to run with out error.
When looking in the job log in MSSQL\LOG, it shows that the reason of the
error is that it tried to backup the log from the database in simple
recovery mode - which the GUI said was excluded from the task.
"Failed0) Database 'SharedServices1_Search_DB' will not be backed up
because it does not have its recovery model set to Full or BulkLogged."
Regards,
Peter
www.skov.comHi Peter, I have confirmed that this issue happens and have filed a Connect
item. Please vote and add any other pertinent information.
https://connect.microsoft.com/SQLSe...=3209
14
"Peter" <pafpaf@.hotmail.com> wrote in message
news:urIlQygTIHA.536@.TK2MSFTNGP06.phx.gbl...
> SQL 2005 SP2:
> I have several Sharepoint databases, all in full recovery mode except the
> large search database which I want to run in simple mode because of the
> large amount of transactions and because data recovery is not needed.
> The back up log task in SQL Server Managment Studio is said to
> automatically exclude databases in simple recovery mode, but it doesen't -
> anyone having a workaround?
> Other users reported that this problem was introduced in SP2, see
> http://forums.microsoft.com/TechNet...36939&SiteID=17
> Here's how I reproduce the error:
> When I edit a maintenance plan which backs up transaction logs, I can
> select "Database(s)":
> At the top of the window it says after the yellow exclamation mark:
> "Databases with simple recovery will be excluded". Here I select "All user
> databases". (I want to use "All user databases" so that any Sharepoint
> databases created in the future are automatically included in this task.)
> Back at the "Back up Database Task", when using the button "View T-SQL" i
> see that the database in simple mode is not included - as expected.
> But when the task is run, it fails. That is, it does what it is expected
> to - it backs up all logs except from the database in simple mode, but it
> returns an error; where I expected it to run with out error.
> When looking in the job log in MSSQL\LOG, it shows that the reason of the
> error is that it tried to backup the log from the database in simple
> recovery mode - which the GUI said was excluded from the task.
> "Failed0) Database 'SharedServices1_Search_DB' will not be backed up
> because it does not have its recovery model set to Full or BulkLogged."
> Regards,
> Peter
> www.skov.com
>
>
>|||I also posted a related item:
https://connect.microsoft.com/SQLSe...=3209
18|||Good idea, I was actually thinking exactly the same today when I had the
problem. :-)
Peter
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in mess
age
news:%23CaJ7%23hTIHA.4880@.TK2MSFTNGP03.phx.gbl...
>I also posted a related item:
> https://connect.microsoft.com/SQLSe...=32
0918
>
...it would be beneficial to be able to examine the T-SQL and possibly amen
d
or comment out the line(s) that are causing problems

Database vs Schema

We currently have a product in which each client has their own Database. We adjust the connection when a user for that client logs into the system. This system has continued to grow and a good pace, but we have come to a point where failover is taking too long.

Refactoring the Database to handle multiple sites in a single database is not an option because of the time it would take to make the change. So, we are looking for another way in which this could be handle. One idea is to take multiple clients and place them in a single database using a schema to seperate them. (ex. Client A = server1.db1.schema1, Client B = server1.db1.schema2, etc).

Is there another option that would be better, or what kind of performance can we expect if we follow this path? Or, is there a way to decrease the failover time (it appears the problem is the startup of the database on the failover server)?

Thad

You are right that having a large number of databases will increase your fail-over time in a fail-over cluster.

Since you mentioned schemas, you must be on SQL Server 2005. For fail-over time, database mirroring is much faster than fail-over clustering. Database mirroring does require twice the storage space, and the licensing situation is not good compared to an Active/Passive cluster. You would have to mirror each database individually.

Are you failing-over for maintenance, rolling upgrades, etc.? Maintaining and adding dozens of schema in a database would be cumbersome and prone to error. It also has some performance drawbacks, since if you don't properly schema qualify a SP name (from code), or a table name (in an SP), you will have name resolution problems and cache misses.

Depending on the numbers of clients you are talking about, I would think about getting another cluster to split the load.

|||

Currently the failover system is done for disaster recovery scenarios. As for performance. All our inline sql from the client class generate sql similar to

Code Snippet

SELECT [Schema].[Table].[Field] FROM [Schema].[Table]

While a stored procedure is set is setup so it exists in each schema, but the schema name is not used in the sproc body. This is the same method we would use with Views and Functions.

Code Snippet

CREATE PROCEDURE [Schema].[ProcedureName](@.Param INT) AS

BEGIN

SELECT * FROM [Table]

END

Would setting up the schema in this way cause these performance drawbacks. I am thinking that maintaining multiple schema will be as error prone as setting up the single db for each client.

Currently we are talking about approx 1000+ clients.

|||

If your client code can pick up the schema name dynamically from a config file or something, then having a schema for each client as opposed to a database for each client will probably be not much different from a maintenance and configuration perspective.

There may be some negative effects on your buffer cache and procedure cache from this approach. Instead of having one large, normalized table that holds data for all your clients in a single database, you will have one table for each client. You will have multiple copies of the same SP (for different schemas) in your procedure cache.

|||Currently the client already selects the Database so we would just need to add a schema selector to the data selection. So all that is straight forward. And yes we are duplicating the entire database inside a schema.

As for the procedure and data cache, which I am not completely familar with, would it not be the same as multiple database?

I can that this is not the best solution, but I think it may be the best solution given the time and other hardware constraints we have. So, it appears that there are little differences in performance and maintenance that we already deal with.