Is there a limit to the number of views that I can create and store in a database or specifically Firebird? So far, I only managed to find the maximum number of tables that can be stored in a database.
Firebird considers views a form of tables, and as such the limit on the number of tables includes views (and system tables, and virtual tables like the monitoring tables).
This limit is 32768 (see https://www.firebirdsql.org/en/firebird-technical-specifications/).
Related
While reading the official docs, I'm trying to understand exactly what objects in the db are segmented between data files or data spaces and what aren't.
https://docs.oracle.com/cd/B19306_01/server.102/b14220/physical.htm
Thanks to all who chime in.
Logical objects, such as indexes and tables, can be stored across many physical objects, such as data files.
Tables and indexes are usually assigned to a single tablespace each, although if they are partitioned each partition can use a different tablespace.
I am using golden gate to replicate table from one DB to multiple DB's. The challenging part is that in one DB the table should be replicated full (all table columns), but in the rest of the DBs the table needs to be half replicated, meaning just a few columns, not all.
Is it possible to have columns exception at the replication level ?
I know that is it possible at the extract level, but this doesn't fit to my scenario.
COLSEXCEPT is an EXTRACT parameter only. It cannot be used in replication.
For tables with large number of columns, using COLEXCEPT can help in excluding some columns instead of entering all the columns in the extract file.
You need to solve this in the REPLICAT side by mapping the necessary columns to the target table using COLMAP. I think USEDEFAULTS will not work in this case for REPLICAT since you mentioned that you need few columns only(Does that mean the table structure is different from SOURCE to TARGET???)
In my application, we have multilple global temporary tables (5-6) in an oracle function. We have indexes on the temporary tables as these can hold significant amount of data. This function is called by different users at the same time (about 30 instances). After first few calls - we are seeing timeout issues - after deleting stats on these tmp table application perform fine.
I did some research on google and it seems that global temp tables shares the stats:
http://blog.go-faster.co.uk/2009/10/global-temporary-tables-shared.html
I like to know what could be the solution for this scenario, other than dropping indexes.
I am converting sybase stored procedures into oracle views. This is what they want and this is not my first choice. My question is:
Are there any limitations in oracle views? Total number of columns? Can you create indexes for views? Since I will be creating subviews and joining views within views, are there any limitations on how many layers of views you can do?
Thanks
Are there any limitations in oracle views?
Total number of columns?
are there any limitations on how many layers of views you can do
All covered here: http://docs.oracle.com/database/121/REFRN/GUID-685230CF-63F5-4C5A-B8B0-037C566BDA76.htm#REFRN0043
The number of columns in a view has the same limits as the number of columns in a table.
Can you create indexes for views?
No you cannot. However you cate create a materialized view, that can be indexed
You're limited to 1000 columns in a table. It wouldn't shock me if there was a similar limit for views. But if you're creating a view with 1000 columns, you're probably doing something very wrong.
You cannot create indexes on views but you can create indexes on the underlying tables that queries against views can use. You can index materialized views since, as the name implies, they materialize the data into a separate structure. But then you have to deal with refreshing the materialized view on commit, which adds overhead to transactions, or tolerate stale data and refresh the materialized view on some schedule.
There is no limit to the number of layers of views you can have. Depending on the Oracle version, the complexity of the views, and things like the presence of constraints, you can end up with queries that either force Oracle to do extra work (i.e. joining in additional tables in view layers that your end query doesn't actually need) or that are too complex for the optimizer to find a decent plan.
There aren't any significant limitations on the complexity of views.
The Oracle cost-based optimizer does a decent (if inscrutable) job of figuring out how to carry out queries to views using the indexes of the underlying tables.
If that performance isn't enough, you might consider looking into materialized views.
The usual way of doing the kind of project you're doing is to get the views working, then use EXPLAIN PLAN to do the optimization.
Can Oracle Materialized views be used to join multiple related tables having foreign keys to create a larger denormalized big table which is refreshed instantaneously?
On some investigations, it says that joins are not allowed while using fast refresh.
Is it my assumption which is wrong that i can do this sort of thing with Oracle Materalized views?
Assuming all the tables are local (i.e. you are not trying to replicate the data from a remote database and do the joins all in one step), the restrictions you need to be aware of are listed in the Data Warehousing Guide, not the replication manual. The specific set of restrictions depends on the Oracle version but you should be able to create a fast-refreshable denormalized view of your data.