Is there any query to find the most frequent accessed table and fields in DB2 (AS400). I need this information to cache some data in order to improve the performance of our systems.
Check view qsys2.SYSTABLESTAT for table access details (logical_reads, physical_reads,etc..). Not sure about field level access details.
Related
I am rebuilding a system so instead of using multiple Access and Excel files the business I am working for, uses SSRS for reporting requirements. Most things are coming along great but I have one sticking point.
One of the Access databases has a table within itself rather than replying on the server data, which is there to keep the grade level of staff up to date (as it is a very complex method on how staff go up a grade).
Now I could easily build a new table in the SQL Server, but I do not want management relying on me for updating this particular table. I could also rebuild the Access database to upload the data to the server which is probably what I will do, but what I wanted to ask first is there a way to join to the table in the Access Database from the T-SQL query, as if it was another table in the main database?
Yes. Attach the database file under Server Objects as a Linked Server.
To ease referencing the table in this, create a view in your database that "hides" the needed weird triple-dot syntax, like:
SELECT FIELD1, FIELD2, FIELDN
FROM THELINKEDSERVERNAME...YourTable AS LinkedYourTable
Then use this view to read the table.
I've been asked to modify an Access database by putting the data themselves into a Postgres database while keeping the old Access file as a frontend. So far everything has worked just fine, with every linked table, query and form working just like before when viewed.
The issue is, however, that all of the forms call on MS Access queries which users can insert data into, but after the tables have been migrated into PostgreSQL, those queries no longer allow for data inserts, which means the forms no longer allow for data inserts. I can edit the rows already entered, but I cannot make new rows, and I can insert new rows into the linked tables. This is as a superuser.
I have made Access queries in the past that allowed for data entry to a Postgres database, but I don't have access to those files now, and I can't for the life of me figure out what I did diferently back then.
Highly appreciate any leads. Couldn't find anything on this. Using MS Access 2010 and PostgreSQL 9.1
Solved
Andre pointed out that these MS Access queries must include the primary key to give the option of creating new rows. Once I added the id field to the query, the forms worked like they did before.
The answer, supplied by Andre, is that simple MS Access queries allow for inserts into PostgreSQL if the queries include the primary key of the queried table. Cheers!
Is it possible to get the table structure like db2look from SQL?
Or the only way is from command line? Thus, by wrapping a external stored procedure in C I could call the db2look, but that is not what I am looking for.
Clarification added later:
I want to know which tables have the non logged option from SQL.
It is possible to create the table structure from regular SQL and the public DB2 catalog - however, it is complex and requires some deeper skills.
The metadata is available in the DB2 catalog views in the SYSCAT schema. For a regular table you would first start off by looking into the values in SYSCAT.TABLES and SYSCAT.COLUMNS. From there you would need to branch off to other views depending on what table and column options you are after, whether time-travel tables, special partitioning rules, or many other options are involved.
Serge Rielau published an article on developerWorks called Backup and restore SQL schemas for DB2 Universal Database that provides a set of stored procedures that will do exactly what you're looking for.
The article is quite old (2006) so you may need to put some time in to update the procedures to be able to handle features that were added to DB2 since the date of publication, but the procedures may work for you now and are a nice jumping off point.
I am currently creating a Form on access however when I go into form view I am unable to update any of the current records or add new records would anyone have any idea why I cant edit or update my records? or how I go about fixing this?
My Form is currently linked to a query, and incase it matters I also have inlcuded a search function in my form.
Any help/advice would be greatly appreciated.
Thanks
Paula
It means that the query you use is not updateable. There are a lot of limitations for updateable queries design, for instance you cannot use aggregaing in query, joins should have unique keys etc. Try to redesign your query. As a workaround you can copy the data from your query to temporary table, edit the data in this table and then copy data back to main table(s)
Your query is probably not updateable. You can check this by simply opening the query directly, and trying to edit/add data.
The most common reason is a JOIN on non-indexed columns.
For more reasons see: Dealing with Non-Updateable Microsoft Access Queries
or Allen Browne: Why is my query read-only?
I need some expert advice on Postgres
I have few tables in my database that can grow huge, may be a hundred million records and have to implement some sort of data archiving in place. Say I have a subscriber table and subscriber_logs table. The subscriber_logs table will grow huge with time, affecting performance. I wanted to create a separate table called archive_subscriber_logs and create a scheduled task which will read from subscriber_logs and insert the data into archive_subscriber_logs, then delete the dumped data from subscriber_logs.
But my concern is, should I create the archive_subscriber_logs in the same database or in a different database. The problem with storing in a different db is the foreign key constraints that already exists on the main tables.
Anyone can suggest whether same db or different db is preferable? Or any other solutions?
Consider table partitioning, which is implemented in Postgres using table inheritance. This will improve performance on very large tables. Of course you would do measurements first to make sure it is worth implementing. The details are in the excellent Postgres documentation.
Using separate databases is not recommended because you won't be able to have foreign key constraints easily.