Search Results

Search found 1650 results on 66 pages for 'indexes'.

Page 1/66 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• Unused Indexes Gotcha

  - by DavidWimbush

  I'm currently looking into dropping unused indexes to reduce unnecessary overhead and I came across a very good point in the excellent SQL Server MVP Deep Dives book that I haven't seen highlighted anywhere else. I was thinking it was simply a case of dropping indexes that didn't show as being used in DMV sys.dm_db_index_usage_stats (assuming a solid representative workload had been run since the last service start). But Rob Farley points out that the DMV only shows indexes whose pages have been read or updated. An index that isn't listed in the DMV might still be useful by providing metadata to the Query Optimizer and thus streamlining query plans. For example, if you have a query like this: select  au.author_name         , count(*) as books from    books b         inner join authors au on au.author_id = b.author_id group by au.author_name If you have a unique index on authors.author_name the Query Optimizer will realise that each author_id will have a different author_name so it can produce a plan that just counts the books by author_id and then adds the author name to each row in that small table. If you delete that index the query will have to join all the books with their authors and then apply the GROUP BY - a much more expensive query. So be cautious about dropping apparently unused unique indexes.

  Read the article

• Stairway to SQL Server Indexes: Step 1, Introduction to Indexes

  Indexes are the database objects that enable SQL Server to satisfy each data access request from a client application with the minimum amount of effort, resulting in the maximum performance of individual requests while also reducing the impact of one request upon another. Prerequisites: Familiarity with the following relational database concepts: Table, row, primary key, foreign key Join SQL Backup’s 35,000+ customers to compress and strengthen your backups "SQL Backup will be a REAL boost to any DBA lucky enough to use it." Jonathan Allen. Download a free trial now.

  Read the article

• When SQL Server Nonclustered Indexes Are Faster Than Clustered Indexes

  SQL Server Clustered indexes can have enormous implications for performance of operations on a table. But are there times when a SQL Server non-clustered index would perform better than a clustered index for the same operation? Are there any trade-offs to consider? Check out this tip to learn more. Deployment Manager 2 is now free!The new version includes tons of new features and we've launched a completely free Starter Edition! Get Deployment Manager here

  Read the article

• Analysing Indexes - reducing scans.

  - by GrumpyOldDBA

  The whole subject of database/application tuning is sometimes akin to a black art, it's pretty easy to find your worst 20 whatever but actually seeking to reduce operational overhead can be slightly more tricky. If you ever read through my analysing indexes post you'll know I have a number of ways of seeking out ways to tune the database. -- This is a slightly different slant on one of those which produced an interesting side effect. -- We all know that except for very small tables avoiding...(read more)

  Read the article

• Analysing Indexes - count *

  - by GrumpyOldDBA

  In my presentations on indexing I have always said that you should explore the advantages of covering your clustered index with a secondary index. In circumstances where you might want to just return values form the PK ( assuming it's your clustered index ) a secondary index will be more efficient especially when the row size is wide. Any operation on a clustered index will always return the entire row, so select ID from dbo.mytable where ID is the clustered PK integer will return not just the...(read more)

  Read the article

• Un-used Indexes on MDP_MATRIX Consuming Resources

  - by user702295

  Disable un-used Indexes: As much as it is recommended to create relevant indexes, it is advised not to have too many indexes on the mdp_matrix table.  Too many indexes will cause long waits on the table as indexes needs to get updated every time the table is updated.  There are many seeded indexes on mdp_matrix, every out of the box data model level has an index on the matrix table.  If a level is unused in the specific data model of the implementation, it is advisable to disable that index.  If the customer is not sure if and how indexes are utilized, the DBA can monitor all indexes.  After a few cycles of operation, the DBA should go over that list and see which indexes have not been used.  Consider disabling them. There are scripts on the net to monitor indexes or use the monitoring usage clause in the alter index statement.

  Read the article

• mysql and indexes with more than one column

  - by clarkk

  How to use indexes with more than one column The original index has an index on block_id, but is it necesarry when it's already in the unique index with two column? Indexes with more than one column (a,b,c) you can search for a, b and c you can search for a and b you can search for a you can not search for a and c Does this apply to unique indexes too? table id block_id account_id name indexes origin PRIMARY KEY (`id`) UNIQUE KEY `block_id` (`block_id`,`account_id`) KEY `block_id` (`block_id`), KEY `account_id` (`account_id`), indexes alternative PRIMARY KEY (`id`) UNIQUE KEY `block_id` (`block_id`,`account_id`) KEY `account_id` (`account_id`),

  Read the article

• MySQL indexes: how do they work?

  - by bob-the-destroyer

  I'm a complete newbie with MySQL indexes. I have several MyISAM tables on MySQL 5.0x having utf8 charsets and collations with 100k+ records each. The primary keys are generally integer. Many columns on each table may have duplicate values. I need to quickly count, sum, average, or otherwise perform custom calculations on any number of fields in each table or joined on any number of others. I found this page giving an overview of MySQL index usage: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html, but I'm still not sure I'm using indexes right. Just when I think I've made the perfect index out of a collection of fields I want to calculate against, I get the "index must be under 1000 bytes" error. Can anyone explain how to most efficiently create and use indexes to speed up queries? Caveat: upgrading Mysql is not possible in this case. Using Navicat Light for db administration, but this app isn't required.

  Read the article

• Do non-clustered indexes slow down inserts?

  - by mikeinmadison

  I'm working in Sql Server 2005. I have an event log table that tracks user actions, and I want to make sure that inserts into the table are as fast as possible. Currently the table doesn't have any indexes. Does adding a single non-clustered index slow down inserts at all? Or is it only clustered indexes that slow down inserts? Or should I just add a clustered index and not worry about it?

  Read the article

• Problem performance datawarehouse with lots of indexes

  - by Lieven Cardoen

  Our product takes tests of some 350 candidates at the same time. At the end of the test, results for each candidate are moved to a datawarehouse full of indexes on it. For each test there's some 400 records to be entered in datawarehouse. So 400 x 350 is a lot of records. If there are not much records in the datawarehouse, all goes well. But if there are already lots of records in the datawarehouse, then a lot of inserts fail... Is there a way to have indexes that are only rebuild at the end of the day or isn't that the real problem? Or how would you solve this?

  Read the article

• July, the 31 Days of SQL Server DMO’s – Day 23 (sys.dm_db_index_usage_stats)

  - by Tamarick Hill

  The sys.dm_db_index_usage_stats Dynamic Management View is used to return usage information about the various indexes on your SQL Server instance. Let’s have a look at this DMV against our AdventureWorks2012 database so we can examine the information returned. SELECT * FROM sys.dm_db_index_usage_stats WHERE database_id = db_id('AdventureWorks2012') The first three columns in the result set represent the database_id, object_id, and index_id of a given row. You can join these columns back to other system tables to extract the actual database, object, and index names. The next four columns are probably the most beneficial columns within this DMV. First, the user_seeks column represents the number of times that a user query caused a seek operation against a particular index. The user_scans column represents how many times a user query caused a scan operation on a particular index. The user_lookups column represents how many times an index was used to perform a lookup operation. The user_updates column refers to how many times an index had to be updated due to a write operation that effected a particular index. The last_user_seek, last_user_scan, last_user_lookup, and last_user_update columns provide you with DATETIME information about when the last user scan, seek, lookup, or update operation was performed. The remaining columns in the result set are the same as the ones we previously discussed, except instead of the various operations being generated from user requests, they are generated from system background requests. This is an extremely useful DMV and one of my favorites when it comes to Index Maintenance. As we all know, indexes are extremely beneficial with improving the performance of your read operations. But indexes do have a downside as well. Indexes slow down the performance of your write operations, and they also require additional resources for storage. For this reason, in my opinion, it is important to regularly analyze the indexes on your system to make sure the indexes you have are being used efficiently. My AdventureWorks2012 database is only used for demonstrating or testing things, so I dont have a lot of meaningful information here, but for a Production system, if you see an index that is never getting any seeks, scans, or lookups, but is constantly getting a ton of updates, it more than likely would be a good candidate for you to consider removing. You would not be getting much benefit from the index, but yet it is incurring a cost on your system due to it constantly having to be updated for your write operations, not to mention the additional storage it is consuming. You should regularly analyze your indexes to ensure you keep your database systems as efficient and lean as possible. One thing to note is that these DMV statistics are reset every time SQL Server is restarted. Therefore it would not be a wise idea to make decisions about removing indexes after a Server Reboot or a cluster roll. If you restart your SQL Server instances frequently, for example if you schedule weekly/monthly cluster rolls, then you may not capture indexes that are being used for weekly/monthly reports that run for business users. And if you remove them, you may have some upset people at your desk on Monday morning. If you would like to begin analyzing your indexes to possibly remove the ones that your system is not using, I would recommend building a process to load this DMV information into a table on scheduled basis, depending on how frequently you perform an operation that would reset these statistics, then you can analyze the data over a period of time to get a more accurate view of what indexes are really being used and which ones or not. For more information about this DMV, please see the below Books Online link: http://msdn.microsoft.com/en-us/library/ms188755.aspx Follow me on Twitter @PrimeTimeDBA

  Read the article

• Grails multi column indexes

  - by Kimble

  Can someone explain how to define multi column indexes in Grails? The documentation is at best sparse. This for example does not seem to work at all: http://grails.org/GORM+Index+definitions I've had some luck with this, but the results seems random at best. Definitions that works in one domain class does not when applied to another (with different names of course). http://www.grails.org/doc/1.1/guide/single.html#5.5.2.6%20Database%20Indices Some working examples and explanations would be highly appreciated!

  Read the article

• Unsigned versus signed numbers as indexes

  - by simendsjo

  Whats the rationale for using signed numbers as indexes in .Net? In Python, you can index from the end of an array by sending negative numbers, but this is not the case in .Net. It's not easy for .Net to add such a feature later as it could break other code perhaps using special rules (yeah, a bad idea, but I guess it happens) on indexing. Not that I have ever have needed to index arrays over 2,147,483,647 in size, but I really cannot understand why they choose signed numbers. Can it be because it's more normal to use signed numbers in code?

  Read the article

• VB.NET Incrementing Indexes

  - by Daniel

  Hello, I am having trouble incrementing the indexes of my list item properties. Here is the code. Dim i As Integer = 0 For x As Integer = 1 To list.Count / 19 database.ExecuteCommand("INSERT INTO Contacts VALUES ('" + _ list.Item(i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "', '" + _ list.Item(++i) + "')") Next The ++i does not increment at all in the parameters. Thanks

  Read the article

• SQL with Regular Expressions vs Indexes with Logical Merging Functions

  - by geeko

  Hello Lads, I am trying to develop a complex textual search engine. I have thousands of textual pages from many books. I need to search pages that contain specified complex logical criterias. These criterias can contain virtually any compination of the following: A: Full words. B: Word roots (semilar to stems; i.e. all words with certain key letters). C: Word templates (in some languages are filled in certain templates to form various part of speech such as adjactives, past/present verbs...). D: Logical connectives: AND/OR/XOR/NOT/IF/IFF and parentheses to state priorities. Now, would it be faster to have the pages' full text in database (not indexed) and search though them all using SQL and Regular Expressions ? Or would it be better to construct indexes of word/root/template-page-location tuples. Hence, we can boost searching for individual words/roots/templates. However, it gets tricky as we interdouce logical connectives into our query. I thought of doing the following steps in such cases: 1: Seperately search for each individual words/roots/templates in the specified query. 2: On priority bases, we merge two result lists (from step 1) at a time depedning on the logical connective For example, if we are searching for "he AND (is OR was)": 1: We shall search for "he", "is" and "was" seperately and get result lists for each word. 2: Merge the result lists of "is" and "was" using the merging function OR-MERGE 3: Merge the merged result list from the OR-MERGE function with the one of "he" using the merging function AND-MERGE The result of step 3 is then returned as the result of the specified query. What do you think gurues ? Which is faster ? Any better ideas ? Thank you all in advance.

  Read the article

• text indexes vs integer indexes in mysql

  - by imanc

  Hey, I have always tried to have an integer primary key on a table no matter what. But now I am questioning if this is always necessary. Let's say I have a product table and each product has a globally unique SKU number - that would be a string of say 8-16 characters. Why not make this the PK? Typically I would make this field a unique index but then have an auto incrementing int field as the PK, as I assumed it would be faster, easier to maintain, and would allow me to do things like get the last 5 records added with ease. But in terms of optimisation, assuming I'd only ever be matching the full text field and next doing text matching queries (e.g. like %%) can you guys think of any reasons not to use a text based primary key, most likely of type varchar()? Cheers, imanc

  Read the article

• MongoDB with OR and Range Indexes

  - by LMH

  I have a query: {"$query"=>{"user_id"=>"512f7960534dcda22b000491", "$or"=>[{"when_tz"=>{"$gte"=>2010-06-24 04:00:00 UTC, "$lt"=>2010-06-25 04:00:00 UTC}}, {"when_tz"=>{"$gte"=>2011-06-24 04:00:00 UTC, "$lt"=>2011-06-25 04:00:00 UTC}}, {"when_tz"=>{"$gte"=>2012-06-24 04:00:00 UTC, "$lt"=>2012-06-25 04:00:00 UTC}}], "_type"=>{"$in"=>["FacebookImageItem", "FoursquareImageItem", "InstagramItem", "TwitterImageItem", "Image"]}}, "$explain"=>true, "$orderby"=>{"when_tz"=>1}} And an index: { user_id: 1, _type: 1, when_tz: 1 } Explain: {"cursor"="BtreeCursor user_id_1__type_1_facebook_id_1 multi", "isMultiKey"=false, "n"=28, "nscannedObjects"=15094, "nscanned"=15098, "nscannedObjectsAllPlans"=181246, "nscannedAllPlans"=241553, "scanAndOrder"=true, "indexOnly"=false, "nYields"=12, "nChunkSkips"=0, "millis"=2869, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "facebook_id"=[[{"$minElement"=1}, {"$maxElement"=1}]]}, "allPlans"=[{"cursor"="BtreeCursor user_id_1__type_1_facebook_id_1 multi", "n"=28, "nscannedObjects"=15094, "nscanned"=15098, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "facebook_id"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1__type_1_twitter_id_1 multi", "n"=28, "nscannedObjects"=15094, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "twitter_id"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1__type_1_instagram_id_1 multi", "n"=28, "nscannedObjects"=15094, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "instagram_id"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1__type_1_foursquare_id_1 multi", "n"=28, "nscannedObjects"=15094, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "foursquare_id"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_phash_1", "n"=21, "nscannedObjects"=15097, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "phash"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_aperature_1_shutter_speed_1_when_tz_1", "n"=25, "nscannedObjects"=35, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "aperature"=[[{"$minElement"=1}, {"$maxElement"=1}]], "shutter_speed"=[[{"$minElement"=1}, {"$maxElement"=1}]], "when_tz"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_image_hash_1", "n"=22, "nscannedObjects"=15097, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "image_hash"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_time_zone_guessed_1_when_tz_-1", "n"=23, "nscannedObjects"=32, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "time_zone_guessed"=[[{"$minElement"=1}, {"$maxElement"=1}]], "when_tz"=[[{"$maxElement"=1}, {"$minElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_time_zone_guessed_1_when_tz_1", "n"=24, "nscannedObjects"=33, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "time_zone_guessed"=[[{"$minElement"=1}, {"$maxElement"=1}]], "when_tz"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_time_zone_guessed_1_when_utc_-1", "n"=23, "nscannedObjects"=15097, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "time_zone_guessed"=[[{"$minElement"=1}, {"$maxElement"=1}]], "when_utc"=[[{"$maxElement"=1}, {"$minElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_time_zone_guessed_1_when_utc_1", "n"=24, "nscannedObjects"=15097, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "time_zone_guessed"=[[{"$minElement"=1}, {"$maxElement"=1}]], "when_utc"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1_original_shared_item_id_1", "n"=24, "nscannedObjects"=15097, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "original_shared_item_id"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1__type_1_s3_tmp_file_1 multi", "n"=28, "nscannedObjects"=15094, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "s3_tmp_file"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1__type_1_processed_-1_uploaded_-1_image_device_1 multi", "n"=28, "nscannedObjects"=15094, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "processed"=[[{"$maxElement"=1}, {"$minElement"=1}]], "uploaded"=[[{"$maxElement"=1}, {"$minElement"=1}]], "image_device"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BtreeCursor user_id_1__type_1_when_tz_1 multi", "n"=28, "nscannedObjects"=28, "nscanned"=15097, "indexBounds"={"user_id"=[["512f7960534dcda22b000491", "512f7960534dcda22b000491"]], "_type"=[["FacebookImageItem", "FacebookImageItem"], ["FoursquareImageItem", "FoursquareImageItem"], ["Image", "Image"], ["InstagramItem", "InstagramItem"], ["TwitterImageItem", "TwitterImageItem"]], "when_tz"=[[{"$minElement"=1}, {"$maxElement"=1}]]}}, {"cursor"="BasicCursor", "n"=0, "nscannedObjects"=15097, "nscanned"=15097, "indexBounds"={}}], "server"=""} Any idea how to get it to hit the indexes?

  Read the article

• SQL Server - Rebuilding Indexes

  - by Renso

  Goal: Rebuild indexes in SQL server. This can be done one at a time or with the example script below to rebuild all index for a specified table or for all tables in a given database. Why? The data in indexes gets fragmented over time. That means that as the index grows, the newly added rows to the index are physically stored in other sections of the allocated database storage space. Kind of like when you load your Christmas shopping into the trunk of your car and it is full you continue to load some on the back seat, in the same way some storage buffer is created for your index but once that runs out the data is then stored in other storage space and your data in your index is no longer stored in contiguous physical pages. To access the index the database manager has to "string together" disparate fragments to create the full-index and create one contiguous set of pages for that index. Defragmentation fixes that. What does the fragmentation affect?Depending of course on how large the table is and how fragmented the data is, can cause SQL Server to perform unnecessary data reads, slowing down SQL Server’s performance.Which index to rebuild?As a rule consider that when reorganize a table's clustered index, all other non-clustered indexes on that same table will automatically be rebuilt. A table can only have one clustered index.How to rebuild all the index for one table:The DBCC DBREINDEX command will not automatically rebuild all of the indexes on a given table in a databaseHow to rebuild all indexes for all tables in a given database:USE [myDB]    -- enter your database name hereDECLARE @tableName varchar(255)DECLARE TableCursor CURSOR FORSELECT table_name FROM information_schema.tablesWHERE table_type = 'base table'OPEN TableCursorFETCH NEXT FROM TableCursor INTO @tableNameWHILE @@FETCH_STATUS = 0BEGINDBCC DBREINDEX(@tableName,' ',90)     --a fill factor of 90%FETCH NEXT FROM TableCursor INTO @tableNameENDCLOSE TableCursorDEALLOCATE TableCursorWhat does this script do?Reindexes all indexes in all tables of the given database. Each index is filled with a fill factor of 90%. While the command DBCC DBREINDEX runs and rebuilds the indexes, that the table becomes unavailable for use by your users temporarily until the rebuild has completed, so don't do this during production  hours as it will create a shared lock on the tables, although it will allow for read-only uncommitted data reads; i.e.e SELECT.What is the fill factor?Is the percentage of space on each index page for storing data when the index is created or rebuilt. It replaces the fill factor when the index was created, becoming the new default for the index and for any other nonclustered indexes rebuilt because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX uses the fill factor value last specified for the index. This value is stored in the sys.indexes catalog view. If fillfactor is specified, table_name and index_name must be specified. If fillfactor is not specified, the default fill factor, 100, is used.How do I determine the level of fragmentation?Run the DBCC SHOWCONTIG command. However this requires you to specify the ID of both the table and index being. To make it a lot easier by only requiring you to specify the table name and/or index you can run this script:DECLARE@ID int,@IndexID int,@IndexName varchar(128)--Specify the table and index namesSELECT @IndexName = ‘index_name’    --name of the indexSET @ID = OBJECT_ID(‘table_name’)  -- name of the tableSELECT @IndexID = IndIDFROM sysindexesWHERE id = @ID AND name = @IndexName--Show the level of fragmentationDBCC SHOWCONTIG (@id, @IndexID)Here is an example:DBCC SHOWCONTIG scanning 'Tickets' table...Table: 'Tickets' (1829581556); index ID: 1, database ID: 13TABLE level scan performed.- Pages Scanned................................: 915- Extents Scanned..............................: 119- Extent Switches..............................: 281- Avg. Pages per Extent........................: 7.7- Scan Density [Best Count:Actual Count].......: 40.78% [115:282]- Logical Scan Fragmentation ..................: 16.28%- Extent Scan Fragmentation ...................: 99.16%- Avg. Bytes Free per Page.....................: 2457.0- Avg. Page Density (full).....................: 69.64%DBCC execution completed. If DBCC printed error messages, contact your system administrator.What's important here?The Scan Density; Ideally it should be 100%. As time goes by it drops as fragmentation occurs. When the level drops below 75%, you should consider re-indexing.Here are the results of the same table and clustered index after running the script:DBCC SHOWCONTIG scanning 'Tickets' table...Table: 'Tickets' (1829581556); index ID: 1, database ID: 13TABLE level scan performed.- Pages Scanned................................: 692- Extents Scanned..............................: 87- Extent Switches..............................: 86- Avg. Pages per Extent........................: 8.0- Scan Density [Best Count:Actual Count].......: 100.00% [87:87]- Logical Scan Fragmentation ..................: 0.00%- Extent Scan Fragmentation ...................: 22.99%- Avg. Bytes Free per Page.....................: 639.8- Avg. Page Density (full).....................: 92.10%DBCC execution completed. If DBCC printed error messages, contact your system administrator.What's different?The Scan Density has increased from 40.78% to 100%; no fragmentation on the clustered index. Note that since we rebuilt the clustered index, all other index were also rebuilt.

  Read the article

• How many indexes will actually get used?

  - by Ender

  I'm writing a page that does very simple search queries, resulting in something like: SELECT * FROM my_table WHERE A in (a1, a2, a3) AND B in (b1, b2) AND C in (c1, c2, c3, c4) AND And so on for a variable number of columns, usually ~5. If I create a separate index for each column (one for A, one for B, one for C, not (A,B,C)), will all of them be used in the above query?

  Read the article

• Is adding indexes to a SQL Server ever a bad idea?

  - by Aerik

  We have a mid-size SQL Server based application that has no indexes defined. Not even on the the identity columns. I suggested to our moderately expensive application consultant that perhaps we might get better performance (particularly as our database grows) by creating some indexes on appropriate fields, and he said: "Indexes will significantly impact other areas of the application and customers should not create them under any circumstances." Anybody ever heard of anything like this? Are there ever circumstances where one should not create any indexes? I can see nothing special about this app - it's got int identity columns, then lots of string columns, bunch of relational tables but nothing special or weird that I can see. Thanks!

  Read the article

• "Too many indexes on table" error when creating relationships in Microsoft Access 2010.

  - by avianattackarmada

  I have tblUsers which has a primary key of UserID. UserID is used as a foreign key in many tables. Within a table, it is used as a foreign key for multiple fields (e.g. ObserverID, RecorderID, CheckerID). I have successfully added relationships (with in the the MS Access 'Relationship' view), where I have table aliases to do the multiple relationships per table: *tblUser.UserID - 1 to many - tblResight.ObserverID *tblUser_1.UserID - 1 to many - tblResight.CheckerID After creating about 25 relationships with enforcement of referential integrity, when I try to add an additional one, I get the following error: "The operation failed. There are too many indexes on table 'tblUsers.' Delete some of the indexes on the table and try the operation again." I ran the code I found here and it returned that I have 6 indexes on tblUsers. I know there is a limit of 32 indexes per table. Am I using the relationship GUI wrong? Does access create an index for the enforcement of referential integrity any time I create a relationship (especially indexes that wouldn't turn up when I ran the script)? I'm kind of baffled, any help would be appreciated.

  Read the article

• Are indexes good or bad for a large database?

  - by gmemon

  Hello All, I read on MySQL Performance Blog that when tables are large, it is better to scan full tables, instead of using indexes. I have a table with tens of millions of rows. When conducting queries, if I use no indexes, then queries are 24 times slower than with indexes. I know lot of things may cause this (e.g., are rows stored sequentially), but can you please give me some hints what might be happening? Or how I should start examining this issue? I want to understand when use of indexes is preferred and when it's not Thanks

  Read the article

• Introduction to Indexes

  Indexes are critical to good performance. However many people don't understand how indexes well. MVP Gail Shaw provides us with an introductory article on the basics of indexing. Join SQL Backup’s 35,000+ customers to compress and strengthen your backups "SQL Backup will be a REAL boost to any DBA lucky enough to use it." Jonathan Allen. Download a free trial now.

  Read the article

• Defining Indexes with SQL Server 2005

  All about SQL Indexes - Query Optimizer, Index, Unique Index, Clustered Index, Full Text Index, XML Index and SQL commands to create, delete, and rename SQL indexes.

  Read the article

• Apache Options -Indexes give me 404 instead of 403, why?

  - by netmano

  I have an Apache/2.2.21 (Debian) webserver, which I disabled directory listing with Options -Indexes but now I got 404 error for a directory, but I think I should get a 403. I have no idea why I get 404, rather than 403. What should I check? I have disabled autoindex module, after it I got a 404 for every URL that request a directory listing (eg: www.somesite.com/dir ). How can I get a 403 for this. (The dir does exist) As a try I also put Options -Index in the end of main config file (apache2.conf).

  Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >