I have a developer who has dbo privileges in master and msdb, and also has
VIEW SERVER STATE and VIEW ANY DATABASE. According to SQL Server 2005
documentation she should be able to view the Activity Monitor, but instead
gets the following error:
TITLE: Microsoft SQL Server Management Studio
--
Cannot show requested dialog.
ADDITIONAL INFORMATION:
Unable to execute requested command.
Unable to launch Activity Monitor. You may not have sufficient permissions.
(ActivityMonitor)
SELECT permission denied on object 'tables', database 'mssqlsystemresource',
schema 'sys'.
SELECT permission denied on object 'partitions', database
'mssqlsystemresource', schema 'sys'.
Changed database context to '<db1>'.
Changed database context to '<db2>'.
Changed database context to '<db3>'.
Changed database context to '<db4>'.
Changed database context to '<db5>'.
Changed database context to '<db6>'.
Changed database context to 'tempdb'. (Microsoft SQL Server, Error: 229)
It popped up last week, and I read that Reporting Services running may have
an effect on it, so I stopped the service and she was able to get in with no
problem. No changes have been made to the server since I stopped the
service, but this error just started again today. No updates or patches hav
e
been installed on the server recently.
I have tried granting permission to 'tables' and 'partition' for master and
mssqlsystemresource db's, and to individual system tables but I run into
errors every time. I'm pretty new to SQL Server 2005 so please explain
everything in very simple terms!
THANKS!
Details: OS is Windows Server 2003 (clustered) and I have SQL Server 2005 SP
1 installed.Augspies (Augspies@.discussions.microsoft.com) writes:
> I have a developer who has dbo privileges in master and msdb, and also has
> VIEW SERVER STATE and VIEW ANY DATABASE. According to SQL Server 2005
> documentation she should be able to view the Activity Monitor, but instead
> gets the following error:
>...
> SELECT permission denied on object 'tables', database
> 'mssqlsystemresource',
> schema 'sys'.
> SELECT permission denied on object 'partitions', database
> 'mssqlsystemresource', schema 'sys'.
That's a tricky one. It would indicate that there are locks on tables
in msqlsystemresource. And mssqlsystemresource is unavailable to
everyone, including sa, but if you're in the sysadmin role, the
check may be bypassed so you don't see the error.
I don't really know what to suggest, but you could try my aba_lockinfo
which gives about the same information as the Actvity Monitor, but
without any GUI. You can get it from
http://www.sommarskog.se/sqlutil/aba_lockinfo.html.
Maybe I would be more worried over the locks in mssqlsystemresource.
That does not really sound normal to me...
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Showing posts with label activity. Show all posts
Showing posts with label activity. Show all posts
Friday, March 23, 2012
Monday, March 12, 2012
non logged transactions with transactional replication
I know that if you're doing log shipping and someone runs a fast bcp ( non
logged ) activity against the database that subsequent transaction log dumps
won't load until you do another full dump and load. This can be a problem,
because of the time involved in dumping and loading. How does transactional
replication handle non logged activity? The same way as log shipping? Which
would be bad, or does the data that was inserted or changed as a result of
the non logged transaction make it to the target server?
John,
it is my understanding that in the full recovery model, every change to the
database is logged, so there's no issue with transactional replication. In
SQL Server 2005 the transaction log may be backed up after minimally logged
operations (eg Bulk load operations in the bulk-logged model) so log
shipping is also possible.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||But, if you run a transaction that is truly minimally logged (BCP in
bulk-logged recovery model), you will have to reinitialize.
I don't understand why that is considered "bad". A minimally logged
transaction does not write everything to the tran log. Therefore, if you
were allowed to backup the tran log and restore it, you would wind up with a
corrupted database. With respect to replication, a minimally logged
transaction doesn't even hit the replication engine, so your publisher and
subscriber will completely out of synch and since there is no track of the
data, there is no ability to resynch them except by reinitializing.
(Replication doesn't even detect that a minimally logged transaction
occured.)
This is not an issue for either replication or log shipping. It is a side
effect of the way the transaction was executed. The replication and log
shipping features are simply protecting the integrity of the databases
against something they can not control.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:OMFC2BDLGHA.648@.TK2MSFTNGP14.phx.gbl...
> John,
> it is my understanding that in the full recovery model, every change to
> the database is logged, so there's no issue with transactional
> replication. In SQL Server 2005 the transaction log may be backed up after
> minimally logged operations (eg Bulk load operations in the bulk-logged
> model) so log shipping is also possible.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||It doesn't handle not logged activity because it is based on logged events
and you can't do non-logged events on tables you are replicating.
Non-logged activity will occur when the bulk copy recovery model is selected
and
1) you do certain operations, i.e. create index, select into, etc
2) fast bcp - which requires no indexes on the table among other things
transactional replication requires a table with an index, so you can't do
fast bcp with it. It also requires publications built on preexisting tables
so you won't be able to replicate a table you are selecting into.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"John" <John@.discussions.microsoft.com> wrote in message
news:59BAC0A1-DE3B-4E1B-A121-0C4E9B78497C@.microsoft.com...
>I know that if you're doing log shipping and someone runs a fast bcp ( non
> logged ) activity against the database that subsequent transaction log
> dumps
> won't load until you do another full dump and load. This can be a problem,
> because of the time involved in dumping and loading. How does
> transactional
> replication handle non logged activity? The same way as log shipping?
> Which
> would be bad, or does the data that was inserted or changed as a result of
> the non logged transaction make it to the target server?
|||Yes, you can in fact perform minimally logged operations on tables that are
being replicated. Writetext and updatetext come to mind.
Also there is no such thing as a "non-logged" event. Every single operation
that manipulates data will place some kind of entry into the log.
Therefore, the correct term is "minimally logged" and it has been for about
a decade now.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eLcsW4vLGHA.1192@.TK2MSFTNGP11.phx.gbl...
> It doesn't handle not logged activity because it is based on logged
> events and you can't do non-logged events on tables you are replicating.
> Non-logged activity will occur when the bulk copy recovery model is
> selected and
> 1) you do certain operations, i.e. create index, select into, etc
> 2) fast bcp - which requires no indexes on the table among other things
> transactional replication requires a table with an index, so you can't do
> fast bcp with it. It also requires publications built on preexisting
> tables so you won't be able to replicate a table you are selecting into.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "John" <John@.discussions.microsoft.com> wrote in message
> news:59BAC0A1-DE3B-4E1B-A121-0C4E9B78497C@.microsoft.com...
>
logged ) activity against the database that subsequent transaction log dumps
won't load until you do another full dump and load. This can be a problem,
because of the time involved in dumping and loading. How does transactional
replication handle non logged activity? The same way as log shipping? Which
would be bad, or does the data that was inserted or changed as a result of
the non logged transaction make it to the target server?
John,
it is my understanding that in the full recovery model, every change to the
database is logged, so there's no issue with transactional replication. In
SQL Server 2005 the transaction log may be backed up after minimally logged
operations (eg Bulk load operations in the bulk-logged model) so log
shipping is also possible.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||But, if you run a transaction that is truly minimally logged (BCP in
bulk-logged recovery model), you will have to reinitialize.
I don't understand why that is considered "bad". A minimally logged
transaction does not write everything to the tran log. Therefore, if you
were allowed to backup the tran log and restore it, you would wind up with a
corrupted database. With respect to replication, a minimally logged
transaction doesn't even hit the replication engine, so your publisher and
subscriber will completely out of synch and since there is no track of the
data, there is no ability to resynch them except by reinitializing.
(Replication doesn't even detect that a minimally logged transaction
occured.)
This is not an issue for either replication or log shipping. It is a side
effect of the way the transaction was executed. The replication and log
shipping features are simply protecting the integrity of the databases
against something they can not control.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:OMFC2BDLGHA.648@.TK2MSFTNGP14.phx.gbl...
> John,
> it is my understanding that in the full recovery model, every change to
> the database is logged, so there's no issue with transactional
> replication. In SQL Server 2005 the transaction log may be backed up after
> minimally logged operations (eg Bulk load operations in the bulk-logged
> model) so log shipping is also possible.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||It doesn't handle not logged activity because it is based on logged events
and you can't do non-logged events on tables you are replicating.
Non-logged activity will occur when the bulk copy recovery model is selected
and
1) you do certain operations, i.e. create index, select into, etc
2) fast bcp - which requires no indexes on the table among other things
transactional replication requires a table with an index, so you can't do
fast bcp with it. It also requires publications built on preexisting tables
so you won't be able to replicate a table you are selecting into.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"John" <John@.discussions.microsoft.com> wrote in message
news:59BAC0A1-DE3B-4E1B-A121-0C4E9B78497C@.microsoft.com...
>I know that if you're doing log shipping and someone runs a fast bcp ( non
> logged ) activity against the database that subsequent transaction log
> dumps
> won't load until you do another full dump and load. This can be a problem,
> because of the time involved in dumping and loading. How does
> transactional
> replication handle non logged activity? The same way as log shipping?
> Which
> would be bad, or does the data that was inserted or changed as a result of
> the non logged transaction make it to the target server?
|||Yes, you can in fact perform minimally logged operations on tables that are
being replicated. Writetext and updatetext come to mind.
Also there is no such thing as a "non-logged" event. Every single operation
that manipulates data will place some kind of entry into the log.
Therefore, the correct term is "minimally logged" and it has been for about
a decade now.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eLcsW4vLGHA.1192@.TK2MSFTNGP11.phx.gbl...
> It doesn't handle not logged activity because it is based on logged
> events and you can't do non-logged events on tables you are replicating.
> Non-logged activity will occur when the bulk copy recovery model is
> selected and
> 1) you do certain operations, i.e. create index, select into, etc
> 2) fast bcp - which requires no indexes on the table among other things
> transactional replication requires a table with an index, so you can't do
> fast bcp with it. It also requires publications built on preexisting
> tables so you won't be able to replicate a table you are selecting into.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "John" <John@.discussions.microsoft.com> wrote in message
> news:59BAC0A1-DE3B-4E1B-A121-0C4E9B78497C@.microsoft.com...
>
Subscribe to:
Posts (Atom)