Tag Info

New answers tagged

1

I think you might be a bit confused about virtualization. Which virtualization platform are you using? I havent come across one yet that doesnt allow you to map the drives however you choose. There are default configs and settings that allow the hypervisor to decide how to best make use of the available host's resources, but I have never seen an offering ...


0

The real use case for table partitioning is fast load and unload of data. If your warehouse tables and staging tables are in the same database, and have the same schema, you will be able to swap a partition from staging to warehouse very quickly. Similarly, when data has reached it retention expiry date and must be purged, it is very quick to delete a ...


1

For very large Databases you can always use the compression method in SQL server 2012. That will help a lot in reducing down the backup size of the database: For how to use and more on this refer to below link: http://www.sqlservergeeks.com/sql-server-database-backup-compression-faster-disaster-recovery/ To avail the space, make sure you're backup ...


3

Since your problem is a conflict between constant updates and being able to run reports without facing deadlocks, I would recommend you consider using READ_COMMITTED_SNAPSHOT isolation set ON. This also has overhead, but usually prevents most deadlocking situations. (Nothing is magic, of course.) You should read the details at: ...


0

I looked at the two suggested tools above but had trouble installing them on my system. (I have access to My DB not the whole server.) If the updates to your table is only additions, no changes in history, the process to partition (or add indexes) to the table is a lot easier and reasonable to hack yourself without external tools. My solution was to make a ...


4

Add a second column which will hold a hash of the text value. Create the index on the hash. Even if there is a hash collision there will be only a few rows to read and perform a full comparison on the text vlaues.


0

If you omit the partitioning column in the initial query, it should be possible to complete the queries entirely from indexes. This should be significantly faster. Given this example I would drop t1 and t2 as the key columns should be available from t3. This should be significantly faster. If you need data from t1 and/or t2, join them to t3. Check ...



Top 50 recent answers are included