When replication started working, (Okay it didn’t start working until we find out that there was a security issue and correct it.) I wanted to check what are the other tables were affected.
As I know the publication database and subscription database, we can get the data from sysarticles table from the publication database.
There were three methods before me to get row count.
- Selecting data by using SELECT COUNT(1) FROM <table> method. This result is accurate, but it will consume a lot of memory and time. This will result reading the entire clustered index (a full clustered index scan) or a table scan.
- Reading the rows FROM sysindexes for the clustered index or heap. This is the fastest method but there is a possibility of inaccuracy. (Even when I ran the test I got some slightly inaccurate results.) This method is fairly okay if you want to know the approximate row count, but in case you need to get the exact row count, this method is not recommended.
- Using sp_SpaceUsed system procedure. This method also does not give accurate numbers; additionally as this is a stored procedure, it does not gives the flexibility to add additional columns or remove unnecessary columns. Additionally, even though this stored procedure accepts schema_name.table_name format as input, on the output only table name is mentioned. This may give some issues if your database having multiple tables with the same name (in different schemas).
SELECT '
SELECT ''source'' AS Table_Location,
'''+ OBJECT_SCHEMA_NAME(a.objid)+''' AS SchemaName,
'''+ OBJECT_NAME(a.objid) +''' AS TableName,
COUNT(*) as row_count
FROM '+ OBJECT_SCHEMA_NAME(a.objid)+'.'+ OBJECT_NAME(a.objid)+'
UNION ALL
SELECT ''destination'' AS Table_Location,
'''+ a.dest_owner +''' AS SchemaName,
'''+ a.dest_table +''' AS TableName,
COUNT(*) as row_count
FROM '+ s.dest_db +'.'+ a.dest_owner +'.'+ a.dest_table
FROM dbo.sysarticles a
INNER JOIN dbo.syssubscriptions s
ON a.artid = s.artid
Is this usefull?
No comments:
Post a Comment