Showing posts with label separate. Show all posts
Showing posts with label separate. Show all posts

Thursday, March 29, 2012

Do SQL Analysis service needs a separate database ?

As Adventure Works have Adventure works DW as a separate database, Do we also needs to create new database such as while working with "pubs" or any other do we need to create pubs DW separately or pubs will be sufficient for our working for sql analysis ?

Hi,

you should to create a new DW database (it′s a best pratice), but it′s not mandatory.

If you have a small production database, you will not percept the performance degradation...

So to create a DW (Dataware house) can be good to isolate OLAP from OLTP.

Regards

Tuesday, March 27, 2012

Do I really need a cursor?

I've built an application to import transactions into the database. Bad transactions go in a separate table and dupe transactions get updated. Currently, it takes about 2 hours to import ~40K records using the code below. Obviously I'd like this to run as fast as possible and since cursors are a real drag I was wondering if there was a more efficient way to accomplish this.

DECLARE
@.contact_id int,
@.product_code char(9),
@.status_date datetime,
@.business_code char(4),
@.expire_date datetime,
@.prod_status char(4),
@.transaction_id int,
@.emailAddress varchar(50),
@.journal_id int

BEGIN TRAN
DECLARE transaction_import_cursor CURSOR
FOR SELECT transaction_id, product_code, emailAddress, status_date, business_code, expire_date, prod_status from transactions_batch_tmp
OPEN transaction_import_cursor
FETCH NEXT FROM transaction_import_cursor INTO @.transaction_id, @.product_code, @.emailAddress, @.status_date, @.business_code, @.expire_date, @.prod_status
WHILE (@.@.FETCH_STATUS = 0)
BEGIN
SELECT top 1 contacts.contact_id AS contact_id, transactions_batch_tmp.status_date AS status_date, transactions_batch_tmp.product_code AS product_code,
transactions_batch_tmp.business_code AS business_code, transactions_batch_tmp.expire_date AS expire_date,
transactions_batch_tmp.prod_status AS product_status
FROM transactions_batch_tmp INNER JOIN
journal INNER JOIN
contacts ON journal.contact_id = contacts.contact_id ON transactions_batch_tmp.emailAddress = contacts.emailAddress AND
transactions_batch_tmp.product_code = journal.product_code INNER JOIN
products ON transactions_batch_tmp.product_code = products.product_code
WHERE rtrim(ltrim(contacts.emailAddress)) = @.emailAddress AND journal.product_code = @.product_code
ORDER BY transactions_batch_tmp.status_date desc
IF @.@.ROWCOUNT = 0
BEGIN
print 'NEW transaction! ' + @.product_code + @.emailAddress
insert into journal (contact_id, product_code, status_date, business_code, expire_date, entryTypeID, product_status, date_entered)
SELECT distinct rtrim(ltrim(contacts.contact_id)) as cid, rtrim(ltrim(products.product_code)), transactions_batch_tmp.status_date,
rtrim(ltrim(transactions_batch_tmp.business_code)) , transactions_batch_tmp.expire_date, 21, rtrim(ltrim(transactions_batch_tmp.prod_status)), getDate()
FROM contacts INNER JOIN (transactions_batch_tmp INNER JOIN products ON transactions_batch_tmp.product_code=products.produ ct_code) ON contacts.emailAddress=transactions_batch_tmp.email Address
WHERE transactions_batch_tmp.transaction_id=@.transaction _id
END
ELSE
BEGIN
--print 'UPDATE transaction! ' + @.product_code + @.emailAddress
UPDATE journal
SET status_date =
(SELECT max(tmp.status_date)
FROM transactions_batch_tmp tmp, contacts c, products p, journal j
WHERE tmp.emailaddress = @.emailAddress
AND tmp.emailaddress = rtrim(c.emailaddress)
AND c.contact_id = j.contact_id
AND j.product_code = @.product_code
AND j.product_code = tmp.product_code)
FROM transactions_batch_tmp tmp, contacts c, products p, journal j
WHERE tmp.emailaddress = @.emailAddress
AND tmp.emailaddress = rtrim(c.emailaddress)
AND c.contact_id = j.contact_id
AND j.product_code = @.product_code
AND j.product_code = tmp.product_code
END
FETCH NEXT FROM transaction_import_cursor INTO @.transaction_id, @.product_code, @.emailAddress, @.status_date, @.business_code, @.expire_date, @.prod_status
END
CLOSE transaction_import_cursor
DEALLOCATE transaction_import_cursor
COMMIT TRAN

/** purge data from temp error table before writing bad records for this batch **/
truncate table tran_import_error;

/** write bad records (missing product code or email address) to temp_error table **/
insert into tran_import_error (transaction_id, product_code, emailAddress, date_entered)
SELECT DISTINCT transactions_batch_tmp.transaction_id, transactions_batch_tmp.product_code, transactions_batch_tmp.emailAddress, getDate()
FROM transactions_batch_tmp
where transactions_batch_tmp.emailaddress not in (select emailaddress from contacts)
OR
transactions_batch_tmp.product_code not in (select product_code from products)

TIAI don't see anything in your code that requires a cursor. It would run much faster as set-based INSERT and UPDATE statements.|||Well, how would I handle the update part without a cursor? I need to make sure that *only* unique contact_id-product_code values exist in the journal table.

Thanks.|||Add some bit flag and notes columns to your import table. Then you can run data checks against the records prior to importing them. Flag any duplicates or bad records and add a note as to why they were flagged. Then import only the non-flagged records. Delete the non-flagged records when you are done, and you are left with a list of bad records that you can review or discard.|||blindman - Thanks for your help.

I'm almost there (I hope), but was wondering if there was a more efficient way to delete the dupe records than having to write two separate queries. I need to keep the most recent product_code-status_date transaction for *each* person. This runs after I insert ALL the records in the journal table.

--delete dupe trans with status_date as the flag
DELETE journal FROM journal, contacts
JOIN
(select product_code, contact_id, max(status_date) as max_status_date
from journal
group by product_code, contact_id) AS G
ON G.[contact_id] = contacts.[contact_id]
WHERE journal.[status_date] < G.[max_status_date]
AND G.[product_code] = journal.[product_code];

--delete dupe trans with journal_id as the flag
DELETE journal FROM journal, contacts
JOIN
(select product_code, contact_id, max(journal_id) as maxID
from journal
group by product_code, contact_id) AS G
ON G.[contact_id] = contacts.[contact_id]
WHERE journal.[journal_id] < G.[MaxID]
AND G.[product_code] = journal.[product_code];

Thanks again.|||The contact table has nothing to do with your delete, except to limit the deleted records to those that have a contact_id. I assume that contact_id is part of journal's natural key and that all records have a valid contact_id, so drop if from both your queries. (If you do need it for filtering, join it in the subquery.)

--delete dupe trans with status_date as the flag
DELETE
FROM journal
INNER JOIN
(select product_code, contact_id, max(status_date) as max_status_date
from journal
group by product_code, contact_id) AS G
ON journal.[product_code] = G.[product_code]
and journal.[contact_id] = G.[contact_id]
and journal.[status_date] < G.[max_status_date]

--delete dupe trans with journal_id as the flag
DELETE journal
FROM journal
INNER JOIN
(select product_code, contact_id, max(journal_id) as maxID
from journal
group by product_code, contact_id) AS G
ON journal.[product_code] = G.[product_code]
and journal.[contact_id] = G.[contact_id]
and journal.[journal_id] < G.[MaxID]

It also appears that the first query should handle all product_code/contact_id duplicates except those with that share exactly the same status_date. If status_date stores only whole-date values, then I guess I see the point of the second delete statement, but otherwise I wouldn't expect you to get a high rowcount from it.

Now to your question; can this be done as a single SQL statement? Yes, but it would essentially require two nested subqueries, so I don't think you would get a big performance boost from it, and you would certainly have to sacrifice code clarity. I recommend that you leave it as two separate deletes.

Do I need to set a Drillthrough action to have Reporting Services perform a drillthrough?

Hi,

Do I need to set a Drillthrough action to have Reporting Services perform a drillthrough? Or are they two separate things?

To be clearer, is the point of the Drillthrough action (or any of the actions) only for the Cube Browser is AS2005 or are they used elsewhere, i.e. Reporting Services?

Thank you.

Gumbatman

I was also curius on whether reporting services support drillthrough or not, and found the following link. I guess, they don't.

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=126175

P.S. You don't mandatory need to have an DT action to use a Drillthrough statement.

|||

Irinia,

Thank you for the information. It is a great help. I was pulling my hair out trying to find an answer.

-Gumbatman

|||

A few clarifications:

- Drillthrough and other actions are often used in applications beyond just the AS 2005 cube browser.

- This MSDN paper describes the configuration of a drillthrough action:

http://msdn2.microsoft.com/en-us/library/ms345125.aspx

>>

Enabling Drillthrough in Analysis Services 2005

...

Analysis Services 2005 introduces a new action type called Drillthrough. The target of a drillthrough action can only be cells in the cube. The MDSCHEMA_ACTIONS schema rowset exposes these as rowset actions. The action expression is a DRILLTHROUGH statement that can be executed by the client application and the resulting rowset displayed to the user.

Clearly drillthrough fits in very cleanly into the actions framework. But the real advantage of drillthrough actions is that it provides the cube designer with the ability to pre-define the return columns of the DRILLTHROUGH statement (Figure 2). This is analogous to the Analysis Services 2000 experience where the database administrator specifies the tables and columns in the Drillthrough Options dialog in Analysis Manager.

...

>>

- Reporting Services has its own concept of "drillthrough" within a report (see paper excerpt below), so I assume that you're only referring to reporting the results of an Analysis Services drillthrough query.

- Though the Analysis Services Provider doesn't support AS drillthrough queries, the older OLE DB Provider still does, as mentioned in this OLAP newsgroup thread:

http://groups.google.com/group/microsoft.public.sqlserver.olap/msg/4870097ed8fcffda

>>

Message from discussion Linked Server to Analysis Services 2005 gets Access denied.

How about trying the OLE DB option? I couldn't get the following AW
Drillthrough query to work with the RS 2005 Analysis Services Provider;
but it returned 8 records when I used OLE DB for OLAP 9.0 instead:

Drillthrough
Select [Ship Date].[Calendar].[Calendar Year].&[2001] on columns,
[Customer].[Customer Geography].[State-Province].&[TAS]&Automobile on rows
from [Adventure Works]
where [Measures].[Internet Order Quantity]
>>

- For guidance on setting up AS drillthrough in Reporting Services using OLE DB, you can refer to this MSDN paper (even though it was written for SQL Server 2000):

http://msdn2.microsoft.com/en-us/library/aa902647(SQL.80).aspx

>>

Integrating Analysis Services with Reporting Services

...

Adding "Drill-through" Capability to a Report

The concept of "drill-through" can mean different things depending on the technology being used. For those familiar with Analysis Services, drill-through represents the ability to return the detail records that contribute to the value of a cell. For Reporting Services, "drill-through" is the capability to jump from one report to another report when the user selects an action-enabled object on the report. It's quite possible to develop a report that uses the drill-through action type for Reporting Services to issue an Analysis Services DRILLTHROUGH MDX query, and it's also possible to use the drill-through action type of Reporting Services to return a report that returns data from Analysis Services without using the DRILLTHROUGH MDX statement. Sound confusing? Hopefully a couple of examples can help us understand the difference between the two, and how the two concepts can also be used together.

...

>>

|||

Deepak,

Thank you so much for the information. It has clarified a bunch of things that I was having trouble getting my head around. There just didn't seem to be enough information about this. Plus, with Report Builder, it seems to do an "auto" drillthrough but I can't figure out how to control which fields are returned.

I am going to read all the information you sent.

Thanks again.

-Gumbatman

sql

Wednesday, March 21, 2012

DMZ, MSDTC and Windows Server 2003 SP1

Hi, did somebody know a checklist or Q-Article how to configure MSDTC
between
two SQL Server in two separate DMZ (Firewall Ports) ?
Further, I must find out which impact has Windows Server SP1 on MSDTC or
better
on a BizTalk 2004 Server.
Thanks for all Infos.
Hi
Check out "INFO: Configuring Microsoft Distributed Transaction Coordinator
(DTC) to Work Through a Firewall" http://support.microsoft.com/kb/250367/
Service Pack 1 enforces tighter security, if you can test the installation
on another system it would help but not guarantee there will not be issues.
You may want to run MBSA to see what it throws before you install the service
pack as these may be potential problem areas.
John
"MV" wrote:

> Hi, did somebody know a checklist or Q-Article how to configure MSDTC
> between
> two SQL Server in two separate DMZ (Firewall Ports) ?
> Further, I must find out which impact has Windows Server SP1 on MSDTC or
> better
> on a BizTalk 2004 Server.
> Thanks for all Infos.
>
>

DMZ, MSDTC and Windows Server 2003 SP1

Hi, did somebody know a checklist or Q-Article how to configure MSDTC
between
two SQL Server in two separate DMZ (Firewall Ports) ?
Further, I must find out which impact has Windows Server SP1 on MSDTC or
better
on a BizTalk 2004 Server.
Thanks for all Infos.Hi
Check out "INFO: Configuring Microsoft Distributed Transaction Coordinator
(DTC) to Work Through a Firewall" http://support.microsoft.com/kb/250367/
Service Pack 1 enforces tighter security, if you can test the installation
on another system it would help but not guarantee there will not be issues.
You may want to run MBSA to see what it throws before you install the service
pack as these may be potential problem areas.
John
"MV" wrote:
> Hi, did somebody know a checklist or Q-Article how to configure MSDTC
> between
> two SQL Server in two separate DMZ (Firewall Ports) ?
> Further, I must find out which impact has Windows Server SP1 on MSDTC or
> better
> on a BizTalk 2004 Server.
> Thanks for all Infos.
>
>

DMZ, MSDTC and Windows Server 2003 SP1

Hi, did somebody know a checklist or Q-Article how to configure MSDTC
between
two SQL Server in two separate DMZ (Firewall Ports) ?
Further, I must find out which impact has Windows Server SP1 on MSDTC or
better
on a BizTalk 2004 Server.
Thanks for all Infos.Hi
Check out "INFO: Configuring Microsoft Distributed Transaction Coordinator
(DTC) to Work Through a Firewall" http://support.microsoft.com/kb/250367/
Service Pack 1 enforces tighter security, if you can test the installation
on another system it would help but not guarantee there will not be issues.
You may want to run MBSA to see what it throws before you install the servic
e
pack as these may be potential problem areas.
John
"MV" wrote:

> Hi, did somebody know a checklist or Q-Article how to configure MSDTC
> between
> two SQL Server in two separate DMZ (Firewall Ports) ?
> Further, I must find out which impact has Windows Server SP1 on MSDTC or
> better
> on a BizTalk 2004 Server.
> Thanks for all Infos.
>
>

Saturday, February 25, 2012

distribution cleanup cannot clean up snapshot folder

We are using SQL Server 2005 SP2 to do transactional replication.

We and have a separate service account for the SQL Agents (sqladmin) vs. SQL Replication Agents (sqlrepadmin). It is my understanding this is a replication security best practice. The sqlrepadmin has full permissions on the snapshot share folder and it's subdirectories. The sqladmin account does not have permissions at all.

I have been getting an error message when we run the distribution clean up job.

Executed as user: PROD\sqladmin. Could not remove directory '\\Tes01box\Repldata\unc\qabox01_DB01_TO_ORACLE\20070905104896\'. Check the security context of xp_cmdshell

I have dropped the publication and recreated which is what appears to have caused the error.

From

http://technet.microsoft.com/en-us/library/ms151151.aspx

Note:

If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. If this account does not have sufficient privileges, log in with an account that does have sufficient privileges and remove the folder manually. Removing a folder requires the Modify privilege if the folder is a local path or the Full Control privilege if the folder is a network path.

The note above implies that the SQL Server service account (sqladmin) needs permissions on the snapshot folder as well.

Finally my questions:

Is there a workaround that will allow the distribution cleanup job to run as sqlrepadmin and perform the delete?

If both sqlrepadmin and sqladmin need permissions to the snapshot what is the reasoning from a security perspective of separating them out?

open up your distribution clean up task job, and in the job step properties do the following:

setuser 'sqlrepadmin'
GO
EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0, @.max_distretention = 72
GO|||


I did have to qualify the domain, as in DOMAIN\sqlrepadmin to get it to work. We have same login for 2 different domains.

What an amazingly simple and elegant solution. I feel silly that I did not think of this.

Thank you Hilary.

distribution cleanup cannot clean up snapshot folder

We are using SQL Server 2005 SP2 to do transactional replication.

We and have a separate service account for the SQL Agents (sqladmin) vs. SQL Replication Agents (sqlrepadmin). It is my understanding this is a replication security best practice. The sqlrepadmin has full permissions on the snapshot share folder and it's subdirectories. The sqladmin account does not have permissions at all.

I have been getting an error message when we run the distribution clean up job.

Executed as user: PROD\sqladmin. Could not remove directory '\\Tes01box\Repldata\unc\qabox01_DB01_TO_ORACLE\20070905104896\'. Check the security context of xp_cmdshell

I have dropped the publication and recreated which is what appears to have caused the error.

From

http://technet.microsoft.com/en-us/library/ms151151.aspx

Note:

If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. If this account does not have sufficient privileges, log in with an account that does have sufficient privileges and remove the folder manually. Removing a folder requires the Modify privilege if the folder is a local path or the Full Control privilege if the folder is a network path.

The note above implies that the SQL Server service account (sqladmin) needs permissions on the snapshot folder as well.

Finally my questions:

Is there a workaround that will allow the distribution cleanup job to run as sqlrepadmin and perform the delete?

If both sqlrepadmin and sqladmin need permissions to the snapshot what is the reasoning from a security perspective of separating them out?

open up your distribution clean up task job, and in the job step properties do the following:

setuser 'sqlrepadmin'
GO
EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0, @.max_distretention = 72
GO|||


I did have to qualify the domain, as in DOMAIN\sqlrepadmin to get it to work. We have same login for 2 different domains.

What an amazingly simple and elegant solution. I feel silly that I did not think of this.

Thank you Hilary.