Best Practices - Removing table fragmentations.

What is the best practices for removing the fragmentation in the tables. Does this process be used after every week month or every day.

Hi Chunm,
What is the best practices for removing the fragmentation in the tables.I monitor chained rows (table fetch continued rows), reorg with dbms_redefinition (or move to larger blocksize), and ALWAYS adjust PCTFREE to prevent future fragmentation. Read this:
http://www.dba-oracle.com/t_identify_chained_rows.htm
http://www.dba-oracle.com/oracle_tips_fetch_cont_rws.htm
Hope this helps. . .
Don Burleson
Oracle Press author

Similar Messages

Best Practice Agregate Tables for agregate awarness ..

Hello,
the question i m facing now is how to improve performance trough agregate awarness. How to plan the agregate tables in order to get the best covering for reporting requirments ? How to realize maximum use of agregate tables and minimum use of Detail tables.
Is there a method / technique to do that the best way?
until now did it this way.
1. I generated a kind of select * from DetailTable. (exp. 5 Mio rows)
2. progressivly i removed one or more dimension from the statment and got for exp. only 3 Mio Rows. the removed dimension is something like Postal code of Customers or so that i get only information about city and country. Or removing Day from date so that i only have info about the month .. etc.
3. I remove further dimensions .. (less rows exp 1 Mio)
4. at the end i have 5 or 6 agregate tables candidate for use in agregate awarness ..
Is that Ok like this .. could u please share your experiences ..?
Edited by: MM on Sep 9, 2010 3:57 PM

What was already suggested is, of course, valid. You need to find out what questions your business users are asking else you run the risk of providing an answer to an unasked question. However, there are a few other tips I would like to share.
First, if you can't get an order of magnitude reduction, it's not worth the effort. Going from 5 million to 3 million rows is not good enough to consider. Going from 5 million to 500,000 rows is, as the resulting aggregate is smaller by a factor of 10. And then going from 500,000 to 50,000 could be even better.
Second, you might consider what options your database has instead of using Aggregate Aware. For example, Teradata offers the AJI or Aggregate Join Index feature which - to be honest - is far more flexible than using Aggregate Aware in the universe. Using your database means your aggregate tables are usable by any tool that hits the database, even from tools that do not hit the universe such as Crystal.
Third, and this goes back to the first point in a way, you have to be very careful in defining your aggregate path. The Aggregate Aware feature of the semantic layer is powerful but it does have limitations. For example, you have to build a linear reduction in your path. That probably doesn't make sense (and I have a draft blog post that I have to get finished one day) but here it is in a nutshell. Suppose you have five factors in your fact, call them A, B, C, D, and E. You want to build an aggregate table at the A, B level. That's fine. You can also build an aggregate at the A, C level. But you can't use both of them in the same @Aggregate_Aware() object definition. You have to build a pyramid, like this:
A
A, B
A, B, C
A, B, C, D
A, B, C, D, E
This does not work because items disappear and reappear later on, and that does not work.
A
A, B
B, C
A, C
A, D, E
A, B, C, D, E
With Teradata AJI definitions you can do this second case. It does not work in the universe, because you need one clear "best" answer at all times. In the second case, where is the single "best place" to retrieve attribute B? There isn't one, and the aggregate aware process fails.
Hope these ideas help.

Best Practices for Table creation

Is it a good practice to have a primary key and/or unique key identifier for every tables created for an application even if for some reason the table is only being used as temporary or interface table? Thanks.

Hi,
only being used as temporaryFor temporary tables, lookup "CREATE GLOBAL TEMPORARY TABLE" in TFM
As for me a table without a PK suffers from an error in it's design. PKs are one of Merise's foundations.
Sure there are exceptions, but if more than x% of your tables have no PK, there's a problem.
Regards,
Yoann.

Best Practice - Removing Old Access-Control Lists from Bug Mitigations

I was just auditing my Internet router configuration against the NSA Router Security Configuration Guide and came across the old entries below.
access-list 100 deny   53 any any
access-list 100 deny   55 any any
access-list 100 deny   77 any any
access-list 100 deny   pim any any
I remember applying them in the dim dark past and tracked it down to this advisory "Cisco IOS Interface Blocked by IPv4 Packets".
Clearly they've just been propagated when then router and IOS get upgraded.
My question is should we remove all the old workarounds, and how often do people audit their configs?
Anything after 12.3 is not vulnerable, so it could safely be removed, but then it doesn't really hurt to leave them since we aren't expecting any of those protocols to be coming from the internet. There is always the possibility that someone will just copy it to a router with an older vulnerable IOS.
Obviously there will be a small amount of additional processing overhead on the acl too.
All comments are welcome.

I would not worry about processing. As long as you have an ACL applied, 2-3 lines more do not practically cause any extra overhead.
You can keep the deny lines there and they will not hurt.
As for how often people audit configs it depends on the policies. I have seen 6 months as the most common time frame.
I hope it helps.
PK

Best Practice - Analyze table with very large partitions

We have a table that contains 100 partitions with about 20m rows in each. Right now the analyze is taking about 1 hour per partition. The table is used for reporting and will have a nightly load of the previous days data.
What would be the best way to analyze this table? Besides using a low value for ESTIMATE and using low GRANULARITY.
Thank You.

Are you suggesting that the table is so big, its not feasible to analyze anymore?I'm suggesting it's not necessary. I think it's highly unlikely that a nightly load is going to change the stats in any meaningful way, unless you are loading millions of rows. the law of diminishing returns has kicked in.
Remember, the standard advice from Oracle is to gather statistics once and then only bother refreshing those stats when we need to. From Metalink note #44961.1:
"Given the 'best' plan is unlikely to change, frequent gathering statistics has no benefit. It does incur costs though."
What you might find useful is to export the stats from your last run before you do the new run (you should do this anyway). Then after the next stats refresh import both sets of stats into dummy schemas and compare them. If the difference is significant then you ought to keep analysing (especially if yours is a DSS or warehousing database). But if they are broadly the same then maybe it's time to stop.
Cheers, APC

Best Practices - Multiple Tables

Post Author: lpangelrob
CA Forum: Data Connectivity and SQL
Hmm. I like this forum much better.Anyways... we're a futures company, and SQL Server 2k5 is set up so that there are a couple of ways to get the previous trade date and put it into the report. I want the previous trade date in the report, but I generally can never link the data in the report to the date table, so I get the warning "Your current link configuration contains multiple starting points. / Please be advised that this is generally not supported."6 reports in, it seems as though this creates some problems. When I try to plug in the date from this second starting point, it continuously comes up as blank.Are there any other good ways to plug in arbitrary distinct data (e.g. "select max(process_date) from date_table where process_flag = 'Y'") besides adding commands through Database Expert?

Post Author: PeterLiebich
CA Forum: Data Connectivity and SQL
Create a subreport with the second table - no need to link it to the main table
If you only want to get a signle piece of information (eg max(process date)) then stick the sub-report in a section of the report header and suppress the printing. In the sub-report you should set a Shared variable.
In the main report create a formula which references the shared variable. Note. You will need to set the evaluation time of this formula to "WhilePrinitingRecords" to ensure that it evaluates after the sub report

Best practice on dynamically changing drop down in page fragment

I have a search form, which is a page fragmant that is shared across many pages. This form allows users to selct a field from the drop down list, and search for a particular value, as seen in the screenshot here:
http://photos1.blogger.com/blogger2/1291/174258525936074/1600/expanded.5.gif
Please note that the search options are part of page fragmant embedded within a page - so that I can re-use it across many pages.
The drop down list changes,based on the page this fragment is embedded. For users page, it will be last name, first name, etc. For parts page, it will be part number, part desc., etc.
Here is my code:
          Iterator it=getTableRowGroup1().getTableColumnChildren();
        Option options[]=new Option[getTableRowGroup1().getColumnCount()];
        int i=0;
        while (it.hasNext()){
            TableColumn column=(TableColumn)it.next();
            if (column.getSort()!=null){
                options=new Option(column.getSort().toString(), column.getHeaderText());
}else{
options[i]=new Option(column.getHeaderText(), column.getHeaderText());
i++;
search search=(search)getBean("search");
search.getSearchDDFieldsDefaultOptions().setOptions(options);
This code works, but it gives me all fields of the table available in the drop down. I want to be able to pick and choose. May be have an external properties file associated with each page, where I can list the fields available for search drop down??
What is the best practice to load the list of options available for drop down on each page? (i.e last name, first name, etc.) I can have the code embedded in prerender of each page, or use sort of a resouce bundle for each page or may be use a bean?

I have to agree with Pixlor and here's why:
http://www.losingfight.com/blog/2006/08/11/the-sordid-tale-of-mm_menufw_menujs/
and another:
http://apptools.com/rants/menus.php
Don't waste your time on them, you'll only end up pulling your hair out :-)
Nadia
Adobe® Community Expert : Dreamweaver
Unique CSS Templates |Tutorials |SEO Articles
http://www.DreamweaverResources.com
Book: Ultimate CSS Reference
http://www.sitepoint.com/launch/005dfd4/3/133
http://twitter.com/nadiap

Varying table columns, best practices

I've been wondering about this for quite sometime now. JTable is very complex, but it has a lot of funcationality that hints at reusable models. The separation of TableModel and ColumnModel seems to hint at being able to reuse a TableModel that stores some sort of objects, and apply different ColumnModels to view the data in different ways. Which is really cool.
However, who is in charge of managing the columns? The default implementation is usually good enough. But, it doesn't do anything special to the columns like: assign renderers, or editors. Should the column model be in charge of this? But, then you have to swap full on column models out when you want to change the look of the table. What if you just want to vary the renderer on a column, or remove one column. Would you build a whole new ColumnModel for this?
Should the JTable be in charge of setting himself up in these matters? But that seems to impose the view's representation on the model. What if you change views in some way that affects your model's structure.
Should there be some external controller in charge of this?
Sometimes you don't plan for these things at it hurts you when you need to reuse models, but maybe modify them in some way. What are your best practices?
charlie

The practice you described is what I'm doing right now, and I feel that it is cumbersome for reuse.The practice you described is what I'm doing right now, and I feel that it is cumbersome for reuse.
What I'm wondering is that if anyone has come up with a very elgant way to organize their class' responsibilities between who populates the column model. I know I can subclass and fill it in the subclass, but it seems that I might NOT need to subclass, use the default, and have another class ( maybe the JTable or a controller ), that populates the ColumnModel.
Then I can get better reuse between TableModel's and ColumnModels.
charlie

What's the best practice to partition an existing table?

We are using Oracle 11g EE 11.2.0.3.0. We want to partition an existing table. I found some information from this link [http://www.oracle-base.com/articles/misc/partitioning-an-existing-table.php], but I am not sure whether that's the best way. Could anyone share the best practice of partitioning an existing table?
Thanks.
Jun

>
We want to partition a few related tables. A couple of tables have about 30 million rows, and a couple of other tables have about 10 million rows. The data for those tables is for ~2000 accounts, each of them is identified by a column named "account_id". We want to partition the tables by using the "account_id" as the partition key to gain better performance for queries, so we would probably use hash partition. Please advise.
>
1. What evidence do you have that your performance will be any better if you partition those tables?
2. What evidence do you have that there is anything wrong with the performance of your current queries?
3. Have you reviewed the actual execution plans for your most important queries to see if there is even any room for improvement?
If your query uses account_id as a predicate but only pulls a few records from a 'master' table for that key value your performance may actually be worse if you partition that table. That is because using an index range scan Oracle can easily find the ROWIDs of the rows that need to be selected and then easily retrieve them regardless of their physical location.
If you have queries that do NOT use account_id but currently use indexes the performance of those queries may also be worse if you partition that table. Those indexes will be GLOBAL.
There are two major implications when you use hash partitioning:
1. Any query that does NOT include the partitioning key (account_id for your case) will, of necessity, have to use a full table scan if an appropriate index is not available.
2. You will get NO management benefits such as being able to add/remove partitions that include old data.
Before you decide to partition a table you should conduct tests and examine the execution plans for your important queries.

Logical level in Fact tables - best practice

Hi all,
I am currently working on a complex OBIEE project/solution where I am going straight to the production tables, so the fact (and dimension) tables are pretty complex since I am using more sources in the logical tables to increase performance. Anyway, what I am many times struggling with is the Logical Levels (in Content tab) where the level of each dimension is to be set. In a star schema (one-to-many) this is pretty straight forward and easy to set up, but when the Business Model (and physical model) gets more complex I sometimes struggle with the aggregates - to get them work/appear with different dimensions. (Using the menu "More" - "Get levels" does not allways give the best solution......far from). I have some combinations of left- and right outer join as well, making it even more complicated for the BI server.
For instance - I have about 10-12 different dimensions - should all of them allways be connected to each fact table? Either on Detail or Total level. I can see the use of the logical levels when using aggregate fact tables (on quarter, month etc.), but is it better just to skip the logical level setup when no aggregate tables are used? Sometimes it seems like that is the easiest approach...
Does anyone have a best practice concerning this issue? I have googled for this but I haven't found anything good yet. Any ideas/articles are highly appreciated.

Hi User,
For instance - I have about 10-12 different dimensions - should all of them always be connected to each fact table? Either on Detail or Total level.It not necessary to connect to all dimensions completely based on the report that you are creating ,but as a best practice we should maintain all at Detail level only,when you are mentioning any join conditions in physical layer
for example for the sales table if u want to report at ProductDimension.ProductnameLevel then u should use detail level else total level(at Product,employee level)
Get Levels. (Available only for fact tables) Changes aggregation content. If joins do not exist between fact table sources and dimension table sources (for example, if the same physical table is in both sources), the aggregation content determined by the administration tool will not include the aggregation content of this dimension.
Source admin guide(get level definition)
thanks,
Saichand.v

Temp Tables - Best Practice

Hello,
I have a customer who uses temp tables all over their application.
This customer is a novice and the app has its roots in VB6. We are converting it to .net
I would really like to know the best practice for using temp tables.
I have seen code like this in the app.
CR2.Database.Tables.Item(1).Location = "tempdb.dbo.[##Scott_xwPaySheetDtlForN]"
That seems to work, though i do not know why the full tempdb.dbo.[## is required.
However, when i use this in the new report I am doing I get runtime errors.
i also tried this
CR2.Database.Tables.Item(1).Location = "##Scott_xwPaySheetDtlForN"
I did not get errors, but I was returned data i did not expect.
Before i delve into different ways to do this, i could use some help with a good pattern to use.
thanks

Hi Scott,
Are you using the RDC still? It's not clear but looks like it.
We had an API that could piggy back the HDBC handle in the RDC ( craxdrt.dll ) but that API is no longer available in .NET. Also, the RDC is not supported in .NET since .NET uses the framework and RDC is COM.
Work around is to copy the temp data into a data set and then set location to the data set. There is no way that I know of to get to the tempdb from .NET. Reason being is there is no CR API to set the owner of the table to the user, MS SQL Server locks the tempdb to that user has exclusinve rights on it.
Thank you
Don

Best Practice Table Creation for Multiple Customers, Weekly/Monthly Sales Data in Multiple Fields

We have an homegrown Access database originally designed in 2000 that now has an SQL back-end. The database has not yet been converted to a higher format such as Access 2007 since at least 2 users are still on Access 2003. It is fine if suggestions
will only work with Access 2007 or higher.
I'm trying to determine if our database is the best place to do this or if we should look at another solution. We have thousands of products each with a single identifier. There are customers who provide us regular sales reporting for what was
sold in a given time period -- weekly, monthly, quarterly, yearly time periods being most important. This reporting may or may not include all of our product identifiers. The reporting is typically based on calendar-defined timing although we have
some customers who have their own calendars which may not align to a calendar month or calendar year so recording the time period can be helpful.
Each customer's sales report can contain anything from 1,000-20,000 rows of products for each report. Each customer report is different and they typically have between 4-30 columns of data for each product; headers are consistently named. The
product identifiers included may vary by customer and even within each report for a customer; the data in the product identifier row changes each week. Headers include a wide variety of data such as overall on hand, overall on order, unsellable on hand,
returns, on hand information for each location or customer grouping, sell-through units information for each location or customer grouping for that given time period, sell-through dollars information for each location or customer grouping for that given time
period, sell-through units information for each location or customer grouping for a cumulative time period (same thing for dollars), warehouse on hands, warehouse on orders, the customer's unique categorization of our product in their system, the customer's
current status code for that product, and so on.
Currently all of this data is stored in a multitude of Excel spreadsheets (by customer, division and time period). Due to overall volume of information and number of Excel sheets, cross-referencing can take considerable time. Is it possible to
set-up tables for our largest customers so I can create queries and pivot tables to more quickly look at sales-related information by category, by specific product(s), by partner, by specific products or categories across partners, by specific products or
categories across specific weeks/months/years, etc. We do have a separate product table so only the product identifier or a junction table may be needed to pull in additional information from the product table with queries. We do need to maintain
the sales reporting information indefinitely.
I welcome any suggestions, best practice or resources (books, web, etc).
Many thanks!

Currently all of this data is stored in a multitude of Excel spreadsheets (by customer, division and time period). Due to overall volume of information and number of Excel sheets, cross-referencing can take considerable time. Is it possible to
set-up tables .....
I assume you want to migrate to SQL Server.
Your best course of action is to hire a professional database designer for a short period like a month.
Once you have the database, you need to hire a professional DBA to move your current data from Access & Excel into the new SQL Server database.
Finally you have to hire an SSRS professional to design reports for your company.
It is also beneficial if the above professionals train your staff while building the new RDBMS.
Certain senior SQL Server professionals may be able to do all 3 functions in one person: db design, database administration/ETL & business intelligence development (reports).
Kalman Toth Database & OLAP Architect
SELECT Video Tutorials 4 Hours
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012

Best Practice to fetch SQL Server data and Insert into Oracle Tables

Hello,
I want to read sqlserver data everry half an hour and write into oracle tables ( in two different databases). What is the best practice for doing this?
We do not have any database dblinks from oracle to sqlserver and vice versa.
Any help is highly appreciable?
Thanks

Well, that's easy:
use a TimerTask to do the following every half an hour:
- open a connection to sql server
- open two connections to the oracle databases
- for each row you read from the sql server, do the inserts into the oracle databases
- commit
- close all connections

Best practice for a same query against 2 different tables

Hello all,
I want to extract info about tablespaces storage, both permanent and temporary. For that I use 2 different cursors that do exactly the same query but against a different table (dba_data_files and dba_temp_files).
CURSOR permanentTBSStorageInfo (tablespaceName VARCHAR2) IS
SELECT file_name, bytes, autoextensible, maxbytes, increment_by
FROM dba_data_files
WHERE tablespace_name = tablespaceName;
CURSOR temporaryTBSStorageInfo (tablespaceName VARCHAR2) IS
SELECT file_name, bytes, autoextensible, maxbytes, increment_by
FROM dba_temp_files
WHERE tablespace_name = tablespaceName;
First I'm bothered that I have to use 2 cursors to execute the same query against 2 different tables. Is there no another way around?
Then I fetch the results of this cursors in 2 different loops because I didn't find a way to dynamically call the cursors. I am looking for best practice here, knowing that I will do the same parsing against the results of the 2 cursors.
Thank you,

Hi
Check whether the below query is helpful or not
select      fs.tablespace_name "Tablespace",
     fs.tempspace "Temp MB",
     df.totalspace "Total MB"
     from
     (select
     tablespace_name,
     round(sum(bytes) / 1048576) TotalSpace
     from
     dba_data_files
     group by
     tablespace_name
     ) df,
     (select
     tablespace_name,
     round(sum(bytes) / 1048576) tempSpace
     from
     dba_temp_files
     group by
     tablespace_name
     ) fs
     where
     df.tablespace_name = fs.tablespace_name;
Thanks

Best practice for migrating data tables- please comment.

I have 5 new tables seeded with data that need to be promoted from a development to a production environment.
Instead of the DBAs just using a tool to migrate the data they are insistent that I save and provide scripts for every single commit, in proper order, necessary to both build the table and insert the data from ground zero.
I am very unaccustomed to this kind of environment and it seems much riskier for me to try and rebuild the objects from scratch when I already have a perfect, tested, ready model.
They also require extensive documentation where every step is recorded in a document and use that for the deployment.
I believe their rationale is they don't want to rely on backups but instead want to rely on a document that specifies each step to recreate.
Please comment on your view of this practice. Thanks!

>
Please comment on your view of this practice. Thanks!
>
Sounds like the DBAs are using best practices to get the job done. Congratulations to them!
>
I have 5 new tables seeded with data that need to be promoted from a development to a production environment.
Instead of the DBAs just using a tool to migrate the data they are insistent that I save and provide scripts for every single commit, in proper order, necessary to both build the table and insert the data from ground zero.
>
The process you describe is what I would expect, and require, in any well-run environment.
>
I am very unaccustomed to this kind of environment and it seems much riskier for me to try and rebuild the objects from scratch when I already have a perfect, tested, ready model.
>
Nobody cares if if is riskier for you. The production environment is sacred. Any and all risk to it must be reduced to a minimum at all cost. In my opinion a DBA should NEVER move ANYTHING from a development environment directly to a production environment. NEVER.
Development environments are sandboxes. They are often not backed up. You or anyone else could easily modify tables or data with no controls in place. Anything done in a DEV environment is assumed to be incomplete, unsecure, disposable and unvetted.
If you are doing development and don't have scripts to rebuild your objects from scratch then you are doing it wrong. You should ALWAYS have your own backup copies of DDL in case anything happens (and it does) to the development environment. By 'have your own' I mean there should be copies in a version control system or central repository where your teammates can get their hands on them if you are not available.
As for data - I agree with what others have said. Further - ALL data in a dev environment is assumed to be dev data and not production data. In all environments I have worked in ALL production data must be validated and approved by the business. That means every piece of data in lookup tables, fact tables, dimension tables, etc. Only computed data, such as might be in a data warehouse system generated by an ETL process might be exempt; but the process that creates that data is not exempt - that process and ultimately the data - must be signed off on by the business.
And the business generally has no access to, or control of, a development environment. That means using a TEST or QA environment for the business users to test and validate.
>
They also require extensive documentation where every step is recorded in a document and use that for the deployment.
I believe their rationale is they don't want to rely on backups but instead want to rely on a document that specifies each step to recreate.
>
Absolutely! That's how professional deployments are performed. Deployment documents are prepared and submitted for sign off by each of the affected groups. Those groups can include security, dba, business user, IT and even legal. The deployment documents always include recovery steps so that is something goes wrong or the deployment can't procede there is a documented procedure of how to restore the system to a valid working state.
The deployments themselves that I participate in have representatives from the each of those groups in the room or on a conference call as each step of the deployment is performed. Your 5 tables may be used by stored procedures, views or other code that has to be deployed as part of the same process. Each step of the deployment has to be performed in the correct order. If something goes wrong the responsible party is responsible for assisting in the retry or recovery of their component.
It is absolutely vital to have a known, secure, repeatable process for deployments. There are no shortcuts. I agree, for a simple 5 new table and small amount of data scenario it may seem like overkill.
But, despite what you say it simply cannot be that easy for one simple reason. Adding 5 tables with data to a production system has no business impact or utility at all unless there is some code, process or application somewhere that accesses those tables and data. Your post didn't mention the part about what changes are being made to actually USE what you are adding.

Best Practices - Removing table fragmentations.

Similar Messages

Maybe you are looking for