Oracle
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Oracle

Hiệu suất điều chỉnh mê cung

Một ngày nọ, bạn thức dậy và thấy rằng bạn là quản trị viên cơ sở dữ liệu Oracle. Các vị thần cuối cùng đã nhìn ra ánh sáng tiềm năng thực sự của bạn và cho phép bạn làm việc trong công việc tốt nhất trên thế giới! Bạn bắt đầu sự nghiệp DBA của mình thật sáng sủa và rậm rạp. Bạn đang tạo cơ sở dữ liệu mới, cấp đặc quyền, viết mã PL / SQL. Cuộc sống thật tuyệt vời. Bạn không thể chờ đợi để thức dậy vào buổi sáng, rót một tách cà phê đầu tiên và hướng trình duyệt của bạn đến các diễn đàn Oracle yêu thích của bạn, mong muốn được tiếp thu kiến ​​thức cả đời trước khi ăn trưa! Nếu những vị thần đó vẫn mỉm cười với bạn, bạn thậm chí có thể trả lời một số câu hỏi và nhận được phần thưởng là những điểm tuyệt vời. Cuộc sống là tốt. Cuộc sống thật ngọt ngào.

Trong khi bạn vẫn đang đắm mình trong ánh hào quang của sự nghiệp mới thành lập, một người nào đó đã đến với bạn để giải quyết vấn đề. Một vấn đề về hiệu suất. Bạn đóng băng. Có một khối u nhỏ trong cổ họng của bạn khi bạn tự nhận ra rằng bạn không biết cách giải quyết các vấn đề về hiệu suất cơ sở dữ liệu. Điều bạn không nhận ra vào ngày hôm đó là mọi DBA trước bạn đều đã từng ở trong tình huống giống hệt như vậy ngay từ đầu trong sự nghiệp của họ. Tuy nhiên, điều đó không ngăn được người khác nhìn bạn và thắc mắc tại sao bạn không giải quyết vấn đề hiệu suất ngay lập tức. Rốt cuộc, bạn là DBA và bạn nên biết cách thực hiện công việc này. Công cụ kỳ diệu mà họ gọi là (ám chỉ các thiên thần đang hát) Điều chỉnh hiệu suất . Vì nó đã được viết, nếu bạn định trở thành một DBA và tồn tại, và làm tốt công việc này, bạn sẽ phải điều chỉnh hiệu suất. Những người khác sẽ không bao giờ biết điều gì đang diễn ra sau bức màn khi bạn chế tạo thuốc và làm phép. Tất cả những gì họ quan tâm là bạn đã giải quyết được vấn đề về hiệu suất của họ và họ có thể tiếp tục công việc hàng ngày của mình.

Vào thời điểm đầu trong sự nghiệp của họ, mọi DBA quyết định họ cần tìm hiểu thêm về thứ mà họ gọi là Điều chỉnh hiệu suất . Nó là gì? Tôi phải làm nó như thế nào? Làm thế nào tôi có thể trở thành người quan trọng nhất trong bộ phận CNTT của mình vì tôi đã khám phá ra bí quyết biến báo cáo 5 giờ đó thành một điều kỳ diệu trong 1 phút?

Ồ, hồi đó chúng tôi còn trẻ quá… ngây thơ quá. Chúng tôi nghĩ rằng nó là dễ dàng. Nhấn một vài nút, kích hoạt một vài công cụ và bắt đầu. Giải pháp điều chỉnh hiệu suất được tìm thấy và chúng tôi thật tuyệt vời! Cuộc sống dường như thật dễ dàng khi chúng tôi phiêu lưu trên con đường gạch vàng đó. Nhưng trên con đường này, không có những con quạ đáng sợ. Không có sư tử. Không có người thiếc. Thậm chí không có bất kỳ con chó nhỏ dễ thương nào tên là Toto. Không… con đường này…. Con đường Điều chỉnh Hiệu suất Oracle này chứa đầy những thứ vĩ đại hơn nhiều. Trên con đường này, chúng ta gặp các tiện ích và công cụ. Chúng tôi gặp Giải thích Kế hoạch. Chúng tôi gặp tkprof và SQLT. Chúng tôi nhận thấy những góc nhìn tuyệt vời như V $ SGA_TARGET_ADVICE và V $ SESSION_WAIT và V $ SESSION_EVENT sinh đôi của nó (không phải cặp song sinh giống hệt nhau khiến bạn nhớ, nhưng bạn chỉ cần nhìn một cái là bạn biết chúng có liên quan đến nhau).

Vậy là bạn đây rồi. Tiêu đề DBA sáng bóng của bạn vẫn nằm dưới tên của bạn trong mọi chữ ký email bạn gửi. Và bây giờ bạn có tất cả những công cụ tuyệt vời này theo ý của bạn. Bạn đã chọn ASH và AWR vì rất may công ty của bạn đã tặng cho bạn Gói chẩn đoán. Giá sách của bạn được trang bị nhiều chủ đề tuyệt vời như thế này. (Vô liêm sỉ mà tôi biết). Một số người tuyệt vời trên diễn đàn, như tôi, đã níu kéo bạn với Lighty. Bạn có toàn bộ hộp công cụ theo ý của mình. Không! Không phải hộp công cụ… .cốt nhất! Các quốc gia nhỏ ở những nơi khác trên thế giới không có kho vũ khí mà bạn có sẵn. Tại sao… Tôi có thể chạm vào nút siêu bí mật đó trong SQL Tuning Advisor và loại bỏ một trong những quốc gia đó, * và * làm cho SQL ID 98byz76pkyql chạy nhanh hơn trong khi cà phê của tôi vẫn còn hơi nước bốc lên từ nó… Tôi rất giỏi.

Bạn còn nhớ ngày hôm đó bạn nhận được sự cố về màn trình diễn đầu tiên và bạn có một khối u trong cổ họng? Có một ngày khác như thế trong sự nghiệp DBA của bạn. Đã đến ngày bạn đạt đến Mê cung điều chỉnh hiệu suất (báo hiệu sấm sét). Nhưng đây không phải là mê cung. Cái này khác. Hầu hết các mê cung có một lối vào và một lối ra, với nhiều ngã rẽ và quyết định trên đường đi. Mê cung này, tại sao, mê cung này rõ ràng là khác. Mê cung này có rất nhiều lối vào. Và mê cung này có rất nhiều lối ra. Mỗi lối vào là một công cụ điều chỉnh hiệu suất khác nhau. Và mỗi lối thoát là một giải pháp , nhưng không phải tất cả các giải pháp đều thực sự giải quyết được vấn đề về hiệu suất. Và đây là câu hỏi hóc búa mà các chuyên gia điều chỉnh hiệu suất của Oracle phải đối mặt. Tôi có một vấn đề về hiệu suất. Tôi biết ở phía bên kia của mê cung này là giải pháp của tôi. Nhưng tôi chọn lối vào nào? Một lối vào có ghi Kế hoạch Giải thích phía trên nó. Một lối vào khác có V $ DB_CACHE_ADVICE được viết trên đó. Tại sao lại có tất cả các lối vào này, mỗi lối vào cho mỗi công cụ theo ý của tôi. Đây là một câu chuyện về tuổi trẻ của tôi và hy vọng, như Bilbo đã viết cho Frodo, câu chuyện này cũng có thể giúp bạn trong cuộc phiêu lưu của mình.

Vì vậy, tôi chọn một lối vào.

Tôi bước vào mê cung.

Tôi có lựa chọn tốt không?

Hãy xem điều này sẽ đi đến đâu. Phía trước, con đường rẽ trái. Nhưng nó là sự lựa chọn duy nhất của tôi vì vậy tôi đi với nó. Tiếp theo, tôi đến một ngã tư. Tôi có thể đi sang phải hoặc sang trái. Tôi rẽ phải. Rất tiếc… ngõ cụt. Vì vậy, tôi quay lại và chuyển sang trái thay thế. Một ngõ cụt khác. Trận đấu. Tôi đã vào mê cung không chính xác. Đôi khi, các công cụ không đưa bạn đến bất kỳ giải pháp nào. Vì vậy, tôi quay lại lối vào và thực hiện một lựa chọn khác, chọn một công cụ khác.

Bây giờ tôi đã vào mê cung lần thứ hai. Nhưng mọi thứ đang có vẻ tốt hơn nhiều. Tôi tiếp tục đi. Chỉ vài lượt nữa thôi. Tôi có thể nhìn thấy ánh sáng nên tôi biết mình sắp đi đến cuối cùng. Vâng… nó đây, lối ra. Cuối cùng tôi cũng đi ra phía bên kia của mê cung. Tôi có giải pháp điều chỉnh hiệu suất trong tay nhưng sau khi thực hiện giải pháp, tôi nhanh chóng nhận ra rằng điều này không giải quyết được vấn đề hiệu suất của tôi. Đôi khi, các công cụ có thể dẫn bạn đến các giải pháp không liên quan đến vấn đề cụ thể của bạn. Vậy là đã đến lúc tôi lần thứ ba vào mê cung.

Bây giờ, là một chuyên gia điều chỉnh hiệu suất sắc sảo, tôi nhận ra rằng tất cả các lối vào mà tôi chọn cho đến nay đều liên quan đến hiệu suất cơ sở dữ liệu tổng thể nhưng những gì tôi thực sự đang tìm kiếm là hiệu suất liên quan đến một câu lệnh SQL cụ thể. Nhưng tôi không biết câu lệnh SQL nào cần điều chỉnh. Làm thế nào tôi có thể tìm ra cái nào? Ba cánh cửa đi xuống là một lối vào mê cung được đánh dấu SQL Trace. Ngay bên cạnh đó là một cánh cửa được đánh dấu EM Search Sessions. Tôi lật một đồng xu và chọn SQL Trace. Ngay sau khi tôi đi vào mê cung, tôi đến ngã tư T. Nếu tôi đi sang trái, nó sẽ đưa tôi trở lại cửa EM Search Sessions. Nếu tôi đi bên phải, đó là một cú sút thẳng tới lối ra. Tự nhiên tôi đi đúng. Nhưng chính tại thời điểm này, tôi biết rằng s ometime, hai công cụ khác nhau sẽ dẫn bạn đến cùng một câu trả lời. Khi thoát ra khỏi mê cung, tôi được cấp một vé vào cửa miễn phí tkprof bởi vì sau tất cả, không phải tất cả các con đường SQL Trace đều dẫn thẳng đến tkprof? Bây giờ tôi có câu lệnh SQL vi phạm. Nhưng vấn đề của tôi vẫn chưa được giải quyết. Làm gì?

Tôi quay trở lại lối vào mê cung. Đôi khi, chúng tôi nhận được câu trả lời từ các công cụ điều chỉnh của mình và chúng tôi phải thực hiện một lần chạy khác qua mê cung để đi sâu vào câu trả lời cuối cùng. Lần này, tôi vào cửa SQLT. Một vài khúc quanh và khúc quanh, nhưng con đường mê cung này khá dễ dàng, hoặc có vẻ như vậy. Tôi đi đến cuối cùng, và tôi không chỉ có một câu trả lời, tôi có nhiều câu trả lời. Ôi… ngày vinh quang! Tôi đã tìm thấy mẹ của tất cả các công cụ.

Tôi đã nghe các DBA khác nói về các công cụ kỳ diệu này như Báo cáo SQLT và AWR. Chúng thật tuyệt vời làm sao. Những công cụ này quá tuyệt vời, một số DBA chỉ nhìn thấy lối vào Báo cáo SQLT và AWR. Tôi luôn nghĩ đây là thứ của truyền thuyết, nhưng cuối cùng thì ở đây, tôi cũng đã tìm thấy một công cụ để cai trị tất cả… được rồi… mỗi người một việc. Tôi có tất cả những câu trả lời này theo ý của tôi. Bây giờ câu trả lời nào liên quan trực tiếp đến vấn đề hiệu suất của tôi. Ở đây tôi có báo cáo SQLT của mình và tôi có tất cả các câu trả lời trong đó. Câu trả lời nào là của tôi. Cái nào?!?!? Đôi khi, các công cụ sẽ cung cấp cho bạn quá nhiều thông tin. Đối với tôi, người mới điều chỉnh hiệu suất này, đầu ra của SQLT cũng có thể được viết bằng Klingon. Nhưng may mắn cho tôi, tôi biết một DBA đồng nghiệp ngồi cách tôi hai khối nói tiếng Klingon. Tôi đưa cho anh ta đầu ra SQLT của tôi. Anh ấy thích nó và trong vòng 30 giây, anh ấy chỉ ra một phần nhỏ của báo cáo và nói những từ kỳ diệu đó. “Thấy… ngay đó… đó là vấn đề của bạn.” Với vẻ mặt khó hiểu trên khuôn mặt tôi, anh ấy đưa tay lướt qua bản báo cáo và như thể có phép thuật, Google Dịch đã thay đổi một vài từ trên trang và giờ tôi có thể thấy rõ ràng mình có một bảng với số liệu thống kê rất tệ. Đôi khi, các công cụ có tất cả các câu trả lời đó là công cụ tiết kiệm thời gian tuyệt vời cho những người biết cách sử dụng chúng. DBA nói tiếng Klingon này đẩy kính của mình lên và tiết lộ một phần khác của báo cáo SQLT. “Hãy xem ở đây, anh ấy nói… những số liệu thống kê tồi tệ đó đang buộc FTS” như thể tôi phải biết FTS là gì vào thời điểm này trong sự nghiệp của mình. Nhưng tôi không muốn có vẻ như là tổng cộng n00b nên tôi mỉm cười và gật đầu đồng ý.

Được rồi… tôi đang tiến gần hơn đến việc giải quyết vấn đề của mình. Tôi biết tôi có số liệu thống kê không tốt. Tôi đang quay trở lại bàn làm việc của mình với mong muốn bắt đầu làm việc để giải quyết vấn đề của mình. Khi tôi đi ngang qua thùng nước mát và đi xung quanh đám đông đồng nghiệp luôn có mặt của mình mà không có gì tốt hơn để làm cả ngày ngoài việc trò chuyện, mặt trời chiếu rọi từ một cánh cửa đến mê cung và thu vào khóe mắt tôi… chỉ một cánh cửa. Phía trên cánh cửa đó là một tấm biển cho biết DBA_TABLES. Cũng giống như bất kỳ DBA tốt nào, tôi tự nói với bản thân rằng kiểm tra kỹ những điều này là một ý tưởng không tồi. Bắt đầu bị cuốn hút, tôi bước vào cánh cửa DBA_TABLES và một lần nữa lại ở trong mê cung. Tôi quay nhanh và một thứ gì đó lao ra phía tôi như thể làm tôi giật mình. Nhưng tôi đang trở nên giỏi trong việc này. Tôi không quan tâm rằng một số cư dân mê cung nhỏ nhất định nói với tôi rằng bảng này nằm trong vùng bảng USERS. Tôi nhanh chóng biết rằng điều này không có gì khác biệt đối với vấn đề của tôi. Tôi tiếp tục và bỏ qua tất cả những lần hiển thị nhỏ này với thông tin giả mạo của họ. Tôi nhấn vào. Và tôi có nó ... xác nhận ở lối ra mê cung rằng không có số liệu thống kê trên bảng này. Bài học nhanh đã được học ở đây, đôi khi, các công cụ sẽ cung cấp cho bạn thông tin không liên quan đến bạn vào ngày này .

Tôi có thể là người mới trong trò chơi DBA này, nhưng tôi biết điều này. Tôi cần xem mọi thứ hiện đang hoạt động như thế nào, thực hiện thay đổi và đo lường sự cải thiện hiệu suất nếu có. Vì vậy, tôi quay trở lại mê cung. Lần này, tôi bước vào cánh cửa được đánh dấu SQL Developer Autotrace và tôi thực thi câu lệnh SQL vi phạm. Tôi không chỉ nhận được thời gian chạy của câu lệnh SQL mà còn có thể xem số lần đọc và kế hoạch thực thi. Tôi nhanh chóng cập nhật số liệu thống kê trên bảng mà người bạn nói tiếng Klingon đã chỉ cho tôi. (Nhanh chóng sang một bên… Tôi từng nghĩ anh ta là một kẻ ngốc nhưng bây giờ anh ta không tệ như vậy. Tôi có thể học hỏi từ anh chàng này. Có lẽ một ngày nào đó tôi cũng có thể nói tiếng Klingon). Sau đó, tôi nhập lại cửa SQL Developer Autotrace. Việc thực thi truy vấn của tôi không chỉ giảm từ 2 phút thực thi xuống còn 2 giây, mà số lần đọc giảm đáng kể và Kế hoạch giải thích được cải thiện. Ok, phần cuối đó hơi dài. Tôi vẫn còn quá ngạc nhiên khi biết Kế hoạch Giải thích là tốt hơn nhưng nhìn lại sau này trong sự nghiệp của mình, tôi biết nó là như vậy. Tôi nhanh chóng biết rằng đôi khi, các công cụ điều chỉnh hiệu suất mà tôi sử dụng không chỉ ở đó để giúp tìm ra nguyên nhân gốc rễ của vấn đề mà còn ở đó để xác nhận giải pháp thực sự đã khắc phục được sự cố. Và đôi khi, những công cụ để xác nhận kết quả không phải là những công cụ tôi đã sử dụng để tìm ra nguyên nhân gốc rễ.

Tôi đã nhanh chóng thông báo cho người dùng cuối của mình rằng sự cố đã được giải quyết. Người dùng càu nhàu điều gì đó mà tôi không thể hiểu ra và kiểm tra xem cuộc sống của họ có thực sự tốt hơn hay không. Và đó là khi tôi nhận được nó. Món quà lớn nhất mà một DBA có thể nhận được. Đúng vậy… Tôi đã nhận được sự tôn thờ của người dùng . Hôm nay, tôi là một nhân viên kỳ diệu hoặc người dùng nghĩ như vậy. Khi tôi đang đứng trong tác phẩm hình khối của người dùng này, anh ấy hét lên “ANH ấy ĐÃ CỐ ĐỊNH NÓ” và theo gợi ý, toàn bộ người đứng đầu bộ phận bật lên trên những bức tường hình khối như những con chuột chũi nhô ra khỏi mặt đất. Hurray..chúng ta vui lên! Tôi đang yêu cuộc sống đắm mình trong ánh sáng rực rỡ. Tại sao ông chủ thậm chí còn đề nghị đưa chúng tôi ra quán rượu sau giờ làm việc.. hiệp đầu tiên là của cô ấy.

Tôi quay lại bàn làm việc, háo hức thực hiện thử thách tiếp theo. Công việc này không thể ngọt ngào hơn.

Tôi nhớ những lần gặp gỡ đầu tiên của mình với Mê cung Hiệu chỉnh này như thể nó mới xảy ra ngày hôm qua. Khi chúng tôi nói đùa với nhau về những ly rượu ở quán rượu vào đêm hôm đó, tôi không dám nói về một số điều tôi đã thấy trong mê cung đó. Đồng nghiệp của tôi không hiểu sao cả. Tôi không bao giờ kể cho ai biết về những trận chiến của tôi với những con rồng MOS. Tôi đã bị bỏng quá nhiều lần. Tôi không bao giờ nói với ai rằng việc chạy một truy vấn, đợi một giờ cho kết quả, thử lại, đợi một giờ, thử lại, đợi một giờ ... rất tiếc ... tôi ngủ gật ở đó. Những thử thách và gian truân của tuổi trẻ của tôi tốt hơn nên để dành cho một thời điểm khác. Có lẽ tôi sẽ viết một cuốn sách khác.

Nhưng tôi đã học được rất nhiều trong những ngày đó. Theo thời gian, tôi đã trở nên tốt hơn và chọn lối vào tốt nhất vào mê cung cho vấn đề đang xảy ra. Rốt cuộc, chỉ với kinh nghiệm, người ta mới có thể trở nên tốt hơn với những thiết bị điều chỉnh hiệu suất kỳ diệu này. Tôi cũng học được rằng đôi khi, một công cụ dường như là công cụ chính xác cho công việc chỉ để khám phá một phần thông qua nỗ lực điều chỉnh rằng một công cụ khác phù hợp hơn.

Tôi cũng học được rằng chỉ làm việc với các công cụ và học những gì họ giỏi và ngược lại những gì họ không giỏi, thì tôi mới có thể chọn tốt nhất công cụ thích hợp cho công việc. Quay lại ngày hôm đó, If thường cảm thấy như tôi đang cố gắng dùng búa đập vào một cái vít. Bây giờ tôi nhìn thấy một cái vít và biết công cụ tốt nhất là một cái tuốc nơ vít.

Theo thời gian, tôi đã tăng số lượng lối vào mê cung điều chỉnh hiệu suất của mình. Tôi vẫn đi qua những cánh cửa đã thử và có thật giống như với một cánh cửa chỉ có một con số ở trên nó, 10046. Trước đây, tôi đã từng được nghe kể về những cánh cửa thần kỳ dẫn đến cầu vồng và kỳ lân chỉ để khám phá thêm một chú troll già khó tính dưới một cầu. Lúc đầu tôi đã nghi ngờ về việc Lighty có phải là một công cụ ma thuật như vậy, nhưng tôi đã nhầm về điều đó.

Ồ, những câu chuyện tôi có thể kể cho bạn nghe, nhưng câu chuyện này thực sự là về Mê cung Điều chỉnh Hiệu suất đó. Nó luôn luôn đi xuống mê cung đó. Chọn cửa tốt nhất có thể, nhưng chỉ có kinh nghiệm mới có thể cho bạn biết cửa nào tốt nhất. Điều đó sẽ cho phép bạn đi đến giải pháp của mình nhanh nhất. Rẽ sai và bắt đầu lại. Đừng ngại vào mê cung nhiều lần. Khi bạn nghĩ rằng bạn có giải pháp, hãy đi qua mê cung để xác minh. Mê cung điều chỉnh hiệu suất kỳ diệu này với tất cả những tiện ích và công cụ điều chỉnh hiệu suất tuyệt vời của Oracle giờ đây đã trở thành một trong những địa điểm yêu thích của tôi để đi chơi. Tôi thích thêm nhiều lối vào mọi lúc, hy vọng rằng mỗi công cụ mới sẽ dẫn tôi đến cuối mê cung nhanh hơn nhiều. Đôi khi họ làm và đôi khi họ không.

Tôi vẫn nhớ những ngày tôi thường đi chơi trong mê cung cũ "điều chỉnh dựa trên tỷ lệ", nhưng tôi đã chuyển sang đồng cỏ xanh hơn. Tôi vẫn cười khúc khích khi nhìn thấy một số DBA mới đứng trước mê cung cũ kỹ đó, được bao phủ bởi mạng nhện và họ không thể hiểu được gợi ý. Và sau đó tôi cáu kỉnh khi tôi hét lên với họ rằng hãy quên mê cung đó đi và đến đây, nơi mọi người khác đang đi chơi, chỉ để bị hắt hủi bởi một người nghĩ rằng họ hiểu rõ hơn. Chà nếu chúng ta gặp lại họ, chúng ta có thể nói "Tôi đã nói với bạn như vậy" và cười sảng khoái.

Tôi thường làm việc với những người thấy tôi sử dụng một số công cụ sáng bóng này. Họ nhìn tôi đi vào mê cung và đi ra phía bên kia với câu trả lời. Vì vậy, câu hỏi rõ ràng tiếp theo của họ là "tôi cũng có thể vào cửa đó chứ?" Tôi cười thầm. “Chắc chắn… hãy tiếp tục đi”, tôi nói với họ. Được trang bị công cụ điều chỉnh tuyệt vời này, nhưng không có kiến ​​thức về cách điều chỉnh Oracle, họ đã thực hiện một nỗ lực khá tốt, nhưng yếu ớt. Họ gọi tôi đến mê cung và yêu cầu tôi giúp họ giải quyết vấn đề. Vì vậy, chúng tôi kích hoạt công cụ và xem xét nó. Tôi ngay lập tức nhận ra nguyên nhân sâu xa của vấn đề, nhưng chuông và còi sáng bóng của công cụ đang làm rối loạn tân sinh. Tại thời điểm này, tôi đang nói tiếng Klingon. Trong vài giây, tôi nói “Thấy… ngay đây… đó là vấn đề của bạn.” và tôi nhận lại được cái nhìn kỳ quặc mà tôi đã cung cấp cho người cố vấn DBA của mình cách đây nhiều năm. Những người mới này luôn muốn truy cập vào các công cụ và nghĩ rằng họ có thể sử dụng chúng như một bậc thầy. Họ không có manh mối gì trong mê cung cũng như không có manh mối nào để điều hướng nó. Quá nhiều người nghĩ rằng các công cụ là thứ nước sốt bí mật khi nó thực sự là người sử dụng công cụ đó. Đáng buồn thay, một số người có quyền truy cập vào các công cụ chỉ muốn có câu trả lời nhanh chóng và dễ dàng. Họ không muốn dành thời gian như nhiều người trong chúng ta.

Thời gian, thời gian để làm theo các bậc thầy. Tất cả chúng ta đều có phiên bản Mt Rushmore. Khắc trên đá. Những người như Millsap, Lewis và Shallahammer để kể tên một số. Mt Rushmore của bạn có thể có những tên khác hoặc thậm chí những tên tương tự. Những người khác xem Mt Rushmore của chúng tôi, tất cả đều được đặt trong đá, không nhận ra những người tốt này là người dẫn đường cho chúng tôi trong mê cung. Họ đã chỉ cho chúng tôi cách điều hướng trong mê cung. Họ đã chỉ cho chúng tôi cách sử dụng các công cụ và những công cụ nào nên sử dụng khi nào. Những người trong chúng ta, những người đã học từ các bậc thầy, hãy cố gắng hết sức để nâng cao trình độ của mình và dạy những người khác, mặc dù chúng ta có thể không bao giờ đạt được những đỉnh cao như vậy, và điều đó không sao cả.

Đạo lý của câu chuyện là học những công cụ này, học những gì chúng làm và những gì chúng không làm. Tìm hiểu những vấn đề mà họ giúp giải quyết. Tận dụng các công cụ, nhưng nhận ra rằng bạn cần học hỏi nhiều nhất có thể để có thể tự tin bước đi trong mê cung. Đáng buồn là tôi phải kết thúc câu chuyện của mình tại đây. Ai đó vừa đến văn phòng của tôi với một vấn đề điều chỉnh hiệu suất khác. Đã đến lúc vào mê cung một lần nữa. Bây giờ tôi đi cửa nào?


No
  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Hàm LAST_DAY () trong Oracle

  2. Hàm TAN () trong Oracle

  3. Độ trễ của Oracle giữa cam kết và chọn

  4. Hibernate ánh xạ một kiểu dữ liệu boolean thành gì khi sử dụng cơ sở dữ liệu Oracle theo mặc định?

  5. Cột nhận dạng Oracle và chèn vào lựa chọn