best recovery mode

hi friends,
what should be the best recovery mode to implement.it is simple,full,bulklog
back.
which should be the efficient .
what is the microsoft recommendations for this
please help
thanks
reddyHi,
We can not differentiate and tell which one is good and which one is bad,
Recover model selection purely depends
on the data inside the database and type of recovery business requires.
FULL :- For production data which requires point-in-time recovery
BULK_LOGGED :- For production with high bulk operations and which do not
need a point-in-time recovery
SIMPLE :- For test and development environments. The recovery can be done
only till the last full backup.
Have a look into "Selecting a Recovery Model" in Books online for more
details.
Thanks
Hari
MCDBA
"reddy" <reddy@.discussions.microsoft.com> wrote in message
news:E42CF3FF-F4EC-476C-AFC0-D81428240791@.microsoft.com...
> hi friends,
> what should be the best recovery mode to implement.it is
simple,full,bulklogback.
> which should be the efficient .
> what is the microsoft recommendations for this
> please help
> thanks
> reddysql

Best and worst scenarios for Notification Services

Hi,

I am just looking for the best and worst scenarios to implement Notification services...This is more to come up with a design guildelines

I Would be more interested in the worst sceanrios :) Please share your inputs based on your experiences...

Regards,

Anjana

I'm not really sure that I understand what you mean by worst case scenario. Do you mean situations where SQLNS is not the best tool for the job? Or do you mean specific configurations that would cause SQLNS to perform poorly.

In either case, I guess, that's going to largely depend on the situation.

|||

I meant where SQLNS should not be used...

For example let's take three cases

News Alerts (changes with reasonable freqeuncy, and alerts must reach the subscriber in reasonable time)

Weather changes alerts(changes very frequently,and alerts can reach the subscriber in reasonable time)

Stock market alerts (changes very frequently and alert needs to be sent immedaitely to the subscriber with no delay).

In the above scenarios are there any scenarios where NS might perform a bit poorly?

Regards,

Anjana

|||

SQLNS is very good at matching lots of event data with lots of subscriber/subscription data and generating lots of events. It is designed to be "internet scalable" where you may not know just how many subscribers, subscriptions, or even events that you maybe processing over a given time period. It's equally as good for smaller applications, too.

For smaller, purely in-house notification applications, sometimes Query Notifications are a better choice. It just depends on what you're trying to accomplish.

For cases where sub-second notifications are required, SLQNS is *not* the best tool. The generator fires on a regular basis to evaluate whether there has been any activities that it needs to process. Same for the distributor. If you must be notified immediately, that is without a possible 2 second delay, SLQNS is not for you.

HTH...