Showing posts with label deploy. Show all posts
Showing posts with label deploy. Show all posts

Saturday, February 25, 2012

agents db rights for trans. repl

We are about to deploy transactional replication with queue updating
subscribers. Both the publisher and distributor are on server A and the
publisher is on server B. We have one publication on the publisher which
will PUSH a small database (around 51 articles) to the subscriber. The
MSSQLSERVER service and the SQLSERVERAGENT services run in the context of
a windows domain account. These services are configured with different
domain accounts on the 2 servers.
- Do the domain accounts require specific rights/permissions on both the SQL
servers and the databases?
- In the properties page for the snapshot agent, log reader agent, queue
reader and distribution agent there is an OWNER setting. Does this has to be
set to the domain accounts for the MSSQLSERVER and SQLSERVERAGENT services
so replication across servers can occur?
Sysadmin on the publisher, dbo on the subscriber for push, for pull sysadmin
on the subscriber and in the pal on the publisher.
I make the job owner sa. It works better for me, when I do this as opposed
to using another account.
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
"newsgroupuser" <abraxas1969@.hotmail.com> wrote in message
news:OAQA%23EPRFHA.1564@.TK2MSFTNGP09.phx.gbl...
> We are about to deploy transactional replication with queue updating
> subscribers. Both the publisher and distributor are on server A and the
> publisher is on server B. We have one publication on the publisher which
> will PUSH a small database (around 51 articles) to the subscriber. The
> MSSQLSERVER service and the SQLSERVERAGENT services run in the context
> of
> a windows domain account. These services are configured with different
> domain accounts on the 2 servers.
>
> - Do the domain accounts require specific rights/permissions on both the
> SQL
> servers and the databases?
>
> - In the properties page for the snapshot agent, log reader agent, queue
> reader and distribution agent there is an OWNER setting. Does this has to
> be
> set to the domain accounts for the MSSQLSERVER and SQLSERVERAGENT services
> so replication across servers can occur?
>
>

Sunday, February 12, 2012

After deploying a Business Intelligence project how to recreate the OLAP security

During development the project is focus on schema and schema changes and test

security. When I I deploy the database to production, I end getting

the development security in the production database. How does one create

a script that recreates the security in the production environment so that I can

be reused it after the deployment. The synchronziation wizard is not appropriate

since it moves data as well.

In SQL

Server Management Studio you can access Script related menu commands from the

context menu. All management dialogs in that program also have Script button on

the toolbar. An object can be scripted and script re-executed on another

server.

Additionally you can import entire database as a BI Development project using. In

BI Development Studio - menu File | New | Project and choose the project of

type "Import Analysis Services 9.0 Database". That imported solution

can be adjusted and deployed onto another server.

|||

I not sure what is meant by context senstive menus? I was hoping for a faster method.

I know that what I ending up doing was for each role in the production database Roles Heading:

I right clicked on the properties of the role and then selected the "Cubes" page and then clicked the Script Action menu.

This took 3 hours to do for all of the production roles:

I am not sure I understand the second choice since I did this at the beginning of the project, removed all of the

production security, made hundreds of changes to cubes and dimensions and readded the development security interactively.

|||You actually did what i meant. Performance is another story.